Vouch - Hệ thống quản lý độ tin cậy cho contributor mã nguồn mở

• Mã nguồn mở vốn từ lâu vận hành dựa trên mô hình trust and verify
• Với sự phổ biến của các công cụ AI, rào cản gia nhập để đóng góp gần như đã biến mất, khiến mô hình tin cậy ngầm trước đây không còn hoạt động hiệu quả
• Đây là hệ thống quản lý độ tin cậy cho mã nguồn mở, được thiết kế để chỉ cho phép tham gia khi độ tin cậy đã được bảo chứng rõ ràng (vouch) trước khi đóng góp
• Contributor đã được tin cậy có thể vouch cho người dùng khác, và tác nhân có hành vi ác ý có thể bị chặn một cách rõ ràng bằng denounce
  • denounce được lưu dưới dạng hồ sơ công khai để các dự án khác có thể tham khảo
  • ai sẽ vouch/denounce và theo tiêu chí nào là do từng dự án tự quyết định
  • hệ thống không áp đặt một hệ giá trị cụ thể nào, và việc quyết định chính sách thuộc về cộng đồng
• Toàn bộ dữ liệu tin cậy được quản lý phiên bản cùng với mã nguồn trong một tệp văn bản thuần duy nhất (VOUCHED) nằm trong kho lưu trữ, đảm bảo tính minh bạch và khả năng di chuyển
• Về lâu dài, hệ thống hướng tới việc chia sẻ thông tin tin cậy giữa các dự án thông qua mạng lưới tin cậy (Web of Trust)
  • việc có chấp nhận nguyên trạng đánh giá của dự án cấp trên hay không là quyền lựa chọn của dự án cấp dưới
  • các dự án vouch/denounce bừa bãi có thể tự nhiên bị loại khỏi mạng lưới tin cậy
• Có thể tích hợp đơn giản bằng GitHub Actions, và quản lý qua các từ khóa như lgtm, denounce trong bình luận issue hoặc PR
• Ghostty đã chuyển mô hình đóng góp sang hệ thống dựa trên vouch
• Được hiện thực dựa trên cảm hứng từ dự án Pi, hiện vẫn đang ở giai đoạn thử nghiệm

Các lệnh được cung cấp

• Tệp cục bộ
  • vouch.nu check <user>: kiểm tra trạng thái vouch/denounce của người dùng
  • vouch.nu add <user>: vouch cho người dùng
  • vouch.nu denounce <user>: denounce người dùng
• Tích hợp GitHub
  • vouch.nu gh-check-pr <pr>: kiểm tra trạng thái tác giả PR và tự động xử lý
  • vouch.nu gh-manage-by-issue <issue> <comment>: vouch/denounce dựa trên bình luận issue

[kuthia]

Có cảm giác là bản thân hệ thống cũng phải giành được uy tín thì mới được chấp nhận.

[xguru]

Có vẻ vì được chú ý nên có một số hiểu lầm, nên họ đã tổng hợp riêng một FAQ.
https://x.com/mitchellh/status/2020628046009831542

• Người mới bắt đầu và người tham gia mới khó tham gia
  • Hoàn toàn không có lý do gì khiến việc nhận được Vouch lại khó
  • Mục đích chính của Vouch là ngăn việc tham gia một cách tùy tiện mà không có nỗ lực
  • Trong các dự án của tôi (bao gồm cả dự án này), bạn có thể nhận được Vouch nếu tự giới thiệu trong issue và giải thích ngắn gọn bạn muốn đóng góp như thế nào
  • Nói ngắn gọn, cũng như trong đời sống xã hội thông thường, chỉ cần tự giới thiệu là có thể nhận được Vouch
  • Tuy nhiên, nếu lạm dụng quyền hạn trong nhóm thì sẽ bị xử lý
• Dễ bị social engineering
  • Người dùng đã nhận được Vouch chỉ có quyền tham gia vào dự án
  • Không có quyền như merge pull request, push code hay phát hành release
  • Tất cả các việc này đều bị giới hạn thông qua quy trình review hiện có và các biện pháp kiểm soát của hệ thống
  • Ngoài ra, chỉ quản trị viên/thành viên cộng tác mới có thể đề cử người dùng
  • Vì vậy, nếu một người dùng có vấn đề đã được đề cử thì họ cũng không thể đề cử người dùng khác
• Không có quy trình khiếu nại đối với Denouncing.
  • Quy trình khiếu nại khác nhau tùy theo từng dự án con
  • Với các dự án của tôi, chỉ cần liên hệ với chúng tôi qua Discord, email hoặc bất kỳ cách nào, nói chuyện như một con người và thừa nhận sai lầm thì chúng tôi sẽ cho bạn một cơ hội nữa. Không khó
• Cốt lõi của dự án này là AI cung cấp thông tin cho con người thông qua API call để giảm thiểu các rào cản tự nhiên vốn có
• Trong các dự án cộng đồng lấy con người làm trung tâm, chỉ cần tương tác giữa người với người ở các ranh giới mà thôi

[GN⁺]

Ý kiến trên Hacker News

• Mình nghĩ việc giả định rằng một người dùng đáng tin cậy ở một dự án sẽ tự động được tin tưởng ở dự án khác là rất nguy hiểm
  Cấu trúc như vậy có thể bị lợi dụng cho tấn công chuỗi cung ứng. Kẻ tấn công có thể xây dựng uy tín như một “người đóng góp tốt” ở nhiều dự án rồi tiếp cận dự án mục tiêu
  Nếu kiểu tin cậy chéo này được tự động hóa, thì bất kỳ tài khoản nào từng được tin tưởng đều có thể trở thành mục tiêu tấn công. Thà bắt đầu bằng một danh sách không tin cậy còn an toàn hơn là một “danh sách tin cậy”

  • Đọc phần mô tả thì có vẻ mục tiêu của hệ thống này không phải là sự tin cậy theo nghĩa bảo mật, mà gần hơn với một bộ lọc spam để chặn các đóng góp chất lượng thấp do AI tạo ra
  • Lo ngại này có phần bị phóng đại. Vouch chỉ là một cánh cổng giới hạn quyền tham gia, chứ không cấp quyền hợp nhất mã. Sau đó quy trình review hiện có vẫn giữ nguyên. Cuối cùng có thể xem nó như một lớp giảm nhiễu
  • Việc kẻ tấn công giả làm người tốt trong thời gian dài để tích lũy danh tiếng là chuyện đã xảy ra ngoài đời rồi. Cuối cùng mọi người sẽ nhận ra khi họ thay đổi. Đây giống tình huống trong xkcd 810
  • Nếu ai đó mất đi sự tin cậy, thì mọi dự án từng tin người đó cũng sẽ mất niềm tin. Đây là khái niệm kiểu bộ lọc spam, chứ không phải mức độ tin cậy như chữ ký khóa PGP. Nó không nhằm chặn các tác nhân cấp quốc gia, mà là để chặn PR spam do AI tạo ra
  • Đây không phải hệ thống hoàn hảo, nhưng mình nghĩ nó là một “cải tiến đáng để chịu phiền”. Nếu là người đóng góp thật sự thì bỏ thêm chút công sức cũng đáng. Mình cũng sẵn sàng chấp nhận mức đó

• Mình nghĩ sẽ hay nếu áp dụng chi phí $1 cho mỗi lần gửi PR.
  Nếu PR hợp lệ thì maintainer sẽ hoàn tiền.
  Bây giờ giao tiếp đã trở nên quá dễ, nên giao tiếp chất lượng thấp tràn lan. Mấy thứ này không chỉ vô giá trị mà còn là tác hại bào mòn thời gian

  • Kiểu tư duy này rốt cuộc sẽ dẫn tới khái niệm staking của thế giới crypto. Khóa token lại rồi nếu PR được merge thì nhận lại. Về mặt kỹ thuật thì gọn đẹp, nhưng khi tiền dính vào thì thiết kế sản phẩm bị tha hóa. Tuyệt đối không nên làm vậy
  • “Muốn tôi đọc bình luận của bạn thì trả $1” là một câu đùa, nhưng nó thể hiện rất rõ bản chất của ý tưởng này
  • Áp chi phí lên giao tiếp cũng có tác động tiêu cực. Điều quan trọng là điểm cân bằng của mức phí phù hợp. “Cuộc trò chuyện chất lượng thấp” từ người thân thì vẫn ổn, nhưng mình ước giao tiếp Twitter của các chính trị gia ít lại thì hơn
  • Cuối cùng đây là vấn đề ngoại hóa chi phí. Nó xảy ra trong sản xuất, giao tiếp, sinh mã và mọi lĩnh vực khác. Giờ đây ngay cả danh tiếng cá nhân cũng gần như không còn tốn chi phí để tạo ra
  • Nếu là cấu trúc như vậy thì chắc mình sẽ không gửi PR nữa. Vốn đã có nhiều PR không được phản hồi, mà còn phải trả tiền thì mình sẽ sửa ở nhánh fork luôn. Nếu không có động lực hoàn tiền thì lại càng bất công. Dù có thêm dịch vụ escrow thì cũng chỉ làm mọi thứ phức tạp hơn. Mình chỉ muốn sửa bug thôi mà không thích các thủ tục kiểu này

• Mình thắc mắc nếu người đóng góp mới không có mạng lưới quan hệ thì họ sẽ phá vỡ rào cản gia nhập bằng cách nào.
  Dù có nhiều nhiễu do AI tạo ra, đây cũng không phải lời giải

  • Trong dự án OSS của mình, mình thích mọi người đề xuất trước qua issue hoặc thảo luận hơn là gửi PR ngay. PR thường tạo ra tình huống khó xử khi nó không khớp với định hướng của dự án nhưng lại khó từ chối
  • Cũng có cách yêu cầu người đóng góp giải thích bản vá qua cuộc gọi video. Thực tế mình từng lọc được ứng viên lừa đảo bằng cách này. Dạo này FOSS gần như đã thành một trò chơi phát hiện gian lận
  • Có vẻ đây là cấu trúc giới hạn quyền truy cập theo từng bước. Ví dụ xác minh trước ở môi trường staging, rồi sau đó mới cho phép truy cập production. Trong thế giới ops thì đây vốn đã là cách làm phổ biến
  • Còn tùy cấu hình của Vouch. Có nơi có thể đóng hoàn toàn, có nơi vẫn mở issue/thảo luận nhưng chỉ hạn chế PR. Có thể tiếp cận phù hợp với tập quán của từng dự án như Linux

• Mình không đồng ý với câu “mã nguồn mở vận hành dựa trên một hệ thống tin cậy và xác minh”.
  Lý tưởng nhất là nên đánh giá được bằng chính mã nguồn.
  Khi nhìn PR, mình có thể quyết định merge hay không chỉ trong vài giây. Khó nhất là viết lý do từ chối một cách lịch sự.
  (Tham khảo: kho openpilot)

  • Gần đây mình có xem qua mã của openpilot, các phần như msgq/cereal, Params, visionipc khá thú vị về mặt cấu trúc
  • Khi có thời gian thì review, khi không có thì dựa vào sự tin tưởng

• Mình tò mò Vouch sẽ ngăn chuyện dự án trở thành một bong bóng khép kín như Bluesky bằng cách nào.
  Bluesky đang dần co lại sau bầu cử. Kiểu lọc xã hội như vậy có thể chặn mất những đóng góp mới

  • Đúng là sau bầu cử có giảm, nhưng số người dùng vẫn nhiều hơn trước đó. Nhìn thống kê thì đây là mô hình tăng vọt rồi ổn định lại.
    Hơn nữa mục tiêu của Vouch ngay từ đầu vốn là nâng cao rào cản gia nhập, nên có lẽ họ cũng không lo chuyện này
  • Mỗi dự án có thể có hệ thống vouch riêng. Cộng đồng cũng có thể nêu ý kiến phản đối qua issue hoặc PR
  • Cũng có góc nhìn kiểu: “Nếu hình thành bong bóng như Bluesky thì sao?” → “Biết đâu đó lại chính là chủ đích”
  • Điều thú vị là tài khoản bị chặn nhiều nhất trên Bluesky lại là các tài khoản chính thức của chính phủ. Điều đó cho thấy một lát cắt của cộng đồng khép kín

• Có người mỉa mai rằng hệ thống kiểu này chắc chắn sẽ không bao giờ bị lạm dụng trong một cộng đồng mã nguồn mở vốn rất ít drama.
  Thậm chí còn tự hỏi không biết có danh sách đen lập trình viên nào đang được chia sẻ hay không

• Mình nghĩ hệ thống dựa trên niềm tin chỉ hoạt động đúng khi nó đi kèm rủi ro.
  Nếu mình bảo chứng cho ai đó mà họ gây vấn đề, thì danh tiếng của mình cũng phải bị ảnh hưởng.
  Ngược lại, nếu mình chỉ trích ai đó vô căn cứ mà họ thực ra ổn, thì uy tín của mình cũng nên bị trừ.
  Nếu không thì việc bảo chứng sẽ bị lạm dụng một cách vô trách nhiệm

  • Vì vậy phải thận trọng. Nhưng nếu mình bảo chứng cho ai đó và kết quả tốt, thì mình cũng có thể được tăng uy tín. Các mối quan hệ của con người cũng vận hành như vậy.
    Cấu trúc này có vẻ cũng có thể triển khai như một đồ thị niềm tin dựa trên blockchain
  • Giống như việc đứng ra giới thiệu ai đó trong công ty, mình bảo chứng vì nếu cùng làm việc tốt thì mình cũng được lợi
  • Nếu có cơ chế người mình bảo chứng đóng góp tốt thì điểm của mình cũng tăng, đó sẽ là động lực khá tốt
  • Nhưng cấu trúc như vậy cũng có nguy cơ trao miễn trừ cho người không xứng đáng chỉ vì họ có nhiều kết nối, như trường hợp Epstein. Ngược lại, người giỏi nhưng hướng nội có thể bị loại ra ngoài
  • Mạng lưới niềm tin như vậy có thể xem là một bài toán duyệt đồ thị. Thông qua quan hệ “người tôi tin tưởng lại tin người khác”, có thể tính toán mức độ tin cậy gián tiếp

• Hệ thống này cho cảm giác khá giống ứng dụng hẹn hò.
  Có quá nhiều người không phù hợp nhưng quá sốt sắng cần phải lọc, và rồi có lẽ sẽ xuất hiện các mô thức như tham gia trả phí, dựa trên vị trí, xác minh danh tính, chấm điểm xã hội.
  Dạo này thật mệt vì những người muốn kiếm danh tiếng trên GitHub cứ liên tục gửi yêu cầu đóng góp vô nghĩa

• Mình hình dung ra một cấu trúc forge tối giản chỉ giữ lại những gì Git vốn không làm được.
  Cốt lõi là Identity, Attestation đã ký, và Policy.
  Trong số đó, Vouch xử lý các chữ ký về con người — chữ ký kiểu “người này đáng tin” có cấu trúc giống hệt chữ ký kiểu “commit này đã qua kiểm thử”.
  Nói cách khác, đây là lớp chính sách kiểm soát chính việc tham gia.
  Loại chức năng này không nên nằm trên một nền tảng đóng như GitHub mà phải tồn tại dưới dạng metadata bên trong repo.
  Mình khá tò mò xem 5 năm nữa khái niệm này sẽ tiến xa đến đâu

  • Nếu lưu loại metadata này dưới dạng chuẩn hóa như thư mục .github/, thì có thể hình thành một mô hình niềm tin độc lập với nền tảng.
    Trong thời đại mã do LLM tạo ra ngày càng nhiều, kiểu hạ tầng danh tiếng này có thể trở thành một thành phần thiết yếu của Internet

• Lúc đầu trông có vẻ ổn, nhưng rốt cuộc nó dường như dẫn tới cấu trúc “chỉ người được tin tưởng mới có thể đóng góp”

  • Dù không hẳn mang tính đột phá, nó vẫn có ý nghĩa ở chỗ khả năng thực thi được thiết kế tốt mới là điều quan trọng
  • Nó khá giống killfile thời Usenet hay danh sách RBL chống spam
    (killfile wiki, DNS blocklist)
  • Cấu trúc này phù hợp hơn với các dự án quy mô lớn. Có thể chặn PR chất lượng thấp theo mặc định, và chỉ cho những người đã xây dựng được niềm tin với maintainer cốt lõi tiếp cận