Vouch - オープンソースコントリビューター信頼管理システム

• オープンソースは伝統的に trust and verify モデルの上で動いてきた
• AIツールの普及により コントリビュートへの参入障壁が事実上なくなり、従来の暗黙的な信頼モデルはもはや機能しなくなっている
• コントリビュート前に信頼を明示的に保証（vouch） しなければ参加できないよう設計された、オープンソースの信頼管理システム
• 信頼されたコントリビューターは他のユーザーを vouch でき、悪意ある行為者は denounce（非難・告発） によって明示的にブロック可能
  • denounce は公開記録として維持され、他のプロジェクトが参照可能
  • 誰が、どの基準で vouch / denounce するかは 各プロジェクトが自律的に決定
  • システムは特定の価値観を強制せず、ポリシー決定はコミュニティの役割
• すべての信頼データはリポジトリ内の 単一のプレーンテキストファイル（VOUCHED） としてコードとともに バージョン管理 され、透明性と移植性を保証
• 長期的には、プロジェクト間で 信頼の網（Web of Trust） を形成し、信頼情報を共有する構造を目指す
  • 上位プロジェクトの判断をそのまま受け入れるかどうかは 下位プロジェクトが選択
  • 無分別に vouch / denounce を行うプロジェクトは 信頼ネットワークから自然に排除可能
• GitHub Actions と 簡単に連携可能 で、Issue や PR コメントで lgtm, denounce のようなキーワードにより管理できる
• Ghostty はコントリビューションモデルを vouch ベースのシステムに移行
• Pi プロジェクトに着想を得て実装され、現在は 実験的段階

提供されるコマンド

• ローカルファイル
  • vouch.nu check <user>: ユーザーの vouch / denounce 状態を確認
  • vouch.nu add <user>: ユーザーを vouch
  • vouch.nu denounce <user>: ユーザーを denounce
• GitHub 連携
  • vouch.nu gh-check-pr <pr>: PR 作成者の状態を確認して自動処理
  • vouch.nu gh-manage-by-issue <issue> <comment>: Issue コメントに基づいて vouch / denounce

[kuthia]

システム自体が権威を得てこそ受け入れられるのでは、という気がしますね。

[xguru]

注目を集める中で誤解もあるようなので、FAQを別途まとめたようですね
https://x.com/mitchellh/status/2020628046009831542

• 初心者や新規参加者は参加しにくい
  • Vouchを受けるのが難しい理由はまったくない
  • Vouchの主な目的は、努力せずにやみくもに参加することを防ぐこと
  • 私のプロジェクト（このプロジェクトを含む）では、issueで自己紹介をして、どのように貢献したいかを簡単に説明すればVouchを受けられる
  • 簡単に言えば、普通の社会生活のように自己紹介をすればVouchを受けられる
  • ただし、グループ内で権限を乱用すれば制裁を受けることになる
• ソーシャルエンジニアリングに弱い
  • Vouchを受けたユーザーは、プロジェクトに参加できる権限だけを得る
  • プルリクエストのマージ、コードのプッシュ、リリースなどの権限は得られない
  • これらすべての作業は、既存のレビューとシステム制御によって制限される
  • また、管理者/コラボレーターだけがユーザーを推薦できる
  • したがって、問題のあるユーザーが推薦を受けたとしても、他のユーザーを推薦することはできない
• Denouncingに対する異議申し立て手続きがありません。
  • 異議申し立ての手続きはサブプロジェクトによって異なる
  • 私のプロジェクトの場合、Discord、メールなどどのような方法でも私たちに連絡して、人として話し、ミスを認めれば、もう一度機会を与える。難しいことではない
• このプロジェクトの核心は、AIがAPI呼び出しを通じて人々に情報を提供することで、既存の自然な障壁を最小化すること
• 人間中心のコミュニティプロジェクトでは、境界線上でのみ人間的な相互作用が必要になる

[GN⁺]

Hacker Newsの意見

• あるプロジェクトで信頼されたユーザーが、別のプロジェクトでも自動的に信頼されると仮定するのは危険だと思う
  この仕組みはサプライチェーン攻撃に悪用され得る。攻撃者が複数のプロジェクトで「善良な貢献者」として信頼を積み上げたあと、標的のプロジェクトに近づけるからだ
  このような交差的な信頼が自動化されると、一度でも信頼されたアカウントが攻撃対象になり得る。むしろ「信頼リスト」より「不信リスト」から始めるほうが安全だと思う

  • 説明を見る限り、このシステムの目的はセキュリティ上の意味での信頼というより、AI生成の低品質な貢献物をふるい落とすスパムフィルターに近いようだ
  • この懸念はやや誇張されている。Vouchは単なる参加権限を制限するゲートであって、コードのマージ権限を与えるものではない。その後は既存のレビュー手順がそのまま維持される。結局のところノイズ最小化レイヤー程度と見ればよい
  • 攻撃者が長期にわたって善人を装い評判を築くのは、すでに現実でも起きている。結局、人はその人物が変わったときに気づく。これは xkcd 810 のような状況だ
  • 誰かが信頼を失えば、その人を信頼していたすべてのプロジェクトでも信頼が失われる。これはスパムフィルターのような概念であって、PGPキー署名レベルの信頼ではない。国家級の攻撃者を防ぐためではなく、AIスパムPRを防ぐための仕組みだ
  • 完璧なシステムではないが、**「面倒をかける価値のある改善」**だと思う。本物の貢献者なら少しの追加の手間をかける価値はある。私もその程度なら受け入れるつもりだ

• PR提出に1ドルの費用を課すとよいのではないかと思う。
  PRが有効ならメンテナーが返金する方式だ。
  今はコミュニケーションが簡単になりすぎて、低品質なコミュニケーションがあふれている。これは単に価値がないだけでなく、時間を食い潰す害でもある

  • この考え方は結局、暗号資産界のステーキングの概念につながる。トークンをロックし、PRがマージされたら返してもらう構造だ。技術的には洗練されているが、金が絡むとプロダクト設計は堕落する。絶対にそうしてはいけない
  • 「私のコメントを読みたければ1ドル払え」という冗談だが、アイデアの本質をよく表している
  • コミュニケーションにコストを課すと負の効果もある。適切なコストの均衡点が重要だ。身近な人の「低品質な会話」は構わないが、政治家たちのTwitterでの発信は減ってほしい
  • これは結局、コストの外部化の問題だ。製造、コミュニケーション、コード生成などあらゆる領域で起きている。今や個人の評判でさえ、ほとんどコストがかからない
  • 私ならこういう仕組みではPRをそもそも出さない気がする。すでに多くのPRが無反応なのに、金まで払うなら単にforkで修正する。返金のインセンティブがない構造ならなおさら不公平だ。エスクローサービスを置くとしても複雑になる。単にバグを直したいだけなのに、こんな手続きは嫌だ

• 新しい貢献者がネットワークを持っていなければ、どうやって参入障壁を突破できるのか疑問だ。
  AIが作ったノイズが多いとしても、これは解決策ではない

  • 私のOSSプロジェクトでは、PRより先にissueや議論で提案してもらうほうを好む。PRはしばしばプロジェクトの方向性と合わず、断りにくい状況を生む
  • 貢献者にビデオ通話でパッチを説明させる方法もある。実際、このやり方で詐欺的な応募者を見抜いたことがある。最近のFOSSはほとんど詐欺検知ゲームになってしまった
  • アクセスを段階的に制限する構造に見える。たとえばステージング環境で先に検証し、その後に本番アクセスを許可するような形だ。これはすでに**運用(ops)**の世界では一般的なやり方だ
  • Vouchの設定次第だ。一部は完全に閉じることもできるし、一部はissue・議論は開けたままPRだけ制限することもできる。Linuxのように各プロジェクトの慣行に合わせて運用すればよい

• 「オープンソースは信頼して検証するシステムの上で動いている」という言葉には同意しない。
  理想的にはコードそのもので評価できるべきだ。
  私はPRを見れば数秒でマージすべきか判断する。難しいのは却下理由を丁寧に書くことだ。
  （参考: openpilotリポジトリ）

  • 最近openpilotのコードを見たが、msgq/cereal, Params, visionipc など構造が興味深い
  • 時間があるときはレビューし、ないときは信頼するという形で回っている

• VouchプロジェクトがBlueskyのような閉鎖的バブルになるのをどう防ぐのか気になる。
  Blueskyは選挙後に縮小しつつある。こうした社会的フィルタリングが新しい貢献を妨げるかもしれない

  • 選挙後に減少したのは事実だが、それ以前より依然としてユーザー数は多い。統計 を見るとスパイク後の安定化パターンだ。
    しかもVouchの目的はそもそも参入障壁を上げることなので、こうした問題は気にしていないのだろう
  • プロジェクトごとに独自のvouchシステムを持てる。コミュニティがissueやPRで反対意見を示すこともできる
  • 「Blueskyのようなバブルができたらどうする？」→「それこそが意図かもしれない」という見方もある
  • Blueskyで最も多くブロックされているアカウントが政府公式アカウントだという点は興味深い。閉鎖的コミュニティの一面を示している

• こんなシステムがドラマのないオープンソースコミュニティで絶対に悪用されないはずがない、と皮肉っている。
  ひょっとしてブラックリスト化された開発者名簿でも共有されているのかと気になる

• 信頼ベースのシステムは、必ずリスクを伴ってこそ機能すると思う。
  私が誰かを保証して、その人が問題を起こしたなら私の評判も下がるべきだ。
  逆に根拠なく非難して、その人がまともな人物だったなら私の評判が下がるべきだ。
  そうでなければ保証が無責任に乱用されるだろう

  • だから慎重であるべきだ。ただし誰かを保証して良い結果になれば、自分の評判上昇も得られるはずだ。人間関係もそういうふうに機能している。
    こうした構造はブロックチェーンベースの信頼グラフとして実装できるかもしれない
  • 会社で推薦人を立てるのと同じで、一緒に働けば自分にも利益があるから保証するのだ
  • 自分が保証した人が良い貢献をしたら自分のスコアも上がる仕組みなら、動機づけになると思う
  • しかしこうした構造は、Epsteinのような事例のように、つながりが多いという理由で不適切な人物に免罪符を与える危険がある。逆に内向的だが有能な人は排除されるかもしれない
  • こうした信頼網はグラフ探索問題として見ることができる。自分が信頼する人が信頼する人という関係を通じて、間接的な信頼度を計算できる

• このシステムはデーティングアプリに似ているように感じる。
  フィルタリングすべきやる気だけは過剰な不適格者が多く、結局は有料参加・位置情報・本人確認・社会的スコア化のようなパターンが生まれそうだ。
  最近はGitHubで名声を得たがる人たちが無意味な貢献リクエストを乱発していてうんざりする

• Gitがもともとできない機能だけを残したミニマルforge構造を想像してみる。
  核心はIdentity、Attestation、Policy だ。
  Vouchはこのうち人に対する署名を扱う――「この人は信頼できる」という署名は、「このコミットはテストに通った」という署名と構造的には同じだ。
  つまり、参加そのものを制御するポリシーレイヤーなのだ。
  こうした機能はGitHubのような閉鎖プラットフォームではなく、リポジトリ内部のメタデータとして存在すべきだ。
  5年後にこの概念がどこまで発展しているのか気になる

  • こうしたメタデータを**.github/** フォルダのような標準化された形で保存すれば、プラットフォーム非依存の信頼モデルが可能になる。
    LLMが生成したコードが増える時代に、こうした評判インフラはインターネットの必須要素になるかもしれない

• 最初はよさそうに見えたが、結局は**「信頼された人だけが貢献可能」**という構造に行き着くように思える

  • 革新的というより、よく設計された実行力が重要だという点では意味がある
  • 昔のUsenetのkillfileやスパムRBLリストに似ている
    （killfile wiki、DNS blocklist）
  • 大規模プロジェクトにはこうした仕組みのほうが適している。低品質なPRをデフォルトで遮断し、コアメンテナーとの信頼を築いた人だけがアクセスできるようにする