block/buzz: a self-hosted Nostr workspace where agents are members, not bots

The problem block/buzz picks: seven tabs that do not know about each other

Most teams already have a chat tool, a forge, a CI dashboard, a search index and a release script. None of them share an identity model. An agent that triages a bug in chat has no way to attach its reasoning to the patch, the CI run, or the approval that let the patch merge. Buzz's answer is to make all of those things the same kind of object: a signed event in one log. The README puts it plainly, saying every message, reaction, workflow step, review approval and git event is a signed event, with the same identity model whether the author is a person or a process. A Buzz community is whatever workspace you reach at a given URL, and in the single-relay setup that ships today the relay URL selects exactly one community.

The audience is narrower than the tagline suggests. This is for a team that already runs its own infrastructure and wants agent activity to be auditable by construction rather than by a permission flag. The README's second bullet makes the design intent explicit: agents get their own keys and channel memberships, scoped by identity rather than by a role system. If your agents are haunted cron jobs with a shared bot token, that difference is the whole pitch.

One event log under the hood: relay, Postgres, Redis and a git backend

Buzz is a Nostr relay written in Rust. The workspace Cargo.toml lists the crates that make up the system, and the names map to the architecture: buzz-relay, buzz-core, buzz-db, buzz-pubsub, buzz-auth, buzz-search, buzz-audit, buzz-workflow, buzz-media, buzz-voice, buzz-acp, buzz-agent, buzz-cli and buzz-sdk, among others. There is no single monolith binary that does everything; the crates are split along the seams you would expect for an event-sourced system with search, audit and push on the side.

The data flow follows from that. Clients speak Nostr over WebSocket. The relay persists events through buzz-db into Postgres, fans out live updates through buzz-pubsub on Redis, indexes them with buzz-search, and records them with buzz-audit. Git is not reimplemented in Rust: the Dockerfile comment states that the relay shells out to git for repo hydrate, receive-pack and upload-pack, so the runtime image includes the git binary. Patches and repo announcements arrive as NIP-34 events, which is why a feature branch can be rendered as a channel rather than as a separate forge page.

Two consequences are worth stating. First, search spans chat, patches, workflow runs and approvals because they are the same event type, which the README calls out as a feature. Second, the operational surface is real: Postgres 17, Redis 7, and a relay process that needs git on PATH. The docker-compose.yml in the repository pins the first two and adds adminer and keycloak for local development.

Installing block/buzz: packaged desktop build or docker compose

There are two entry points, and the README separates them by intent. If you only want to see the app, download a packaged build from the latest release. The README gives the file names per platform: Buzz_<version>_aarch64.dmg for Apple Silicon, Buzz_<version>_x64.dmg for Intel Macs, Buzz_<version>_amd64.AppImage or Buzz_<version>_amd64.deb for Linux x86_64, and Buzz_<version>_x64-setup_alpha-unsigned.exe for Windows. The Windows build is not code-signed, so the README warns that SmartScreen may show a warning on first launch and tells you to click More info, then Run anyway.

The desktop app defaults to a local relay. The README states that by default the app connects to ws://localhost:3000, and that you can point it elsewhere by setting BUZZ_RELAY_URL before launching or by switching the relay inside the app. If you have no relay yet, the README points you at building from source.

For a local relay, the repository ships a compose file. This brings up Postgres, Redis, adminer and keycloak:

docker compose up -d

Postgres listens on 127.0.0.1:5432 with user buzz, password buzz_dev and database buzz, per docker-compose.yml. Redis listens on 127.0.0.1:6379. Adminer is exposed on 127.0.0.1:8082 and points at the postgres service by default. All four services carry a com.buzz.env label set to dev, which is the repository telling you this file is not a production deployment.

If you would rather not manage servers, the README offers a one-click deploy of a relay to Railway. The README does not document what that template provisions, so treat the resulting relay as something to inspect before you put real work in it.

Where block/buzz is the wrong tool right now

The README contains a table that most project pages would have hidden. It splits the product into three columns: what works today, what is being wired up, and what is still an opinion pending code. Relay, channels, threads, DMs, canvases, media, search and the audit log are in the first column. Mobile clients for iOS and Android, workflow approval gates, and huddle lifecycle events are in the second. Web-of-trust reputation across relays, push notifications and culture features are in the third, under a note asking you not to plan a compliance program around that column yet.

That is unusually candid, and it should drive your decision. A team that needs a phone client today is out of scope, because the Flutter mobile directory exists but the README lists mobile as not finished. A team that needs approval gates to block a merge today should check the glue themselves; the README says the infrastructure exists but the glue is still drying. And a team that needs a signed audit trail for regulatory purposes should read the same warning the README gives.

The other limitation is structural rather than temporary. One relay serves one community in the default self-hosted deployment. A hosted operator can serve many communities behind many subdomains, but the client-facing rule stays the same: the URL is authoritative. If your model is a single account spanning many unrelated organizations, this is not that model.

How block/buzz differs from Slack and from a plain Nostr relay

Against Slack, the difference is not the chat. It is that the channel becomes the record of why the code exists. The README's branch-as-room story describes a feature branch producing a channel, patches landing as NIP-34 events, CI posting results, an agent running a first-pass review, and the merge decision landing in the same room as the evidence. Slack can host the conversation and the CI bot, but the patch, the approval and the conversation are three systems with three identity models. Buzz's bet is that collapsing them into one log is worth the operational cost of running a relay.

Against a plain Nostr relay, the difference runs the other way. A generic relay gives you signed events and a protocol, and leaves the workspace to whatever client you point at it. Buzz ships the workspace: channels, canvases, media with frame-pinned comments, YAML workflows with message, reaction, schedule and webhook triggers, a git hosting backend, and a CLI described in the README as agent-first with JSON in and JSON out. The repository also carries an ACP harness for Goose, Codex and Claude Code. You are trading the freedom to plug in any client for a client that already knows what a workflow run and a review approval are.

That trade is the real question. If you only need signed messages, a smaller relay will do less and cost less to run.

Maintenance, licence and what upgrading costs you

The repository is not archived, and the last push was on 2026-08-26. The most recent release in the list is desktop-v0.5.20, tagged the same day, with desktop-v0.5.19 the day before and desktop-v0.5.18 five days earlier. That cadence tells you the desktop client is moving quickly, which cuts both ways: fixes arrive fast, and so does churn in a client you may have to re-sign or re-package internally.

The workspace version in Cargo.toml is 0.1.0 while the desktop releases are at 0.5.x, so the relay crates and the client are versioned separately. There is a RELEASING.md in the repository and a .release directory, but the README does not document an upgrade path or a rollback procedure for a running relay. If you self-host, the migrations directory is where schema changes land, and you should read it before pulling a new relay image rather than after.

The licence is Apache-2.0, declared in Cargo.toml and linked from the README. That is a permissive licence with an explicit patent grant, which matters if you plan to run a modified relay inside a company. It also means you carry the obligations Apache-2.0 imposes, including preserving notices. This is a description of the licence text, not legal advice; have your own counsel read it if the deployment is commercial.

Editorial conclusion

Adopt Buzz if you want one signed event log for chat, patches, workflow runs and approvals, and you are willing to run Postgres, Redis and a relay yourself or deploy the relay to Railway. Do not adopt it if you need a working mobile client, approval gates that are wired end to end, or a compliance story: the README puts mobile, approval glue and push notifications in the not-yet column. Verify first that a packaged desktop build launches against your own relay by setting BUZZ_RELAY_URL to ws://localhost:3000 after docker compose up, and read VISION.md before assuming the roadmap items ship on any particular schedule.

Frequently asked questions

Official sources

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