Block、Buzzをオープンソース化し、Nostr署名イベントでAIエージェント、会話、Git監査ログを統合

BlockはBuzzのデスクトップクライアント、relay、CLI、エージェントharnessを公開し、チームチャット、Gitリポジトリ、エージェントワークフローを、セルフホスト可能な単一のワークスペースに集約しようとしている。ボットを人間のアカウントに紐付ける方式とは異なり、各エージェントは独立した鍵、チャンネルメンバーシップ、アクティビティログを持ち、リポジトリを開き、patchを提案し、コードをレビューし、ワークフローを実行し、さらには他のエージェントを調整できる。

Buzzの中核は、別のメッセージ用データベーステーブルではなく、Nostr形式の署名イベントログだ。メッセージ、reaction、Gitイベント、承認、ワークフローのステップは、すべて同じイベントモデルでrelayに書き込まれ、作成者は人間でもプログラムでもよい。理論上、監査システムは公開鍵をたどることで、どのエージェントが操作を生成したかを確認でき、共有サービスアカウントやモデルプロバイダーのチャットログに依存する必要がない。このプロジェクトはRustやTypeScriptなどのコンポーネントで構成され、macOS、Windows、Linux向けパッケージを提供するほか、Dockerを使って独自のrelayを起動することもできる。

エージェント統合はモデルとharnessに依存しない方針を採っており、Claude Code、Codex、Blockのgoose、または独自開発のエージェントを接続できる。この設計が企業導入において真に価値を持つのは、アイデンティティ、権限、作業成果をエージェント自体に紐付けられる点だ。異なるエージェントに異なる鍵とチャンネルスコープを割り当てれば、特定のエージェントを失効させる際に人間の認証情報まで同時にローテーションする必要がなく、モデルの提案、ツールの実行、人間による承認も区別しやすくなる。

ただし、署名で証明できるのは、ある鍵がイベントを送信したという事実だけであり、その背後にあるモデルの安全性や出力の正確性までは証明できない。現在の単一relayアーキテクチャには、relay間のフェデレーション、レプリケーション、フェイルオーバーがない。Blockがホストするrelay上のメッセージとメディアもエンドツーエンド暗号化されておらず、外部のモデルプロバイダーにチャンネルのコンテキストが送られる可能性も残る。モバイル対応、プッシュ通知、完全な承認ゲートもまだ成熟していない。エンジニアリングチームは当面、Buzzを検証可能なエージェント協働のプロトタイプと位置付け、鍵の保管、きめ細かな認可、データ保持、relayの災害復旧を重点的にテストすべきだ。