Vouch - sistem manajemen kepercayaan kontributor open source

• Open source secara tradisional berjalan di atas model trust and verify
• Dengan meluasnya alat AI, hambatan masuk untuk berkontribusi pada dasarnya hilang, sehingga model kepercayaan implisit yang lama tidak lagi efektif
• Sistem manajemen kepercayaan open source yang dirancang agar partisipasi hanya dimungkinkan jika ada jaminan kepercayaan eksplisit (vouch) sebelum berkontribusi
• Kontributor tepercaya dapat vouch untuk pengguna lain, dan pelaku berniat buruk dapat diblokir secara eksplisit dengan denounce
  • denounce disimpan sebagai catatan publik sehingga dapat dijadikan referensi oleh proyek lain
  • siapa yang boleh melakukan vouch/denounce, dan berdasarkan kriteria apa, ditentukan secara mandiri oleh tiap proyek
  • sistem ini tidak memaksakan nilai tertentu, dan keputusan kebijakan merupakan ranah komunitas
• Semua data kepercayaan dikelola versinya bersama kode dalam satu file teks biasa (VOUCHED) di dalam repositori, untuk menjamin transparansi dan portabilitas
• Dalam jangka panjang, sistem ini menargetkan pembentukan jaringan kepercayaan (Web of Trust) antarpoyek untuk berbagi informasi kepercayaan
  • apakah penilaian proyek induk akan diterima apa adanya dipilih oleh proyek turunan
  • proyek yang sembarangan melakukan vouch/denounce dapat tersisih secara alami dari jaringan kepercayaan
• Dapat diintegrasikan dengan mudah melalui GitHub Actions, dan dikelola lewat komentar issue atau PR menggunakan kata kunci seperti lgtm, denounce
• Ghostty telah beralih ke sistem berbasis vouch untuk model kontribusinya
• Diimplementasikan dengan inspirasi dari proyek Pi, dan saat ini masih dalam tahap eksperimental

Perintah yang disediakan

• File lokal
  • vouch.nu check <user>: memeriksa status vouch/denounce pengguna
  • vouch.nu add <user>: melakukan vouch untuk pengguna
  • vouch.nu denounce <user>: melakukan denounce terhadap pengguna
• Integrasi GitHub
  • vouch.nu gh-check-pr <pr>: memeriksa status penulis PR dan memprosesnya secara otomatis
  • vouch.nu gh-manage-by-issue <issue> <comment>: melakukan vouch/denounce berdasarkan komentar issue

[kuthia]

Menurut saya, sistem itu sendiri harus memperoleh otoritas agar bisa diterima.

[xguru]

Sepertinya ada beberapa kesalahpahaman seiring topik ini makin mendapat perhatian, jadi FAQ-nya dirangkum terpisah. https://x.com/mitchellh/status/2020628046009831542

• Pemula dan peserta baru sulit untuk ikut berpartisipasi
  • Tidak ada alasan sama sekali mengapa mendapatkan Vouch harus sulit
  • Tujuan utama Vouch adalah mencegah partisipasi sembarangan tanpa usaha
  • Di proyek saya (termasuk proyek ini), Anda bisa mendapatkan Vouch dengan memperkenalkan diri di issue dan menjelaskan secara singkat bagaimana Anda ingin berkontribusi
  • Singkatnya, seperti dalam kehidupan sosial pada umumnya, Anda bisa mendapatkan Vouch dengan memperkenalkan diri
  • Namun, jika menyalahgunakan wewenang di dalam grup, akan ada sanksi
• Rentan terhadap social engineering
  • Pengguna yang menerima Vouch hanya mendapatkan hak untuk berpartisipasi dalam proyek
  • Mereka tidak mendapatkan hak untuk merge pull request, push code, atau membuat rilis
  • Semua tindakan ini tetap dibatasi melalui proses review yang ada dan kontrol sistem
  • Selain itu, hanya admin/kolaborator yang dapat merekomendasikan pengguna
  • Karena itu, meskipun pengguna bermasalah menerima rekomendasi, mereka tidak bisa merekomendasikan pengguna lain
• Tidak ada prosedur banding untuk Denouncing.
  • Prosedur banding berbeda tergantung subproyek
  • Untuk proyek saya, jika Anda menghubungi kami lewat Discord, email, atau cara apa pun, lalu berbicara secara manusiawi dan mengakui kesalahan, kami akan memberi Anda kesempatan lagi. Tidak sulit
• Inti proyek ini adalah AI meminimalkan hambatan alami yang sudah ada dengan memberikan informasi kepada orang-orang melalui panggilan API
• Dalam proyek komunitas yang berpusat pada manusia, interaksi antarmanusia hanya diperlukan di titik-titik batas

[GN⁺]

Komentar Hacker News

• Menurut saya berbahaya jika diasumsikan bahwa pengguna tepercaya di satu proyek otomatis dipercaya juga di proyek lain
  Struktur seperti ini bisa disalahgunakan untuk serangan rantai pasok. Penyerang dapat membangun kepercayaan sebagai ‘kontributor baik’ di banyak proyek, lalu mendekati proyek target
  Jika kepercayaan lintas proyek seperti ini diotomatisasi, akun yang pernah dipercaya sekali pun bisa menjadi sasaran serangan. Menurut saya, lebih aman memulai dari daftar tidak dipercaya daripada ‘daftar dipercaya’

  • Dari penjelasannya, tujuan sistem ini tampaknya lebih mirip filter spam untuk menyaring kontribusi buruk buatan AI daripada kepercayaan dalam arti keamanan
  • Kekhawatiran seperti ini agak dibesar-besarkan. Vouch hanyalah gerbang pembatas partisipasi, bukan pemberian hak untuk menggabungkan kode. Setelah itu, prosedur review yang ada tetap berjalan seperti biasa. Pada akhirnya ini bisa dilihat sebagai lapisan minimisasi kebisingan
  • Penyerang yang berpura-pura baik dalam jangka panjang untuk membangun reputasi sudah terjadi di dunia nyata. Pada akhirnya orang-orang menyadari ketika dia berubah. Ini situasi seperti xkcd 810
  • Jika seseorang kehilangan kepercayaan, kepercayaan itu juga hilang di semua proyek yang mempercayainya. Ini konsep seperti filter spam, bukan kepercayaan setingkat penandatanganan kunci PGP. Tujuannya bukan menghentikan penyerang kelas negara, melainkan mencegah PR spam AI
  • Ini memang bukan sistem sempurna, tetapi saya rasa ini adalah “peningkatan yang layak untuk sedikit kerepotan”. Jika memang kontributor sungguhan, sedikit usaha tambahan masih layak. Saya sendiri bersedia menerimanya

• Saya berpikir mungkin bagus jika ada biaya $1 untuk mengirim PR.
  Jika PR valid, maintainer mengembalikannya.
  Sekarang komunikasi sudah terlalu mudah sehingga komunikasi berkualitas rendah membanjir. Hal seperti ini bukan sekadar tidak bernilai, tapi juga kerusakan yang menggerogoti waktu

  • Pola pikir seperti ini pada akhirnya mengarah ke konsep staking di dunia kripto. Token dikunci, lalu dikembalikan jika PR digabungkan. Secara teknis elegan, tetapi ketika uang ikut masuk, desain produk jadi rusak. Ini sama sekali tidak boleh dilakukan
  • “Kalau mau baca komentar saya, bayar $1” memang lelucon, tetapi itu cukup menggambarkan inti idenya
  • Membebankan biaya pada komunikasi juga punya efek negatif. Titik keseimbangan biaya yang tepat itu penting. ‘Percakapan berkualitas rendah’ dari orang dekat masih bisa diterima, tetapi saya berharap komunikasi Twitter para politisi berkurang
  • Ini pada akhirnya soal eksternalisasi biaya. Terjadi di manufaktur, komunikasi, pembuatan kode, dan semua bidang lain. Sekarang bahkan reputasi pribadi pun hampir tidak butuh biaya
  • Kalau strukturnya seperti ini, saya rasa saya tidak akan mengirim PR sama sekali. Banyak PR saja sudah tidak dijawab, apalagi kalau masih harus bayar, saya akan langsung memperbaiki di fork. Jika tidak ada insentif pengembalian dana, ini makin tidak adil. Bahkan jika ada layanan escrow, semuanya jadi makin rumit. Saya cuma ingin memperbaiki bug, dan saya tidak suka prosedur seperti ini

• Saya penasaran bagaimana kontributor baru tanpa jaringan bisa menembus hambatan masuk.
  Walaupun memang ada banyak kebisingan buatan AI, ini bukan solusinya

  • Di proyek OSS saya, saya lebih suka usulan diajukan dulu lewat issue atau diskusi daripada langsung PR. PR sering membuat situasi canggung ketika harus ditolak karena tidak sejalan dengan arah proyek
  • Ada juga metode meminta kontributor menjelaskan patch lewat panggilan video. Saya benar-benar pernah menyaring pelamar palsu dengan cara ini. FOSS belakangan ini hampir menjadi permainan deteksi penipuan
  • Ini tampaknya struktur yang membatasi akses secara bertahap. Misalnya diverifikasi dulu di lingkungan staging, lalu baru diberi akses produksi. Di dunia ops, ini sudah sangat umum
  • Tergantung pengaturan Vouch. Sebagian bisa ditutup sepenuhnya, sebagian lain bisa tetap membuka issue·diskusi dan hanya membatasi PR. Pendekatannya bisa disesuaikan dengan kebiasaan tiap proyek seperti Linux

• Saya tidak setuju dengan pernyataan bahwa “open source berjalan di atas sistem percaya lalu verifikasi.”
  Idealnya, kode harus bisa dinilai dari dirinya sendiri.
  Saat melihat PR, saya bisa memutuskan dalam hitungan detik apakah akan digabungkan atau tidak. Yang sulit adalah menulis alasan penolakan dengan sopan.
  (Referensi: repositori openpilot)

  • Saya baru-baru ini melihat kode openpilot, dan strukturnya seperti msgq/cereal, Params, visionipc cukup menarik
  • Saat ada waktu, orang melakukan review; saat tidak ada waktu, orang mengandalkan kepercayaan

• Saya penasaran bagaimana proyek Vouch akan mencegah dirinya menjadi gelembung tertutup seperti Bluesky.
  Bluesky makin menyusut setelah pemilu. Pemfilteran sosial seperti ini juga bisa menghalangi kontribusi baru

  • Memang benar ada penurunan setelah pemilu, tetapi jumlah penggunanya masih lebih banyak daripada sebelumnya. Jika melihat statistik, polanya adalah lonjakan lalu stabilisasi.
    Lagi pula tujuan Vouch memang sejak awal menaikkan hambatan masuk, jadi mungkin mereka tidak terlalu mengkhawatirkan hal ini
  • Setiap proyek bisa punya sistem vouch mandiri sendiri. Komunitas juga bisa menyampaikan keberatan lewat issue atau PR
  • Ada juga sudut pandang “Bagaimana kalau muncul gelembung seperti Bluesky?” → “Mungkin memang itu tujuannya”
  • Menarik bahwa akun yang paling banyak diblokir di Bluesky adalah akun resmi pemerintah. Ini menunjukkan salah satu sisi komunitas yang tertutup

• Dengan nada sarkastik: sistem seperti ini pasti sama sekali tidak akan disalahgunakan di komunitas open source tanpa drama.
  Saya jadi penasaran apakah mereka membagikan semacam daftar pengembang yang diblokir

• Saya rasa sistem berbasis kepercayaan hanya bisa berfungsi jika ada risiko yang menyertainya.
  Jika saya menjamin seseorang lalu dia menimbulkan masalah, reputasi saya juga harus turun.
  Sebaliknya, jika saya menuduh seseorang tanpa dasar dan ternyata dia orang baik, reputasi saya juga harus berkurang.
  Kalau tidak, penjaminan akan disalahgunakan secara ceroboh

  • Karena itu kita harus hati-hati. Tetapi jika saya menjamin seseorang dan hasilnya baik, saya juga bisa mendapat kenaikan reputasi. Hubungan antarmanusia juga bekerja seperti itu.
    Struktur seperti ini tampaknya juga bisa diwujudkan sebagai graf kepercayaan berbasis blockchain
  • Seperti ketika perusahaan meminta referensi, orang memberi jaminan karena jika bekerja bersama, saya juga mendapatkan manfaat
  • Kalau ada struktur di mana skor saya juga naik ketika orang yang saya jamin memberi kontribusi bagus, itu terasa memotivasi
  • Tetapi struktur seperti ini berisiko memberi pengampunan pada orang yang salah hanya karena punya banyak koneksi, seperti kasus Epstein. Sebaliknya, orang kompeten yang introver bisa tersisih
  • Jaringan kepercayaan seperti ini bisa dilihat sebagai masalah penelusuran graf. Melalui hubungan orang yang dipercaya oleh orang yang saya percayai, kita bisa menghitung tingkat kepercayaan tidak langsung

• Sistem ini terasa mirip aplikasi kencan.
  Ada banyak orang tidak cocok yang terlalu bersemangat yang perlu difilter, dan pada akhirnya sepertinya akan muncul pola seperti partisipasi berbayar, berbasis lokasi, verifikasi identitas, dan pemberian skor sosial.
  Belakangan ini melelahkan karena banyak orang ingin mendapat reputasi di GitHub dengan membanjiri proyek dengan permintaan kontribusi yang tidak bermakna

• Saya membayangkan struktur forge minimalis yang hanya menyisakan hal-hal yang Git secara bawaan belum bisa lakukan.
  Intinya adalah Identity, Attestation, dan Policy.
  Di antara itu, Vouch menangani tanda tangan tentang manusia — tanda tangan “orang ini dapat dipercaya” secara struktural sama dengan tanda tangan “commit ini lulus pengujian”.
  Dengan kata lain, ini adalah lapisan kebijakan yang mengendalikan partisipasi itu sendiri.
  Fitur seperti ini seharusnya tidak berada di platform tertutup seperti GitHub, melainkan sebagai metadata di dalam repo.
  Saya penasaran sejauh mana konsep ini akan berkembang dalam 5 tahun ke depan

  • Jika metadata seperti ini disimpan dalam bentuk terstandarisasi seperti folder .github/, maka model kepercayaan yang independen dari platform menjadi mungkin.
    Di era ketika kode buatan LLM terus bertambah, infrastruktur reputasi seperti ini bisa menjadi elemen penting internet

• Awalnya ini tampak lumayan, tetapi pada akhirnya sepertinya berujung pada struktur “hanya orang tepercaya yang bisa berkontribusi”

  • Nilainya ada bukan karena inovatif, melainkan karena eksekusi yang dirancang dengan baik itu penting
  • Ini mirip dengan killfile di Usenet lama atau daftar RBL spam
    (wiki killfile, DNS blocklist)
  • Struktur seperti ini lebih cocok untuk proyek berskala besar. Ia memblokir PR berkualitas rendah secara default, dan hanya memberi akses kepada orang-orang yang sudah membangun kepercayaan dengan maintainer inti