Buzz: A self-hostable Nostr relay that turns agents into team members

What Buzz actually is

Buzz is a self-hostable workspace that runs on a Nostr relay. The README is blunt about the premise: every message, reaction, workflow step, review approval, and git event is a signed event in one log. Humans and agents use the same identity model, the same keypairs, and the same audit trail. The target user is a team that wants agents to do real work, not just chat. Agents can open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, and join voice huddles. The difference from a typical bot integration is that the agent is a member of the room, not a script bolted on the side. The project is written in Rust, licensed under Apache-2.0, and ships a desktop app, a CLI, and a relay. The repository is active, with recent releases like desktop-v0.5.20 from August 2026.

The one-log substrate: Nostr events as the universal unit

The architecture is built around Nostr events. A patch is a NIP-34 event, a CI result is an event, a review approval is an event, and a chat message is an event. They all land in the same search index. This is not a chat app with a sidecar database. The README claims that search covers the conversation, the patch, the workflow run, and the approval in one place because they are all the same kind of thing. That uniformity has a real consequence: agents can query six months of history and post threads as answers, with receipts. The identity model is also uniform. Agents have their own keys, their own channel memberships, and their own audit trail. Scoping is by identity, not by permission flags. The README compares it to scoping a human teammate. This design choice means there is no separate permission system for agents; they get the same surface area as humans. That is either elegant or unsettling, depending on how much you trust your agents.

Getting it running: from packaged builds to a hosted relay

The README offers two paths. For trying the app, grab a packaged build from the latest release. There are DMGs for macOS (Apple Silicon and Intel), an AppImage or deb for Linux x86_64, and an unsigned Windows x64 installer. The Windows build is not code-signed, so SmartScreen will warn on first launch. The app defaults to ws://localhost:3000. To point it at a different relay, set BUZZ_RELAY_URL before launching, or switch the relay from inside the app. For a hosted relay without managing servers, the README mentions deploying to Railway in one click, though the link is truncated in the README. If you want to run from source, the README points to a build-and-run path, but the specific commands are in the truncated section. The CLI, buzz-cli, is agent-first, with JSON in and JSON out, and there is an ACP harness for Goose, Codex, and Claude Code. So the practical entry point is either a packaged desktop app or a Railway deploy, not a manual server setup.

What works today versus what is still wiring up

The README has a clear table of status. Works today: relay, channels, threads, DMs, canvases, media, search, audit log, the desktop app (Tauri + React), buzz-cli with the ACP harness, YAML workflows with message, reaction, schedule, and webhook triggers, git events (NIP-34), and a git hosting backend. Being wired up: mobile clients (iOS and Android via Flutter), workflow approval gates (infra exists but glue is still drying), and huddle lifecycle events. Strong opinions but pending code: web-of-trust reputation across relays, push notifications, and culture features. The README warns not to plan a compliance program around the pending column. This is a useful honesty. It means the core event log is solid, but the edges, especially mobile and approval gates, are not ready for production. If your team lives on mobile, Buzz is not the tool yet.

The single-relay, single-community constraint

The README describes the client-facing rule: the relay URL selects exactly one community. In the default self-hosted setup, one relay hosts one community. A hosted operator can serve many communities behind many domains or subdomains, but the tenant-observable state under a URL is community-local. This is a deliberate boundary. It means you cannot have two teams sharing one relay and seeing each other's data, unless you run separate relays or use a multi-tenant hosting setup. The trade-off is isolation versus simplicity. For a small team, this is fine. For an organization that wants a single infrastructure for multiple projects, you need either multiple relays or a hosted operator. The README positions this as a feature: one community, one identity model, one event log. But it is also a limitation if you want cross-community search or shared agents. The web-of-trust reputation across relays is explicitly in the pending column, so cross-relay trust does not exist yet.

The agent story: scoped by identity, not permissions

The README's key claim is that agents are members, not bots. You add an agent to a channel the same way you add a person. Agents have their own keys, their own channel memberships, and their own audit trail. This is different from giving an agent a global API token with permission flags. The scoping is by identity, which means an agent's access is limited to the channels it belongs to, just like a human. The README gives an example: an agent can triage a bug without getting the keys to the kingdom. It searches history, posts threads, and offers to page the person who shipped the last one. The whole exchange stays in the channel. This identity-based scoping is a real architectural choice. It avoids the common failure of agents having too broad access because they were added to a system, not to a room. But it also means you must be disciplined about which channels you add an agent to. The audit trail helps, but the design assumes you trust the agent's keypair.

Alternatives and the difference in approach

The closest alternative is a traditional team chat with bot integrations, like Slack or Discord with custom bots. Those tools treat agents as external processes that call APIs. Buzz treats agents as native participants in an event log. The difference is not cosmetic. In Slack, a bot's messages are separate from the conversation history, and its actions (like opening a PR) are logged in a different system. In Buzz, the patch, the review, the CI result, and the chat message are all events in the same log, searchable together. Another alternative is a dedicated agent orchestration platform, which typically has its own workflow engine and a separate chat UI. Buzz folds the workflow engine into the relay itself, using YAML workflows triggered by messages, reactions, schedules, or webhooks. The trade-off is that Buzz is less mature than those platforms. The workflow approval gates are still being wired up, and the mobile clients are not done. So if you need a battle-tested agent workflow system today, Buzz may not be ready.

Maintenance, licensing, and what to verify before adopting

The project is under Apache-2.0, which is permissive and allows commercial use without copyleft obligations. The repository is active, with releases roughly every few days in August 2026, so maintenance appears ongoing. The README includes a RELEASING.md, which suggests a documented release process. The desktop app is Tauri + React, and the relay is Rust, so the maintenance cost is split between Rust backend and web frontend skills. The Windows build is unsigned, which is a practical hurdle for enterprise deployment. The workflow approval gates are not fully finished, so if you need human approval before merges, verify the current state of that feature before relying on it. Also verify how the relay handles multi-tenant deployments if you plan to serve multiple communities. The README says the infrastructure exists, but the client-facing rule is URL-based, so you need to understand the hosting model. Finally, the mobile clients are not ready, so if your team uses phones, Buzz is not a complete solution.

Editorial conclusion

Adopt Buzz if you want a self-hosted workspace where agents act as first-class members with their own keys and audit trails, and you are comfortable with Nostr's event model. Do not adopt it if you need mobile clients, push notifications, or cross-relay reputation today, as those are still in progress. Before committing, verify that the single-relay, single-community model fits your team structure, and check the current state of workflow approval gates and the Windows build's unsigned status.

Official sources

1. Official README
2. Project repository
3. Release notes