Introduction
"A workspace where humans and agents build together, on a relay you own."
This is article #132 in the "One Open Source Project a Day" series. Today's project is Buzz — an open-source self-hostable team workspace from Block Inc. (the company behind Square, Cash App, and TBD), built on a Nostr relay, where humans and AI agents share the same rooms.
Most AI agent integrations work like this: add a bot to Slack/Teams, the bot replies when @mentioned, does nothing otherwise. Buzz starts from a different question: why should an agent's capability surface be smaller than a human teammate's? If an agent can review code, trigger workflows, open channels, pull in collaborators — the same things a human does, with the same identity system and audit trail — what does team collaboration look like then?
12,390 Stars. Created March 2026. Apache 2.0.
What You'll Learn
- Why Buzz is built on Nostr, and what that actually means
- The mechanics of agents as "first-class members" rather than bots
- Three concrete scenarios: incident memory, branch-as-room, release notes that write themselves
-
buzz-cliand the ACP adapter: how to connect Claude Code to Buzz - Architecture: the Rust crate map, Postgres + Redis + MinIO data layer
- What works today, what's being wired up, and what's still "strong opinions, pending code"
Prerequisites
- Basic familiarity with team collaboration tools (channels, messages, workflows)
- General understanding of AI agent tool-calling
- Basic Git knowledge
Project Background
Overview
Buzz is a self-hostable team workspace whose technical foundation is a Nostr relay (NIP-01 / NIP-42). Messages, reactions, workflow steps, code review approvals, Git events — all of these are events in the same signed event log. Same format, same identity model, same audit trail, whether the author is a human or a process.
Author / Team
- Author / Company: Block, Inc.
- Primary language: Rust (backend) + TypeScript (desktop UI)
- License: Apache-2.0
- Desktop app: Tauri + React
Project Stats
- ⭐ GitHub Stars: 12,390+
- 🍴 Forks: 996+
- 📄 License: Apache-2.0
- 📅 Created: 2026-03-06
Quick Start
Requires Docker and Hermit (or manually: Rust 1.88+, Node 24+, pnpm 10+, just).
First-time setup:
git clone https://github.com/block/buzz.git && cd buzz
. ./bin/activate-hermit # pinned toolchain (tools download on first use)
just setup && just build
just setup runs just bootstrap automatically — copies .env.example, downloads tools, starts Docker services + migrations.
Every day:
. ./bin/activate-hermit
just dev # starts relay + desktop app together
Relay on ws://localhost:3000. Desktop app pops up. You're in.
For split-terminal workflow (relay logs separate from Vite output):
# Terminal 1
just relay
# Terminal 2
just desktop-dev
Core Design: Everything Is an Event
Why Nostr
Buzz's technical foundation is a Nostr relay (NIP-01 / NIP-42). This choice has several deep implications:
Unified identity model: humans sign with Schnorr keypairs, AI agents sign with Schnorr keypairs. Identity isn't a role or permission flag — it's a cryptographic identity. An agent is "a holder of a different keypair," not "an authorized bot."
Unified event log: a message, an emoji reaction, a workflow trigger, a PR review approval, a CI status — all events in the same log, equally searchable, equally auditable.
Native Git integration (NIP-34): Git patches, repo announcements, and status events publish to the relay via NIP-34, meaning code changes and the conversations about them live in the same place.
Self-hostable: the relay is yours. Data stays on your infrastructure.
Agents Are Members, Not Bots
This is Buzz's core design claim.
Traditional team tool bots:
- Have a special "bot" account type
- Can only respond to specific triggers (@mention, webhook)
- Can do a restricted subset of what human members can do
- Have a separate audit trail from humans
Buzz agents:
- Have their own Nostr keypair (just like a human member)
- Have their own channel memberships
- Can do everything a human member can do: send messages, create channels, edit canvases, trigger workflows, join voice huddles, open repos, send patches, review code, orchestrate other agents
- Audit trail lives in the same log as humans, distinguished by cryptographic key
The project's own words: "Agents have the same surface area as humans, with their own keys and their own audit trail."
Three Concrete Scenarios
The README describes three scenarios that concretely illustrate what this design means in practice:
Scenario 1: Incident Memory
It's 2am. You type "have we seen this error before?" An agent watching the channel pulls six months of history, posts the threads, the root causes, the fixes, and offers to page whoever shipped the last one. The whole exchange — question, answer, evidence — stays in the channel.
The problem this solves: incident memory is usually scattered across different tools — Slack threads, Jira tickets, PagerDuty alerts, code comments. No one can correlate them at 2am. When everything is in the same event log, the agent's "search six months of history" isn't a cross-system API crawl — it's querying one index.
Scenario 2: Branch as Room
You open a feature branch. A channel appears. Patches land as NIP-34 events, CI posts results, an agent runs a first-pass review, teammates react to the parts they care about, and the merge decision lands in the same room as the evidence — so the channel becomes the record of why the code exists.
The traditional PR problem: why is the decision to create this PR in Slack, the PR itself in GitHub, CI in another tool, and the deploy approval in yet another? Buzz's answer: they're all events, they all belong in the same channel.
Scenario 3: Release Notes That Write Themselves
A workflow fires on a tag. An agent reads the merged PRs from the project channels, drafts the release notes, posts them for human review, gets a 👍 reaction, and ships. Every step signed. Every step searchable.
Notice the "👍 reaction as approval gate" design — not a special approval UI, not a separate approvals tool, just an emoji reaction in the channel, because it's also a signed event that a workflow can listen for.
Agent Integration: buzz-cli and the ACP Adapter
buzz-cli
buzz-cli is a command-line tool designed specifically for AI agents: JSON in, JSON out, optimized for LLM tool calls.
# Set the agent's Nostr private key
export BUZZ_PRIVATE_KEY=nsec...
# Now buzz-cli acts as this agent's identity
Design principle: all command I/O is structured for LLM tool calls, not human-readable output that's hard to parse.
ACP Adapter (buzz-acp)
Buzz provides an ACP (Agent Communication Protocol) adapter that lets the following AI coding agents connect directly to Buzz:
- Claude Code
- Goose (Block's own AI agent)
- Codex
buzz-acp bridges ACP ↔ MCP: it translates Buzz's capabilities into MCP tools so any MCP-compatible agent can call them directly.
buzz-dev-mcp
buzz-dev-mcp is an MCP server exposing:
- Shell tools (run commands in the Buzz context)
- File editing tools
This lets Claude Code and similar tools work inside Buzz channels using familiar MCP tool-call patterns, without learning a new API.
Architecture Deep Dive
System Architecture
┌────────────────────────────────────────────────────────────┐
│ Clients │
│ Human client AI agent CLI / scripts │
│ (Buzz desktop) (Goose/Codex/Claude) (buzz-cli) │
│ │ ┌─────────────┐ │ │
│ │ │ buzz-acp │ │ │
│ │ │ (ACP ↔ MCP) │ │ │
│ │ └──────┬──────┘ │ │
└──────┼───────────────────┼────────────────────┼────────────┘
│ WebSocket │ WS + REST │ WS + REST
▼ ▼ ▼
┌────────────────────────────────────────────────────────────┐
│ buzz-relay │
│ NIP-01 · NIP-42 auth · channel/DM/media/workflow/git │
│ REST · audit log │
└────┬───────────────────┬─────────────────┬────────────────┘
│ │ │
┌──▼────────┐ ┌──────▼──────┐ ┌────▼──────┐
│ Postgres │ │ Redis │ │ S3/MinIO │
│(events + │ │ (pub/sub) │ │ (Blossom) │
│ FTS) │ └─────────────┘ └───────────┘
└───────────┘
Single source of truth: the relay. All state flows through the relay, eliminating client/server drift. For agent behavior, this matters: the history the agent queries is the same history humans see.
Rust Crate Map
Core protocol
-
buzz-core— zero-I/O types, NIP-01 filters, Schnorr verify -
buzz-relay— Axum WebSocket + REST server
Services
-
buzz-db— Postgres -
buzz-auth— NIP-42/98 Schnorr auth + rate limiting -
buzz-pubsub— Redis pub/sub + presence + typing -
buzz-search— Postgres full-text search -
buzz-audit— hash-chain audit log
Agent surface
-
buzz-cli— agent-first CLI (JSON in/out) -
buzz-acp— ACP adapter for Goose/Codex/Claude Code -
buzz-agent— ACP agent implementation -
buzz-dev-mcp— shell + file-edit MCP tools -
buzz-workflow— YAML automation -
buzz-persona— agent persona packs
Git + pairing
-
git-sign-nostr/git-credential-nostr— Nostr-signed Git -
buzz-pair-relay/buzz-pairing-cli— relay pairing
Multi-Community Mode
A relay defaults to hosting one community (workspace). A hosted operator can serve multiple communities behind multiple domains/subdomains, but the client-facing rule stays the same: the URL is the authoritative identifier for a workspace, and all tenant-observable state is scoped by community — even when the backend shares a single Postgres and Redis instance.
Works Today / Being Wired Up / Strong Opinions, Pending Code
The README's transparency about project status deserves to be called out:
| ✅ Works today | 🚧 Being wired up | 💭 Strong opinions, pending code |
|---|---|---|
| Relay, channels, threads, DMs, canvases, media, search, audit log | Mobile clients (iOS + Android, Flutter) | Web-of-trust reputation across relays |
| Desktop app (Tauri + React) | Workflow approval gates (infra exists, glue still drying) | Push notifications |
buzz-cli + ACP harness (Goose, Codex, Claude Code) |
Culture features | |
| YAML workflows (message / reaction / schedule / webhook triggers) | ||
| Git events (NIP-34: patches, repo announcements, status) | ||
| Git hosting backend |
The README closes this table with: Please do not plan your compliance program around the 💭 column yet. This kind of explicit transparency about what's vaporware and what's shipping is uncommon in open-source project READMEs.
Resources
Official Links
- 🌟 GitHub: block/buzz
- 📖 Architecture: ARCHITECTURE.md
- 🔭 Vision: VISION.md
- 🤖 Agent vision: VISION_AGENT.md
- 🚀 Latest release: Releases
Summary
Buzz's core thesis is that the assumption "let agents do what humans do, with the same identity system, leaving the same audit trail" is worth testing seriously. Rather than using permission flags to constrain agents, it uses cryptographic identity to distinguish them — the same way it distinguishes different human members.
Three engineering decisions worth noting:
Nostr relay as unified foundation: Not "Slack with Git integration bolted on" but rather putting all event types (messages, code, approvals, workflow steps) into the same protocol. This eliminates "search across systems to reconstruct history" as a problem class — at the cost of committing to a relatively niche underlying protocol.
Single source of truth: All state flows through the relay; no client-local state drifts from server truth. This matters especially for agent reliability — the history an agent queries is identical to what humans see.
Audit trail is not optional: The hash-chain audit log is built in, not bolted on. Every step is signed, every step is traceable, regardless of whether a human or agent performed it.
ACP adapter + buzz-dev-mcp: For Claude Code users, this means working inside Buzz channels using familiar MCP tool-call patterns rather than learning a new API from scratch.
Block Inc. has a structural advantage here: they're also building Goose (their own AI coding agent), so "human-agent collaborative workspace" isn't just a product vision — it's their own internal tooling. That tends to sharpen the requirements in ways that purely speculative product work doesn't.
Explore PrimeSkills — a curated marketplace of AI agents and skills, each validated against real enterprise workflows. No hype, just what actually works.
Visit my personal site for more insights and interesting products.
Top comments (0)