ハクソク

世界を動かす技術を、日本語で。

バウチ

107日前原文(github.com)

概要

Vouch は、オープンソースプロジェクト向けの 信頼管理システム。 vouched/denounced の概念で貢献者の信頼性を明示的に管理。 GitHub Actions やCLI経由で容易に導入・運用可能。 Web of Trust 構築により、複数プロジェクト間で信頼の共有が可能。 Ghostty で実験運用中、今後も改善予定。

Vouch: プロジェクト信頼管理システム

  • Vouch は、プロジェクト内で特定の操作を行う前に 信頼されている人物（vouched） であることを必須とするシステム
  • 明示的な排除（denounced） も可能で、信頼できない人物はプロジェクトへの関与をブロック
  • 実装は 汎用的 で、どんなプロジェクト・コードホスティングサービスでも利用可能
  • GitHub統合 を標準サポートし、GitHub ActionsやCLIから運用可能
  • vouchリスト はシンプルなフラットファイル形式で管理、POSIXツールや任意のプログラミング言語で容易にパース可能

Web of Trustと信頼の共有

  • vouchリスト は他プロジェクトのリストを参照でき、 信頼のネットワーク（Web of Trust） を構築可能
  • 価値観を共有する複数プロジェクト間で 信頼判断の連携 が実現
  • あるプロジェクトで信頼されたユーザーは、他プロジェクトでも自動的に信頼される仕組み

背景と目的

  • 従来のOSSは「 信頼して検証する」文化だが、AIツールの普及で低品質な貢献が増加
  • 従来の参入障壁 では信頼性を担保できなくなった現状
  • 明示的な 信頼モデル への移行を提案し、信頼された人物のみが貢献できる体制を目指す

vouch/denounceの運用

  • 誰を信頼・排除するか、その結果の扱いは各プロジェクトが自由に決定
  • プロジェクトやコミュニティの方針に合わせた柔軟な運用が可能

GitHub統合と利用方法

  • GitHub Actions を使い、PR作者のvouch状態チェックや自動クローズが可能
  • manage-by-discussion ：ディスカッションコメントでvouch/denounce操作
  • manage-by-issue ：イシューコメントでvouch/denounce操作
  • 詳細な運用例は 公式リポジトリ を参照

CLI（Nushellモジュール）

  • Nushell のみで動作、追加依存なし
  • 各コマンドはhelpで詳細確認可能
  • ローカルコマンド例
    • ユーザーのvouch状態確認：vouch check <ユーザー名>
    • ユーザーをvouchedリストに追加：vouch add <ユーザー名>
    • ユーザーをdenounce：vouch denounce <ユーザー名> --reason "理由"
  • GitHub統合コマンド例
    • PR作者のvouch状態チェック：vouch gh-check-pr <PR番号> --repo <owner/repo>
    • イシューコメント経由でvouch/denounce：vouch gh-manage-by-issue <issue番号> <comment_id> --repo <owner/repo>

コマンド出力ステータス

  • vouched ：信頼済み
  • denounced ：排除済み
  • unknown ：未判定
  • skipped ：botや書き込み権限コラボレーター
  • allowed/closed/unchanged ：各アクション結果

カスタマイズ

  • vouch/denounceキーワードは--vouch-keyword・--denounce-keywordで変更可能

ライブラリ・スクリプト連携

  • libサブモジュール でスクリプトからvouchリスト操作可能
    • 例：ユーザーの状態取得、追加、排除、削除

vouchedファイルフォーマット（.td）

  • .tdファイル （Trustdown形式）でvouchリスト管理
  • 1行1ハンドル、アルファベット順、@不要
  • プラットフォーム指定例：github:mitchellh
  • denounceは-プレフィックス、理由はスペース区切りで追記可能
  • コメントは#で記載
  • Nushellのopenコマンド で構造化テーブルとして扱える
  • from td/to tdコマンド も利用可能

Trustdown（.td）仕様について

  • Trustdown はMarkdownをもじった信頼リスト仕様
  • vouchシステムの安定運用後、正式な仕様公開予定

注意事項・今後

  • Ghostty プロジェクトで実験運用中
  • 利用経験・フィードバックを元に今後も継続的に改善予定

参考リンク

Hackerたちの意見

GitHubがプラットフォームに何かをネイティブに統合してくれるといいな。公式フォーラムで見た関連の議論があるよ: https://github.com/orgs/community/discussions/185387

└

来週、ここでいくつかの初期変更を出す予定だよ。メンテナーがPRアクセスを設定できるようにするためにね。これが出たら、まだ改善の余地がたくさんあるから、いろいろと迅速に探求を続けるつもり。最近、コメントのピン留めや+1コメントの誘導など、いくつかの問題関連の機能も出したよ。[1] こういうのがコミュニティで他にどんなものが出てくるのか興味あるな。実験が続くといいね、OSSにとっては良いことだと思う。[1] https://github.blog/changelog/2026-02-05-pinned-comments-on-...

個人的には、信頼ベースのシステムはリスクを伴う場合にのみ機能すると思う。自分のスコアは「推薦する」人や「非難する」人にリンクしているべきだね。これは現実世界と似ていて、誰かを推薦してその人が詐欺を働いたら、自分の評判も落ちるからね。だから、推薦にはリスクがある。逆に、誰かを避けているのが信頼できないと分かれば、自分の評判も落ちる。もし推薦や非難が無料になったら、武器化するのが簡単になっちゃう。そうなると、そもそも誰かを推薦するために自分の評判をリスクにさらす理由がなくなるよね。

└

そうなると、そもそも誰かを推薦するために自分の評判をリスクにさらす理由がなくなるよね。推薦した人がプロジェクトに貢献すると、自分の推薦スコアが上がるってこともあるかも？

└

そうなると、そもそも誰かを推薦するために自分の評判をリスクにさらす理由がなくなるよね。慎重になる理由はあるね。もしかしたら、良い仕事をする人を推薦すると、自分も少し恩恵を受けるかも。結局、個人関係ってそういうもんだし。---------- 俺は暗号通貨にはかなり懐疑的だけど、こういうのがブロックチェーン技術の実際の良い使い方になるんじゃないかって考えたことはあるな…

└

最近、似たようなことを考えてて、「パラレルウェブ」がどんな感じになるか想像してた。俺の（正直言って不完全な）アイデアの一つは、現実世界のインセンティブに似た推薦システム。基本的に、サインアップするには誰かが推薦する必要があって、実際に物理的なやり取りがある感じ。でも、もっと進めたいんだ。サインアップするときに、リアルな詳細が「エスクロー」されて、何か悪いことをして永久追放レベルになると、個人情報がバレるっていう。

└

エプスタインみたいな感じだけど、コードの中で。彼は超コネがあるから、みんなが彼を推薦するだろう。だから、彼はずっとフリーパスを得ることになる。でも、全てが吹き出すと、彼を推薦していた人たちがフラグを立てられる。主な問題は、それが爆発するまでに10年から20年かかることだよね。そうなると、良い人だけどコネがない内向的な人は入れなくなっちゃう。結局、コネがあって良い人を選んでいることになるんだ。

└

とはいえ、もしそうなら、誰かのために自分の評判を危険にさらす理由は何だろう。誰かを雇うために自分の会社を推薦するのと同じだよね - その人の助けを得られるから。あなたの提案はいいと思うよ。

└

信頼に基づくシステムはリスクを伴う場合にのみ機能する。自分のスコアは「推薦する」または「非難する」人々にリンクされるべきだ。これはグラフ検索だね。評価している人が推薦する人が、あなたが推薦する人を非難している場合、彼らが非難されていなくても、逆も然りで、あなたがその人をどれだけ信頼できるかに関する情報を得ることができる。

フォーラムのモデレーション（例えば、Discourseの信頼レベル^[1]）がソースコードリポジトリにも来るのかな？ [1]: https://blog.discourse.org/2018/06/understanding-discourse-t...

これって結局、難しい問題をコードから人にシフトさせただけじゃない？「人の質」を評価するのは簡単そうに見えるけど、実際には複雑な社会的ダイナミクスが絡んでるし、時間が経つにつれて変化も大きいよね。人間の問題を技術的な解決策で解決しようとするのは、やっぱりオタクに任せておけばいいんだよ…。

└

人間の問題を技術的な解決策で解決しようとするのは、やっぱりオタクに任せておけばいいんだよ…。正直言って、これは文化的な問題に対する技術的な解決策だと思う。特にここ10年くらいで、オープンソースは「企業のリハーサル」文化に押し込まれてる感じがする。すべてのコミュニケーションはすごくプロフェッショナルであることが求められてる。問題を提起したりPRを出したりする人には、同僚に接するように敬意を持って接しなきゃいけない。誰かを不快にさせるようなことは言わず、PG-13に留めるべき。リンスも、PRのクソコードに対する辛辣な反応を控えなきゃいけなかったくらいだし。オープンで包括的であるのは素晴らしいけど、悪質な行為者がこれを利用してるのが現実。明らかにAI生成のクソPRには「消えろ」って言って、PRを閉じて、リポジトリから追放するのが正しい反応だと思う。でも、メンテナーは企業のリハーサルの雰囲気を壊したくないから、これを直接やるのは気が引けるんだよね。だから、vouchはそれを間接的に実現する方法なんだ。

最初はこのアイデアが好きだったけど、考えれば考えるほど、結局「信頼できる人のリストからだけ貢献を許可する」ってことに行き着く気がする。

└

便利なものって、革新的だから役立つわけじゃなくて、ちゃんとデザインされて実行されてるから役立つんだよね。

└

昔のUsenetの「キルファイル」に似てるね。https://en.wikipedia.org/wiki/Kill_file ...あるいは、よく共有されてたスパムの「RBL」リストとか。https://en.wikipedia.org/wiki/Domain_Name_System_blocklist

└

これは大規模で注目度の高いプロジェクトにはもっと理にかなってるし、貢献者がコアメンテナーの信頼を得ない限り、質の低いPRをデフォルトで排除できるんだよね。

先行技術？ https://en.wikipedia.org/wiki/Advogato

「オープンソースは常に信頼と検証のシステムで動いてきた」って言うけど、信頼の部分はちょっと疑問だな。理想的には、変更をそのまま評価できるべきだと思う。私の経験では、PRを閉じるかマージするかは数秒で判断できるし、難しいのは、同じことを繰り返さないように閉じるための返答を書くことなんだよね。（私はopenpilotのPRをたくさんレビューしてるよ。https://github.com/commaai/openpilot）

└

私の経験では、PRを閉じるかマージするかは数秒で分かります。人々が高速道路で命を預けるシステムについて、こんなことを聞くのはちょっと不安だな…。

└

時間があるときはレビューし、ないときは信頼する…。

どうやって潜在的な貢献者が入り込むんだろう？ もし彼らがすでに何かに貢献していなくて、他の貢献者とネットワークもない場合は？ その分野の専門家で、実際に何かを持っているかもしれないけど、プライベートなソースでしか活動していないかも。AIがメンテナに多くの負担をかけているのは分かるけど、これが解決策とは思えないな。

└

これを見ると、特定のコードパスを拒否することで対処することを意図しているように見える。生産環境へのアクセスを拒否する感じ。でも、ステージングには変更を許可する。低い環境（他のリポジトリやロックされていないコードパス）で自分を証明して、高い環境へのアクセスを得るってことだね。実際、運用の世界ではもうやってるし。

└

OSSプロジェクトでは、PRを始める前にアイデアでイシューやディスカッションを開いてくれると嬉しいな。PRだと「このコードは動くけど、プロジェクトの他の方向性とは合わない」と言わざるを得ない awkwardな立場になることが多いから（例えば、APIデザインとか、長期的な目標に到達するのを難しくする変更とか）。

なぜnushellなの？ goじゃないの？でも、そのアイデアと原則は好きだな。OSSにはこれが必要で、あまり重視されていないよね。

次は中央カルマデータベースでお願いします。バウチ＝アップボート、デノンス＝ダウンボート。