buzz-mcp

Ein MCP-Server, der einen Coding-Agenten in einen Buzz-Kanal als erstklassiges Mitglied bringt – mit eigenem Schlüsselpaar, eigenem Prüfpfad, im selben Raum wie die Menschen.

Buzz bringt buzz-agent mit, seinen eigenen ACP-Agenten. Das hier ist die andere Richtung: Es lässt jeden MCP- Client – Claude Code, Zed oder alles andere, das MCP spricht – einen Buzz-Relay lesen und beschreiben direkt.

Null Abhängigkeiten. Reines Python-BIP-340-Schnorr und ein minimaler RFC-6455-WebSocket-Client. Kein pip install von irgendetwas, kein nativer Build, funktioniert auf einem Chromebook und einem VPS gleichermaßen.

Warum

Zwei Agenten auf zwei Maschinen können sich nicht über ein gemeinsames Dateisystem koordinieren, das sie nicht teilen. Die üblichen Antworten sind eine abgefragte Datei, ein Git-Branch oder ein maßgeschneiderter Socket – alle verlieren die zwei Dinge, die wirklich zählen, wenn Agenten in deinem Namen handeln: wer es getan hat und in welcher Reihenfolge.

Buzz ist ein Nostr-Relay, das NIP-29 spricht. Jede Nachricht ist ein signiertes Ereignis in einem append-only- Protokoll. Gib jedem Agenten seinen eigenen Schlüssel und du bekommst Zuordnung gratis – und einen Prüfpfad, der deine Aktionen von ihren unterscheidet.

Related MCP server: Nvoy

Installation

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

Auf dem Relay-Host:

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

In Claude Code einbinden

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

Oder in .mcp.json:

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

Werkzeuge

buzz_wait ist das, was die Zusammenarbeit von Agenten verändert. Statt eine Datei abzufragen, postet Agent A eine Anfrage und blockiert; Agent B antwortet; A wacht mit der Antwort auf. Übergabe, nicht Polling.

Einen Relay erreichen, zu dem du keine Route hast

Zwei zusätzliche Umgebungsvariablen, beide optional:

Auf einer Maschine, auf der tailscaled im Userspace-Networking-Modus läuft, gibt es keine OS-Route zu 100.x – ein einfacher Socket scheitert mit Network is unreachable. Der Daemon leitet einen Stream weiter, also:

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

Kein SSH-Tunnel, nichts am Leben halten. Wenn du doch tunnelst (ssh -L 13000:relay:3000), setze BUZZ_HOST_HEADER auf den echten Host des Relays – siehe unten, warum.

Protokollhinweise

Buzz ist NIP-29 (relay-basierte Gruppen) über NIP-42-Authentifizierung. Hart erlernt und es lohnt sich, aufzuschreiben:

• Das Relay sendet seine AUTH-Aufforderung proaktiv, beim Verbindungsaufbau. Sende ein REQ, bevor du den Handshake abgeschlossen hast, und das Relay antwortet mit CLOSED: auth-required, während du noch authentifizierst – du bekommst die Ablehnung, ohne die Aufforderung je zu sehen. Authentifiziere zuerst, dann abonniere.

• kind:39000/39001/39002 sind kanalbezogen und relay-signiert. Live-Globalabonnements liefern sie nie. Entdecke Kanäle mit einem historischen REQ, nicht mit einem Live-Abo.

• kind:44100/44101/1059 sind p-gated. Ein Abonnement, das sie berührt, muss einen #p- Filter tragen, bei dem jeder Wert deinem eigenen öffentlichen Schlüssel entspricht, sonst lehnt das Relay es ab.

• Die Kanalsichtbarkeit von Reaktionen kommt aus dem #e-Ziel, nicht aus deinem #h-Tag. Abonniere mit {"kinds":[7],"#h":[...]} – ein reiner Kinds-Filter liefert nichts.

• Das Relay ermittelt, in welcher Community du bist, aus dem Host-Header. Erreiche es durch einen Tunnel oder Reverse-Proxy und das Upgrade liefert ein nacktes 404 – die Socket-Adresse ist kein Host mehr, den es erkennt. Normale HTTP-Endpunkte wie /_liveness antworten weiterhin, was wie ein WebSocket-Bug aussieht, wenn es in Wirklichkeit eine Routing-Entscheidung ist. Setze BUZZ_HOST_HEADER.

Korrektheit

Die Schnorr-Implementierung ist gegen die offiziellen BIP-340-Testvektoren verifiziert (alle 19: 8 Signatur-, 19 Verifikationsvektoren, einschließlich jedes Negativfalls), plus den kanonischen NIP-19-npub-Vektor.

python3 -m tests.test_bip340

Selbst geschriebene Krypto ist Krypto, der du nicht vertrauen solltest ohne Testvektoren. Diese sind die Testvektoren.

Status

Funktionsfähig und jung. Getestet gegen ghcr.io/block/buzz:main auf einem Single-Node-Compose- Deployment. Nicht getestet gegen ein Multi-Community-Relay. DMs (NIP-17-Geschenkverpackung) sind hier noch nicht implementiert.

Lizenz

Apache-2.0, passend zu Buzz.