Buzz Desktop v0.5.18: a Nostr relay, two Rust crates, and agents that sign as members — Block's workspace for humans and agents
Short answer (60 seconds): Buzz Desktop v0.5.18 shipped on August 21, 2026 with a wave of changes across desktop, workflows, and models. The project — github.com/block/buzz, Apache 2.0, ~30k stars — argues that a small team can put a coding agent in the workflow without re-architecting Slack+Linear+GitHub+CI. The difference from the rest of the agentic ecosystem is that the agent has its own Nostr keypair, not a permission flag. The two core crates (buzz-agent and buzz-dev-mcp) are written to be readable in an afternoon per the repo's VISION_AGENT.md. If you care about real AI infra rather than theory, this is the most interesting case study of the month.
1. The day an agent logs in like a person
What changes with Buzz is neither the UI nor the model. It is the identity model. In Slack a bot is a permission flag inside your user, in Linear it is an OAuth service token, in GitHub it is a GitHub App with permissions declared in YAML. If the token leaks, everything leaks. In Buzz every agent has its own Nostr keypair — a cryptographic key pair — and joins a channel as a member, with its own profile, its own presence, and its own audit trail.
When an agent writes a message, the message carries its pubkey. When it reacts with an emoji, the reaction carries its pubkey. When it opens a NIP-34 patch, the patch carries its pubkey. All signed with the same class of key a human uses, with the same verification flow, with the same audit log.
Two practical consequences follow. First: you revoke an agent's membership in a channel the same way you revoke a human's — no vault secret to touch, no token to rotate across five systems. Second: the audit trail is per identity, not per service account. If an agent deleted something at 3am, you know which agent and from which session.
2. One identity, one log
The other place Buzz diverges from the traditional stack is that everything lives in a single signed event log. A message is a Nostr event. A reaction is a Nostr event. A git patch (NIP-34) is a Nostr event. A workflow step is a Nostr event. An approval is a Nostr event. Same shape, same identity, same audit trail, same search index.
The repo README puts it bluntly: "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."
The default deploy model is self-hosted: one relay, one community, one URL. A community is the workspace you reach by URL — all observable state (profiles, channels, messages, presence, audit) is local to that community. A hosted multi-tenant deployment can serve many communities sharing Postgres, Redis, and object storage, but the semantic boundary holds: an agent with the same npub can join two communities and repost its profile, but no agent state is inherited across hosts.
3. buzz-agent: the ACP client in a single crate
The technical core is a pair of crates that, per the repo's VISION_AGENT.md, "can be read in an afternoon."
buzz-agent is the ACP client. It speaks the Agent Client Protocol (JSON-RPC 2.0 over stdio) with an editor (Zed, JetBrains) or with a harness (Goose, Codex, Claude Code via buzz-acp). It calls an LLM — Anthropic, OpenAI-compat, OpenRouter, or Databricks with OAuth PKCE — and forwards tool calls to an MCP server. Multiple concurrent sessions per process, each with its own MCP servers, history, and context.
The buzz-agent default is 8 concurrent sessions (cap configurable via BUZZ_AGENT_MAX_SESSIONS). Each session has its own set of MCP servers. Run it behind a Buzz relay and you can have up to 10 agents in parallel, each with its own keypair and its own MCP configuration.
The differentiator is that the two crates know nothing about each other: the agent does not know which MCP server sits in front of it, the MCP server does not know which agent is calling. They compose through protocol, not imports. The buzz-agent README states the philosophy directly: "Minimal, unbreakable ACP-compliant LLM agent. Stdio in, tool calls out. Non-streaming. No persistence. No cleverness."
4. buzz-dev-mcp: the shell with a kill switch
Of the two crates, buzz-dev-mcp is the smaller and the more important one for safety. It is an MCP server that exposes four tools to the agent: shell, str_replace, todo, plus access to rg and tree on the PATH.
The reason it exists as a separate crate is the process group. When buzz-agent spawns buzz-dev-mcp as a child process, it calls setpgid(0,0) in pre_exec so the MCP server and all its descendants share a process group ID. If the agent cancels, if the transport breaks, if the user hits Ctrl-C, or if a timeout fires, buzz-agent calls killpg(SIGKILL) on the whole group. The MCP server dies. Any processes the MCP server spawned die. The grandchildren die too. No orphans.
The rest of the design follows the same line: bounded output size (a cat of a giant log cannot stall the session), file edits resolved against the working directory (you cannot str_replace a path that escapes the cwd), and a minimal, auditable tool surface. Want a new tool? Add it as an MCP server next door — buzz-agent never finds out.
5. Agents as members, not bots
The project framing — "Agents are members, not bots" — appears in the README and shows up in every design decision. Membership is by cryptographic identity, not by permission flag. If the agent has the key, it is a member. If it does not, it is not.
In practice that changes three things:
- Onboarding: adding an agent to a channel is the same flow as adding a person. The UI does not differentiate. The agent shows up in the member list with its npub and its profile.
- Revocation: removing an agent from a channel is the same flow as removing a person. No OAuth panel to revoke a token, no vault to rotate a secret. Revoke the membership and move on.
- Audit: every agent action in the log carries its pubkey. If an agent deleted a message, the event carries the agent's key. If an agent approved a patch, the event carries the agent's key. If an agent deployed a workflow, the event carries the agent's key.
For a small SaaS team putting its first coding agent in the workflow, that lowers the barrier from "build an internal Monarch-grade permission stack" to "give the agent a keypair and add it to the channel like anyone else."
6. What is still green
The README is honest about what is not done yet. It splits three columns:
- 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 with message/reaction/schedule/webhook triggers, git events (NIP-34: patches, repo announcements, status), git hosting backend. - Being wired up: mobile clients iOS + Android (Flutter), workflow approval gates (infra exists, glue still drying).
- Strong opinions, pending code: web-of-trust reputation across relays, push notifications, culture features.
The README closes with the literal line: "Please do not plan your compliance program around the 💭 column yet." If your team needs serious compliance today, look at the Works today column first.
7. How to install and try it
The fastest path is to grab the desktop app from the v0.5.18 release. Builds ship for macOS Apple Silicon, macOS Intel, Linux (AppImage and deb), and Windows (alpha-unsigned).
When you open the app for the first time it generates a Nostr keypair locally — the seed stays on your machine, nothing is sent to a server. Then you pick a name and description for your community and you are in.
If you want to try buzz-agent on its own (the coding agent that speaks ACP), you need the 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 also accepts openai, openrouter, and databricks (the last one with OAuth PKCE). The agent reads JSON-RPC frames from stdin and writes them to stdout.
Honest disclosure: I am writing this post from a Buzz client talking to a local relay. The iteration loop closes faster than I expected, and the split between "my session" and "the agent's session" in the audit log is exactly the kind of thing worth trying before forming an opinion.
What changes for your workflow
If you currently run Slack/Linear/GitHub plus a coding agent with a wrapper on top, what you will notice in the first weeks is that the operational noise drops. Not because Buzz is quieter — the agent makes just as much noise — but because identity stops being an operational problem.
Three things I would try first, in order:
- Open a channel per feature branch. Open the branch, open the channel. The agent joins and starts working there. When you merge, archive the channel. The channel becomes the record of why the code exists.
- Add the agent with its own keypair, not yours. The agent's identity is the agent's. If the keypair gets compromised, rotate the agent's key and move on. You do not rotate five OAuth tokens.
- Let the agent open its own PRs. NIP-34 support (patches as signed events) is in Works today. If your agent can open a signed patch and you can react with 👍 to approve it, you have a review loop with an audit trail and no extra CI toolchain.
If you have a SaaS product idea that touches two or three of these pieces (agent + workflow + review), Buzz is worth a look. If your process is 100% Slack with humans and you will never add an agent, it is not for you — and the README is honest about that.
Frequently asked questions
What is Buzz and why does Block maintain it as open source?
Buzz is a self-hostable workspace where humans and agents share the same rooms. Block maintains it as an open-source project at github.com/block/buzz under Apache 2.0, created on March 6, 2026. The bet is that a single Nostr relay holds messages, reactions, git events (NIP-34), workflows, and approvals — all signed, all in the same log.
What is buzz-agent and why is it separate from buzz-dev-mcp?
buzz-agent is the ACP client: it speaks the Agent Client Protocol (JSON-RPC 2.0 over stdio) with an editor or harness, calls an LLM, and forwards tool calls to an MCP server. buzz-dev-mcp is the MCP server that gives the agent shell, str_replace, todo, and rg/tree, with process-group kill on every exit. The two crates have zero coupling: the agent does not know which MCP server is in front of it, the MCP server does not know which agent is calling. They compose through protocol, not imports.
How many agents can I run in parallel?
buzz-agent defaults to 8 concurrent ACP sessions per process, each with its own MCP servers and context (cap configurable via BUZZ_AGENT_MAX_SESSIONS). Behind a Buzz relay you can run up to 10 agents in parallel, each with its own keypair and its own MCP configuration — and each Buzz community keeps memberships, jobs, DMs, profile, and presence isolated even when the backend shares Postgres, Redis, and object storage.
How is this different from Slack+Linear+GitHub+Cursor with a wrapper?
The identity model. In Slack/Linear/GitHub a bot is a permission flag inside your user account or an OAuth service token: if it leaks, everything leaks. In Buzz every agent has its own Nostr keypair, scoped by identity the same way a teammate is. An agent joins a channel as a member, leaves as a member, and everything it signed stays signed under its key. The audit trail is per identity, not per service account.
Is it worth it for a small team, or is it for big enterprises?
From the project's posture, it looks aimed at small teams that want to put an agent in the workflow without re-architecting Slack+Linear+GitHub+CI. The two core crates are readable in an afternoon per VISION_AGENT.md — a senior engineer can audit them with confidence. If your team is small and you want to add a coding agent that opens PRs, files issues, and closes issues on its own, Buzz fits. If you already have a Monarch-grade internal stack, or your team is 50+ people with serious Compliance processes, look at the 💭 column of the README before you plan anything around it.
What is still green?
The README itself separates three columns: Works today (relay, channels, threads, DMs, canvases, media, search, audit log, desktop app, buzz-cli, ACP harness, YAML workflows, git events NIP-34, git hosting backend), Being wired up (mobile clients iOS+Android on Flutter, workflow approval gates), and Strong opinions, pending code (web-of-trust reputation across relays, push notifications, culture features). The README closes with the literal line: "Please do not plan your compliance program around the 💭 column yet."
How do I install it?
For the desktop app, download the build for your platform from the v0.5.18 release at github.com/block/buzz/releases/tag/desktop-v0.5.18 — there are .dmg files for macOS (aarch64 and x64), .AppImage and .deb for Linux, and a .exe for Windows. For the CLI + ACP, follow the instructions in the main README; you need the Rust toolchain and you export BUZZ_AGENT_PROVIDER plus the matching API key (Anthropic, OpenAI-compat, OpenRouter, or Databricks with OAuth PKCE).