buzz-mcp

Un servidor MCP que mete a un agente de codificación en un canal de Buzz como miembro de pleno derecho: su propio par de claves, su propio rastro de auditoría, la misma sala que los humanos.

Buzz incluye buzz-agent, su propio agente ACP. Esta es la otra dirección: permite que cualquier cliente MCP — Claude Code, Zed o cualquier otra cosa que hable MCP — lea y escriba directamente en un relay de Buzz.

Cero dependencias. Schnorr BIP-340 en Python puro y un cliente WebSocket RFC 6455 mínimo. Nada de pip install de nada, sin compilación nativa, funciona tanto en un Chromebook como en un VPS.

Por qué

Dos agentes en dos máquinas no pueden coordinarse a través de un sistema de archivos compartido que no comparten. Las respuestas habituales son un archivo sondeado, una rama de git o un socket a medida — todas pierden las dos cosas que de verdad importan cuando los agentes actúan en tu nombre: quién lo hizo y en qué orden.

Buzz es un relay de Nostr que habla NIP-29. Cada mensaje es un evento firmado en un único registro de solo añadir. Dale a cada agente su propia clave y obtienes la atribución gratis — y un rastro de auditoría que distingue tus acciones de las suyas.

Related MCP server: hermes-buzz-bridge

Instalación

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

En el host del relay:

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

Conéctalo a Claude Code

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

O en .mcp.json:

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

Herramientas

buzz_wait es el que cambia la forma en que los agentes trabajan juntos. En lugar de sondear un archivo, el agente A publica una solicitud y se bloquea; el agente B responde; A se despierta con la respuesta. Traspaso, no espera activa.

Alcanzar un relay al que no puedes enrutar

Dos variables de entorno adicionales, ambas opcionales:

En una máquina que ejecuta tailscaled en modo userspace-networking no hay ninguna ruta del sistema operativo hacia 100.x — un socket simple falla con Network is unreachable. El daemon hará de proxy de un flujo, así que:

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

Sin túnel SSH, nada que mantener vivo. Si de verdad usas un túnel (ssh -L 13000:relay:3000), establece BUZZ_HOST_HEADER al host real del relay — consulta la nota siguiente sobre el porqué.

Notas de protocolo

Buzz es NIP-29 (grupos basados en relay) sobre autenticación NIP-42. Lo aprendimos por las malas y merece la pena dejarlo escrito:

• El relay envía su desafío AUTH de forma proactiva, al conectar. Si envías un REQ antes de completar el handshake, el relay responde con CLOSED: auth-required mientras aún te estás autenticando — consumes el rechazo sin llegar a verlo. Autentícate primero y luego suscríbete.

• kind:39000/39001/39002 están limitados al canal y firmados por el relay. Las suscripciones globales en vivo nunca los entregan. Descubre los canales con un REQ histórico, no uno en vivo.

• los kinds 44100/44101/1059 están restringidos por p. Una suscripción que los toque debe llevar un filtro #p donde cada valor sea igual a tu propia pubkey, o el relay lo rechaza.

• El ámbito de canal de las reacciones proviene del objetivo #e, no de tu etiqueta #h. Suscríbete con {"kinds":[7],"#h":[...]} — un filtro solo de kinds no recibe nada.

• El relay determina en qué comunidad estás a partir de la cabecera Host. Si llegas a través de un túnel o un proxy inverso, la actualización devuelve un 404 puro — la dirección del socket ya no es un host que reconozca. Los endpoints HTTP simples como /_liveness siguen respondiendo, lo que hace que esto parezca un bug de WebSocket cuando en realidad es una decisión de enrutamiento. Establece BUZZ_HOST_HEADER.

Corrección

La implementación de Schnorr está verificada contra los vectores de prueba oficiales de BIP-340 (todos los 19: 8 de firma, 19 de verificación incluyendo todos los casos negativos), además del vector canónico npub de NIP-19.

python3 -m tests.test_bip340

La criptografía que escribes tú mismo es criptografía en la que no deberías confiar sin vectores. Estos son los vectores.

Estado

Funciona, y es joven. Probado contra ghcr.io/block/buzz:main en un despliegue Compose de un solo nodo. No probado contra un relay multicomunidad. Los DMs (NIP-17 gift wrap) aún no están implementados aquí.

Licencia

Apache-2.0, igual que Buzz.