Buzz Desktop v0.5.18: relay Nostr, dos crates de Rust, y agentes que firman como miembros — el workspace de Block para humanos y agentes
Respuesta corta (60 segundos): Buzz Desktop v0.5.18 salió el 21 de Agosto de 2026 con una ola de cambios en desktop, workflows y models. El proyecto — github.com/block/buzz, Apache 2.0, ~30k stars — sostiene que un equipo chico puede meter un coding agent al workflow sin re-arquitecturar Slack+Linear+GitHub+CI. La diferencia con el resto del ecosistema agentic es que el agente tiene su propia Nostr keypair, no un permission flag. Los dos crates centrales (buzz-agent y buzz-dev-mcp) están escritos para leerse en una tarde según el VISION_AGENT.md del repo. Si te interesa la AI infra real, no la teoría, este proyecto es el caso de estudio más interesante del mes.
1. El día que un agente se loguea como si fuera una persona
Lo que cambia con Buzz no es la UI ni el modelo. Es la identidad. En Slack un bot es un permission flag dentro de tu usuario, en Linear es un OAuth token de servicio, en GitHub es una GitHub App con permisos declarados en YAML. Si te roban el token, tienen todo. En Buzz cada agente tiene su propia Nostr keypair — un par de claves criptográficas — y entra a un canal como un miembro más, con su propio perfil, su propia presencia y su propia audit trail.
Cuando un agente escribe un mensaje, el mensaje lleva su pubkey. Cuando reacciona con un emoji, la reacción lleva su pubkey. Cuando abre un patch NIP-34, el patch lleva su pubkey. Todo firmado con la misma clase de clave que usa un humano, con el mismo flujo de verificación, con el mismo audit log.
Eso tiene dos consecuencias prácticas. La primera: podés revocar la membresía de un agente de un canal igual que revocás la de un humano — sin tocar un secret en un vault, sin rotar un token en cinco sistemas. La segunda: el audit trail es por identidad, no por service account. Si un agente borró algo a las 3am, sabés qué agente fue y desde qué sesión.
2. Una sola identidad, un solo log
El otro punto donde Buzz se separa del stack tradicional es que todo vive en un único event log firmado. Un mensaje es un evento Nostr. Una reacción es un evento Nostr. Un patch de git (NIP-34) es un evento Nostr. Un workflow step es un evento Nostr. Una aprobación es un evento Nostr. Mismo formato, misma identidad, mismo audit trail, mismo search index.
El README del repo lo dice textual: "It's a Nostr relay: every message, reaction, workflow step, review approval, and git event is a signed event in one log. Same shape, same identity model, same audit trail, whether the author is a person or a process."
El modelo de deploy por defecto es self-hosted: un relay, una comunidad, una URL. Una comunidad es el workspace al que llegás por URL — toda la información observable (perfiles, canales, mensajes, presence, audit) es local a esa comunidad. Una versión hosted multi-tenant puede servir muchas comunidades compartiendo Postgres, Redis y object storage, pero la frontera semántica se mantiene: un agente con la misma npub puede estar en dos comunidades y republicar su perfil, pero ningún estado de agente se hereda entre hosts.
3. buzz-agent: el cliente ACP en un solo crate
El corazón técnico es un par de crates que, según el VISION_AGENT.md del repo, "se pueden leer en una tarde".
buzz-agent es el cliente ACP. Habla el Agent Client Protocol (JSON-RPC 2.0 sobre stdio) con un editor (Zed, JetBrains) o con un harness (Goose, Codex, Claude Code vía buzz-acp). Llama a un LLM — Anthropic, OpenAI-compat, OpenRouter o Databricks con OAuth PKCE — y le pasa tool calls a un MCP server. Múltiples sesiones concurrentes por proceso, cada una con sus propios MCP servers, su propia historia y su propio contexto.
El default de buzz-agent es 8 sesiones concurrentes (cap configurable vía BUZZ_AGENT_MAX_SESSIONS). Cada sesión tiene su propio set de MCP servers. Si lo corrés detrás de un relay Buzz, podés tener hasta 10 agentes en paralelo, cada uno con su propia keypair y su propia configuración de MCP.
Lo que hace la diferencia es que las dos crates no se conocen entre sí: el agente no sabe qué MCP server tiene enfrente, el MCP server no sabe qué agente lo llama. Composan por protocolo, no por imports. El README de buzz-agent es bien directo sobre la filosofía: "Minimal, unbreakable ACP-compliant LLM agent. Stdio in, tool calls out. Non-streaming. No persistence. No cleverness."
4. buzz-dev-mcp: el shell con kill switch
De los dos crates, buzz-dev-mcp es el más pequeño y el más importante por seguridad. Es un MCP server que expone cuatro tools al agente: shell, str_replace, todo, más acceso a rg y tree en el PATH.
La razón por la que existe como crate separado es el process group. Cuando buzz-agent lanza buzz-dev-mcp como subproceso, hace setpgid(0,0) en pre_exec para que el MCP server y todos sus hijos compartan process group ID. Si el agente se cancela, si el transporte se rompe, si el usuario le da Ctrl-C, o si vence el timeout, buzz-agent llama killpg(SIGKILL) al grupo entero. El MCP server muere. Los procesos que el MCP server haya lanzado también mueren. Los nietos también. No hay huérfanos.
El resto del diseño va por la misma línea: output con tamaño acotado (un cat de un log gigante no puede trabar la sesión), file edits que resuelven contra el working directory (no podés str_replace un path que se escapa del cwd), y un set de tools mínimo y auditable. Si querés sumar una tool, la sumás como MCP server al lado — buzz-agent no se entera.
5. Agents como miembros, no como bots
El framing del proyecto — "Agents are members, not bots" — está en el README y se sostiene en cada decisión de diseño. La membresía es por identidad criptográfica, no por flag de permisos. Si un agente tiene la clave, es miembro. Si no la tiene, no lo es.
En la práctica eso cambia tres cosas:
- Onboarding: agregar un agente a un canal es el mismo flujo que agregar a una persona. La UI no diferencia. El agente aparece en la lista de miembros con su npub y su perfil.
- Revocación: sacar un agente de un canal es el mismo flujo que sacar a una persona. No hay que ir a un panel de OAuth a revocar un token, ni a un vault a rotar un secret. Se revoca la membresía y listo.
- Audit: cada acción del agente en el log lleva su pubkey. Si un agente borró un mensaje, el evento tiene la clave del agente. Si un agente aprobó un patch, el evento tiene la clave del agente. Si un agente deployó un workflow, el evento tiene la clave del agente.
6. Lo que está verde
El propio README es honesto sobre lo que todavía no está. Separa tres columnas:
- Works today: relay, channels, threads, DMs, canvases, media, search, audit log, desktop app (Tauri + React),
buzz-cli(agent-first, JSON in / JSON out), ACP harness (Goose, Codex, Claude Code), YAML workflows con triggers message/reaction/schedule/webhook, eventos git (NIP-34: patches, repo announcements, status), git hosting backend. - Being wired up: mobile clients iOS + Android (Flutter), workflow approval gates (la infra existe, el glue todavía está secando).
- Strong opinions, pending code: web-of-trust reputation across relays, push notifications, culture features.
El README termina con la frase literal: "Please do not plan your compliance program around the 💭 column yet." Si tu equipo necesita compliance serio hoy, mirá primero la columna Works today.
7. Cómo instalarlo y probarlo
Lo más rápido es bajar la app desktop desde la release v0.5.18. Hay builds para macOS Apple Silicon, macOS Intel, Linux (AppImage y deb) y Windows (alpha-unsigned).
Al abrir la app por primera vez se genera una Nostr keypair local — la seed queda en tu máquina, no se envía a ningún servidor. Después elegís nombre y descripción de tu comunidad y ya estás dentro.
Si querés probar buzz-agent por separado (el coding agent que habla ACP), necesitás Rust toolchain:
git clone https://github.com/block/buzz
cd buzz
cargo build --release -p buzz-agent
cargo build --release -p buzz-dev-mcp
BUZZ_AGENT_PROVIDER=anthropic \
ANTHROPIC_API_KEY=sk-ant-... \
ANTHROPIC_MODEL=claude-sonnet-4-5 \
./target/release/buzz-agent
BUZZ_AGENT_PROVIDER también acepta openai, openrouter y databricks (este último con OAuth PKCE). El agente lee frames JSON-RPC por stdin y los escribe por stdout.
Disclosure honesto: estoy escribiendo este post desde un cliente Buzz hablando con un relay local. El ciclo de iteración cierra más rápido de lo que esperaba, y la separación entre "mi sesión" y "la sesión del agente" en el audit log es exactamente el tipo de cosa que hace que valga la pena probarlo antes de opinar.
Qué cambia para tu workflow
Si venís usando Slack/Linear/GitHub + un coding agent con un wrapper por encima, lo que vas a notar las primeras semanas es que el ruido baja. No porque Buzz sea más callado — el agente hace ruido igual — sino porque la identidad deja de ser un problema operacional.
Tres cosas que probaría primero, en orden:
- Crear un canal por feature branch. Cuando abrís la branch, abrís el canal. El agente se suma y empieza a trabajar ahí. Cuando mergeás, archivás el canal. El canal queda como el registro de por qué el código existe.
- Sumar el agente con su propia keypair, no con la tuya. La identidad del agente es la del agente. Si la keypair se compromete, rotás la del agente y seguís. No rotás cinco OAuth tokens.
- Dejar que el agente abra sus propios PRs. El soporte para NIP-34 (patches como eventos firmados) está en Works today. Si tu agente puede abrir un patch firmado y vos podés reaccionar con 👍 para aprobar, tenés un loop de revisión con audit trail sin un CI toolchain extra.
Si tenés una idea de producto SaaS que toca dos o tres de estas piezas (agente + workflow + revisión), Buzz vale la pena mirarlo. Si tu proceso es 100% Slack con humanos y nunca vas a meter un agente, no es para vos — y el README es honesto al respecto.
Preguntas frecuentes
¿Qué es Buzz y por qué Block lo mantiene open source?
Buzz es un workspace self-hostable donde humanos y agentes comparten las mismas salas. Lo mantiene Block como proyecto open source en github.com/block/buzz bajo Apache 2.0, creado el 6 de marzo de 2026. La promesa es que un solo relay Nostr sostiene mensajes, reacciones, eventos de git (NIP-34), workflows y aprobaciones — todo firmado, todo en el mismo log.
¿Qué es buzz-agent y por qué está separado de buzz-dev-mcp?
buzz-agent es el cliente ACP: habla Agent Client Protocol (JSON-RPC 2.0 sobre stdio) con un editor o harness, llama a un LLM, y le pasa tool calls a un MCP server. buzz-dev-mcp es el MCP server que le da shell, str_replace, todo y rg/tree al agente, con process-group kill en cada salida. Son dos crates con cero acoplamiento entre sí: el agente no sabe qué MCP server tiene enfrente, el MCP server no sabe qué agente lo está llamando. Composan por protocolo, no por imports.
¿Cuántos agentes puedo correr en paralelo?
El default de buzz-agent es 8 sesiones ACP concurrentes por proceso, cada una con sus propios MCP servers y su propio contexto (cap configurable vía BUZZ_AGENT_MAX_SESSIONS). Detrás de un relay Buzz podés levantar hasta 10 agentes en paralelo, cada uno con su propia keypair y su propia configuración de MCP — y cada comunidad Buzz mantiene el aislamiento de memberships, jobs, DMs, perfil y presence aunque compartan Postgres, Redis u object storage.
¿En qué se diferencia de Slack+Linear+GitHub+Cursor con un wrapper?
En la identidad. En Slack/Linear/GitHub el bot es un permission flag dentro de tu usuario o un OAuth token de servicio: si te lo roban, roban todo. En Buzz cada agente tiene su propia Nostr keypair, scoped por identidad igual que un teammate. Un agente entra a un canal como un miembro, se va como un miembro, y todo lo que firmó queda firmado bajo su clave. El audit trail es por identidad, no por service account.
¿Vale la pena para un equipo chico, o es para empresas grandes?
Por la pinta del proyecto, parece pensado para equipos chicos que quieren meter un agente al workflow sin re-arquitecturar Slack+Linear+GitHub+CI. Los dos crates centrales se leen en una tarde según el VISION_AGENT.md del repo — un senior engineer los puede auditar con confianza. Si tu equipo es chico y querés sumar un coding agent que escriba PRs, abra issues y cierre issues por su cuenta, Buzz encaja. Si ya tenés un Monarch-stack interno o tu equipo es 50+ personas con procesos Compliance serios, probablemente mirás primero la columna 💭 del README antes de planificar nada alrededor.
¿Qué está verde todavía?
El propio README separa tres columnas: Works today (relay, canales, threads, DMs, canvases, media, search, audit log, desktop app, buzz-cli, ACP harness, YAML workflows, eventos git NIP-34, git hosting backend), Being wired up (mobile clients iOS+Android con Flutter, workflow approval gates) y Strong opinions, pending code (web-of-trust reputation, push notifications, culture features). El README termina con la frase literal: "Please do not plan your compliance program around the 💭 column yet."
¿Cómo lo instalo?
Para la app desktop, bajá el build correspondiente a tu plataforma desde la release v0.5.18 en github.com/block/buzz/releases/tag/desktop-v0.5.18 — hay .dmg para macOS (aarch64 y x64), .AppImage y .deb para Linux, y .exe para Windows. Para el CLI + ACP, seguí las instrucciones del README principal; necesitás Rust toolchain y exportás BUZZ_AGENT_PROVIDER + la API key correspondiente (Anthropic, OpenAI-compat, OpenRouter o Databricks con OAuth PKCE).