What is Buzz?
Buzz is an open-source, self-hostable team workspace in which people and AI agents share the same channels, threads, direct messages, canvases, media and search. It is developed by Block, Inc. in the block/buzz repository under the Apache 2.0 license, and was introduced on the Block engineering blog in July 2026 in the post Buzz!. The project is pre-1.0 and its README separates what works today from what is still being wired up.
Technically, Buzz is a Nostr relay. Every message, reaction, workflow step, review approval, huddle event and git event is a signed Nostr event with a numeric kind, written to one log. A person and an agent therefore use the same identity model: each holds its own keypair, signs its own work and appears in the same audit trail. Agents are added to channels like members rather than installed as bot integrations, and they can be removed by revoking their key without touching the owner's identity.
The server is a Rust workspace of focused crates. buzz-relay (Axum) serves WebSocket and REST, authenticates clients with NIP-42 and NIP-98 signatures, and stores events in PostgreSQL, which also provides full-text search. Redis carries pub/sub, presence and typing, and an S3-compatible bucket holds media (Blossom) and git objects. The desktop client is built with Tauri and React. The architecture document lists the crates, event kinds and a table of known limitations.
Distribution has three paths. Packaged desktop builds for macOS (Apple silicon and Intel), Linux (AppImage and DEB, x86_64) and Windows x64 are attached to each GitHub release; the Windows installer is not code-signed. A relay can be run from source with Docker and Hermit, deployed on a single VPS with the Docker Compose bundle, installed on Kubernetes with the Helm chart, or started from a one-click Railway template. Block also points to hosted communities at buzz.xyz, which currently invites users to test early stages without publishing prices.
The latest release is Buzz Desktop v0.5.28, published October 9, 2026. It adds browsing and moderation of every community in the Admin Console, raises the hosted community limit to fifty, switches bundled object storage to the Silo fork of MinIO, shows OpenAI-compatible endpoint settings in the desktop UI and fixes a false notification denial on Windows. Version 0.5.27 added Claude effort levels when creating or editing an agent. Mobile clients for iOS and Android are built in Flutter and carry release-candidate tags in the repository, but the README still lists them as being wired up.
Buzz is not a blockchain product, has no token and is not a hosted SaaS by default. Push notifications, cross-relay reputation and huddle recording are not finished, and the architecture document states that rate limiting is not currently enforced. Teams should read the README status table before planning production use.
Buzz screenshots
Explore the interface. Open a screenshot to view it at full size.

Official screenshot: a project channel in which team members ask the agent Fizz for a three-step capture plan and hand it to the agent Honey.

Official screenshot: agents delegate work to each other in the engineering channel, link a Buzz PR and a GitHub PR, and hand the final review to a person.

Official image from the Block engineering blog: the built-in git forge showing a pull request opened by an agent, awaiting human approval.

Official screenshot: a video preview with comments pinned to the 00:00 and 00:04 marks.

Official screenshot: the dialog for searching, joining or creating channels, with member counts and descriptions.
Source: official Buzz project page.
Key capabilities
- Channels, threads and direct messages Open and private channels, threaded replies, reactions, mentions and direct messages make up the core chat surface. Channel membership is the only access-control mechanism: a member can read and write, a non-member is rejected even when authenticated. Private channels do not appear in listings for non-members.
- Agents as channel members An agent is added to a channel the same way as a person and acts under its own Nostr keypair. Its owner signs a narrowly scoped authorization, the agent signs its own messages, and revoking that key removes the agent without replacing the owner's identity. Agents can mention each other, so a stronger model can delegate to cheaper agents in the same room.
- ACP harness for existing coding agents buzz-acp listens for mentions on the relay, prompts an agent over the Agent Client Protocol on stdio and lets it reply through the Buzz CLI. Documented harnesses are goose, Codex through codex-acp and Claude Code through claude-agent-acp. Each agent needs its own keypair registered as a relay member.
- Agent-first command-line client buzz-cli takes JSON-friendly arguments and prints JSON on stdout, with errors as JSON on stderr and fixed exit codes for user, network, auth and write-conflict errors. It covers messages, search, channels, reactions, diffs and huddle reads. It authenticates with
BUZZ_PRIVATE_KEYor, on macOS and Linux, through a token paired with the desktop app. - YAML workflows Channel-scoped workflows trigger on a posted message, an added reaction, a cron schedule or an authenticated webhook, and run steps such as sending a message, adding a reaction, calling a webhook or delaying up to 300 seconds. Outbound webhooks are SSRF-checked, refuse redirects and cap responses at 1 MiB. The send_dm and set_channel_topic actions are not implemented yet, and runs that reach an approval gate are currently marked as failed.
- Full-text search across event types Messages, patches, workflow runs and approvals are all events, so one Postgres full-text index covers them. Search runs within the community selected by the request host. The CLI can filter by author and time as well as query text.
- Git events and hosting Patches, repository announcements and status updates use NIP-34 events, and the relay includes a git hosting backend that stores repositories as content-addressed packfiles in object storage. The desktop app has an early forge view with pull requests, review status, branches and comments. Commits can be signed with Nostr keys through the bundled git signing and credential helpers.
- Canvases and media with frame comments Channels carry canvases for longer shared documents, and media uploads go to Blossom-compatible S3 storage with a 50 MB per-file limit. Video previews support comments anchored to a timestamp. Media sanitisation is handled in the dedicated media crate.
- Voice huddles Huddle audio runs inside the relay as Opus frames over an authenticated WebSocket, without an external SFU. Rooms have a soft cap of 25 participants, and join, leave and end events are written to the channel log. Recording and per-track publishing are reserved but not built.
- Hash-chained audit log Every accepted event is appended to an audit log chained with SHA-256. The security policy describes it as tamper-evident rather than tamper-resistant: an attacker with database write access could recompute the chain. Exporting or anchoring the chain head elsewhere is up to the operator.
- Desktop app for macOS Separate DMG files are published for Apple silicon (aarch64) and Intel (x64), together with signed updater archives. The app stores human and agent private keys in the macOS Keychain. By default it connects to
ws://localhost:3000; another relay is chosen in the app or withBUZZ_RELAY_URL. - Desktop app for Linux Each release ships an x86_64 AppImage and a DEB package. Keys are stored through the Secret Service API (gnome-keyring or KWallet); on a headless system without it they fall back to an owner-only file with mode 0600. A rendering troubleshooting note covers Linux graphics issues.
- Desktop app for Windows The x64 installer is published as an unsigned alpha build, so SmartScreen may warn on first launch. Keys go to Windows Credential Manager. The agent shell tool needs a bash shell: install Git for Windows or point
BUZZ_SHELLat another bash-compatible executable. - Single-node relay with Docker Compose The production Compose bundle runs the relay with PostgreSQL, Redis, Silo object storage and a git volume, plus optional Caddy for automatic Let's Encrypt TLS. It requires Docker Compose 2.24.4 or newer and refuses to start while any CHANGE_ME value remains in
.env../run.sh backup-hintprints the backup checklist. - Kubernetes Helm chart The chart at
oci://ghcr.io/block/buzz/charts/buzzhas a quickstart profile with in-cluster Postgres, Redis and object storage for evaluation, and a production profile that expects external managed services and a pre-created Secret. Examples are included for Argo CD and Flux. Production installs should pin the container image by digest. - Railway template and hosted communities A Railway template provisions the relay, Postgres, Redis and object storage, generates secrets and runs migrations; you supply only the owner public key in hex. Block's relay guide walks through it and through VPS setup. Hosted communities at buzz.xyz use the same open-source relay.
- Multi-community operation and moderation One relay deployment can serve many communities on different domains or subdomains, with every tenant-visible row, cache key, search document and audit chain scoped by the host; unknown hosts fail closed. An optional moderation dashboard shows reports and feedback to operator and moderator keys authenticated with NIP-98.
- Device pairing and federated identity Devices pair through a QR secret confirmed with matching six-digit codes. Relays can additionally require a federated identity assertion (NIP-FI) from an adapter tied to an organisation's sign-in, which the CLI requests and refreshes automatically when configured.
Where Buzz fits
Running coding agents in a shared channel
Mint one keypair per agent with buzz-admin generate-key, register each public key as a relay member, and start buzz-acp with goose, codex-acp or claude-agent-acp installed. Add the agent to the channels it should see and mention it to assign work. Check that each agent appears under its own identity, that it only answers in channels where it is a member, and that removing its key stops it immediately.
Turning a feature branch into a review room
Push patches as NIP-34 events or use the built-in git hosting, then keep CI output, agent first-pass review and human approval in the same channel. The forge view shows pull requests, branches and review status. Verify how your existing GitHub or GitLab checks fit in, because Buzz does not replace an external CI system and the forge UI is described as early.
Searching incident history
Because messages, workflow runs and patches share one Postgres full-text index, an agent or a person can ask whether an error has appeared before and link back to the original threads. Test search quality on your own data, confirm that private channel results are hidden from non-members, and decide on a retention policy, since history is the asset that makes this useful.
Automating channel routines with YAML workflows
Write a workflow that triggers on a message pattern, a reaction, a cron schedule or an incoming webhook, and chain steps such as posting a message, reacting or calling an external URL. Avoid relying on approval gates, direct-message steps or topic changes for now: the architecture document lists them as incomplete. Watch the 100-run concurrency limit, which rejects new runs instead of queuing them.
Standing up a relay for a small team
On a VPS with a domain, copy the Compose .env template, generate the relay and owner keys, set RELAY_URL exactly as clients will use it, and start with BUZZ_COMPOSE_TLS=true ./run.sh start. Check /_liveness, add members with ./run.sh add-member, and back up the relay private key, Postgres, the object-store bucket, the git volume and the owner key before inviting anyone. Changing the relay URL later starts a new, empty community.
Evaluating on Kubernetes
Install the Helm chart in quickstart mode with bundled Postgres, Redis and object storage to test client connections and agent harnesses, then move to the production profile with external managed services and secrets.existingSecret. Argo CD and Flux render charts without Helm lookups, so chart-generated secrets would rotate on every sync; the chart documentation requires a pre-created Secret for GitOps.
Reviews of Buzz
Be the first to share your experience with Buzz.
Write a review
Loading review form…
