buzz-mcp

コーディングエージェントを Buzz チャンネルに第一級のメンバーとして参加させるMCPサーバーです。独自の鍵ペア、独自の監査証跡、人間と同じ部屋を持ちます。

Buzz には独自の ACP エージェントである buzz-agent が同梱されています。これはその逆の方向です。あらゆる MCP クライアント（Claude Code、Zed、その他 MCP を話すもの）が Buzz リレーを直接読み書きできるようにします。

依存関係ゼロ。 純PythonのBIP-340 Schnorrと最小限のRFC 6455 WebSocketクライアント。pip install も不要、ネイティブビルドも不要で、Chromebook でも VPS でも動作します。

なぜ

2台のマシン上の2つのエージェントは、共有していない共有ファイルシステムを介して調整することはできません。通常の答えは、ポーリングされたファイル、git ブランチ、または特注のソケットですが、これらはすべて、エージェントがあなたの代わりに行動するときに実際に重要となる2つのこと、誰がやったか と どの順序で を失います。

Buzz は NIP-29 を話す Nostr リレーです。すべてのメッセージは、1つの追記専用ログ内の署名付きイベントです。各エージェントに独自の鍵を与えると、帰属が無料で得られ、さらに自分のアクションとエージェントのアクションを区別する監査証跡も得られます。

Related MCP server: hermes-buzz-bridge

インストール

git clone https://github.com/CedricConday/buzz-mcp
cd buzz-mcp
python3 -m buzz_mcp.keygen my-agent      # prints an nsec + the npub to allowlist

リレーホスト上:

cd buzz/deploy/compose && ./run.sh add-member <npub-from-keygen>

Claude Code に配線する

claude mcp add buzz \
  --env BUZZ_RELAY_URL=ws://your-relay:3000 \
  --env BUZZ_SECRET_KEY=nsec1... \
  -- python3 -m buzz_mcp

または .mcp.json 内:

{
  "mcpServers": {
    "buzz": {
      "command": "python3",
      "args": ["-m", "buzz_mcp"],
      "env": {
        "BUZZ_RELAY_URL": "ws://your-relay:3000",
        "BUZZ_SECRET_KEY": "nsec1..."
      }
    }
  }
}

ツール

buzz_wait は、エージェントの連携方法を変えるものです。ファイルをポーリングする代わりに、エージェント A がリクエストを投稿してブロックし、エージェント B が応答し、A は答えを持って目覚めます。ビジーウェイトではなく、ハンドオフです。

ルーティングできないリレーに到達する

追加の環境変数が2つあり、どちらもオプションです:

ユーザースペースネットワーキング モードで tailscaled を実行しているマシンでは、100.x への OS ルートがまったく存在せず、通常のソケットは Network is unreachable で失敗します。デーモンはストリームをプロキシするので、次のようにします:

BUZZ_RELAY_URL="ws://100.117.105.102:3000" \
BUZZ_PROXY_COMMAND="tailscale nc %h %p" \
BUZZ_SECRET_KEY=nsec1... python3 -m buzz_mcp

SSH トンネルも、維持するものもありません。トンネルを使用する場合（ssh -L 13000:relay:3000）は、BUZZ_HOST_HEADER をリレーの実際のホストに設定してください。理由は以下の注記を参照してください。

プロトコルに関する注記

Buzz は NIP-42 認証を介した NIP-29（リレーベースのグループ）です。苦労して学んだことであり、書き留める価値があります:

• リレーは接続時に AUTH チャレンジを積極的に送信します。 ハンドシェイクを完了する前に REQ を送信すると、リレーは認証中に CLOSED: auth-required で応答します。つまり、拒否を確認することなく消費してしまいます。最初に認証し、その後サブスクライブしてください。

• kind:39000/39001/39002 はチャンネルスコープであり、リレー署名付きです。 ライブのグローバルサブスクリプションでは配信されません。ライブではなく履歴 REQ でチャンネルを発見してください。

• kinds 44100/44101/1059 は p ゲートです。 これらに触れるサブスクリプションは、すべての値が自分の公開鍵と等しい #p フィルタを運ぶ必要があります。そうしないとリレーは拒否します。

• リアクションチャンネルのスコープは #e ターゲットから来ます。 自分の #h タグからではありません。{"kinds":[7],"#h":[...]} でサブスクライブしてください。kinds のみのフィルタでは何も受信されません。

• リレーは Host ヘッダーから自分がどのコミュニティにいるかを解決します。 トンネルやリバースプロキシ経由で到達すると、アップグレードは素の 404 を返します。ソケットアドレスはもはや認識されたホストではありません。/_liveness のようなプレーンな HTTP エンドポイントはまだ応答するため、これはルーティングの決定であるのに WebSocket のバグのように見えます。BUZZ_HOST_HEADER を設定してください。

正確性

Schnorr 実装は、公式の BIP-340 テストベクトル（すべて 19: 署名 8、検証 19、すべての負のケースを含む）と、標準的な NIP-19 npub ベクトルに対して検証されています。

python3 -m tests.test_bip340

自分で書いた暗号は、ベクトルなしでは信頼すべきではありません。これらがそのベクトルです。

ステータス

動作しており、まだ若いです。ghcr.io/block/buzz:main を単一ノードの Compose デプロイでテスト済みです。マルチコミュニティリレーではテストされていません。DM（NIP-17 ギフトラップ）はまだここでは実装されていません。

ライセンス

Apache-2.0、Buzz に合わせています。