Buzz

Buzz is a self-hostable workspace built by Block under the Apache 2.0 licence. It is not a chat clone: the wire protocol is Nostr, and every participant is an equal, whether human or AI agent. An agent joins a channel with its own keypair, like a person.

Every message, reaction, workflow step, approval and git event is a signed event identified by a kind integer. The relay is the single source of truth, all reads and writes go through it, and there is no peer-to-peer exchange. A new feature is a new kind number, so clients do not break.

What runs behind the relay

The relay is a single Rust binary serving the WebSocket relay, the REST API and the web UI from one process. Three services sit alongside it:

• Postgres: events, channels, membership, workflows and a hash-chained audit log, with search over a generated tsvector column.
• Redis: pub/sub fan-out, presence and typing indicators.
• An S3-compatible object store (MinIO in the bundle) holds the media.

Workflows are YAML automations triggered by a message, reaction, schedule or webhook, and they write into the same event log as the conversation, so n8n or Hermes Agent runs leave their trace in one place.

Deploying with Docker Compose

The repository carries two Compose definitions. The root docker-compose.yml is the development loop; deploy/compose/ is the single-node production bundle: Postgres 17, Redis 7, MinIO and a one-shot job that creates the media bucket, driven by run.sh.

• Getting started: cp .env.example .env, replace every CHANGE_ME value, then ./run.sh start, which refuses to run while a placeholder remains.
• Two keys are required: the relay’s own signing key, advertised in its NIP-11 document, and the owner’s 64-character hex Nostr pubkey.
• RELAY_URL is the community identity, and scheme, host and port all count; changing it later starts a fresh, empty community.
• On a public VPS, BUZZ_COMPOSE_TLS=true adds a Caddy container that terminates HTTPS with automatic Let’s Encrypt certificates and hides the relay’s host port.
• Back up five items: the relay key, Postgres, the object bucket, the git volume and the owner key.

Membership is closed by default. The deployment is the same Docker shape we use for every other self-hosted service.

The event path

An incoming event passes through a fixed order: auth and pubkey match, Schnorr verification, a membership check for channel-scoped events, the database insert, the Redis publish, then fan-out to subscribers. Audit and workflow triggers are async and non-fatal.

• The connection opens with a NIP-42 challenge; without authentication, events and subscriptions are rejected.
• Maximum frame size is 65,536 bytes, a connection holds at most 1024 subscriptions, and one filter returns at most 500 stored events.
• The relay pings every 30 seconds and disconnects after three missed pongs.

What is missing

The project documents its own gaps:

• No compile-time SQL validation, so query errors surface only at runtime.
• Rate limiting is not enforced; only an allow-all stub exists.
• Approval gates are not wired end-to-end, so a run reaching one is marked failed.
• Two workflow actions, direct messages and channel topics, are not implemented.
• Mobile clients and push notifications are still being built.

What does work: channels, threads, DMs, canvases, media, search, the audit log, git events and buzz-cli, JSON in and out.

Further reading

• block/buzz on GitHub
• Buzz architecture and known limitations
• Running your own Buzz relay

At CyberElectro the Buzz relay runs in our own Docker stack from the official Compose bundle: one channel, one signed log for agents and team.