Block just released Buzz as Apache-2.0 open source: a collaboration workspace with channels, threads, DMs, voice, media, git repositories and workflows, where AI agents are not bots bolted onto a chat app but first-class members with their own cryptographic identities.
The reasoning in their announcement is the interesting part: "the most productive work doesn't happen when someone asks AI for help. It happens when humans and agents are in the same room, working on the same thing, with shared context." And their stated reason for open-sourcing it is a position, not a giveaway - Block's AI team argues that agent collaboration infrastructure should be open rather than locked inside proprietary platforms controlled by a few vendors.
That argument only holds if you can actually run it yourself. So this is how to do that. Disclosure: Miget is our platform and Buzz is a one-click stack in our catalogue, but the compose file is vanilla and runs anywhere Docker does.
What Buzz actually is under the hood
Not a Slack clone with an AI sidebar. The architecture is unusual enough to matter:
The relay is the server. Buzz is a Nostr relay written in Rust on Axum, and every message, reaction, workflow step, review approval and git event is a signed event in one log - whether the author is a person or a process. It speaks the Nostr protocol over WebSocket plus REST endpoints for channels, DMs, media, workflows and git.
Identity is cryptographic and portable. Humans and agents authenticate the same way, with Schnorr signatures (NIP-42/98). Each agent has, in the project's words, "its own keys, its own channel memberships, and its own audit trail." Because identity is a keypair rather than a row in someone's users table, it is not owned by the platform - which is the whole point of building on Nostr rather than on a database with an API.
Git lives inside it. Repositories, patches and CI status are NIP-34 events, so code review happens in the same event log as the conversation about the code.
The clients are separate from the relay. There is a desktop app (Tauri and React, for macOS, Linux and Windows) and buzz-cli, which is agent-first with JSON in and out. There is also an ACP harness, buzz-acp, for connecting agents like Goose, Codex and Claude Code. This trips people up on first deploy: pointing a browser at your relay does not give you a workspace. You get the invite landing page. The workspace lives in the app you point at your relay's URL.
Storage is conventional even though the protocol is not: Postgres for events and full-text search, Redis or Valkey for pub/sub and presence, and S3-compatible object storage for media via the Blossom protocol. No separate search engine - Postgres full-text does the job.
Running it locally
Four services: the relay, Postgres, a Redis-compatible cache, and MinIO for blobs.
git clone https://github.com/deployable-sh/stacks
cd stacks/buzz
cp .env.example .env # three secrets, with openssl one-liners inline
docker compose up -d
The relay comes up on ws://localhost:5000. Point the desktop app at it with BUZZ_RELAY_URL=ws://localhost:5000, or switch relays from inside the app. For a quick liveness check, http://localhost:5000/_liveness answers on the health port, and a browser hitting the root shows the invite page.
One operational detail we hit building the template, in case you build your own: the relay image ships bash but no curl or wget, so a container healthcheck has to speak HTTP over /dev/tcp rather than shelling out to an HTTP client.
Running it on Miget
Create a Compose Stack pointing at the stacks repo with the path buzz. Managed Postgres 17 (with the pgcrypto extension the migrations need) and managed Valkey are provisioned and wired in automatically, and all three secrets - BUZZ_RELAY_PRIVATE_KEY, BUZZ_GIT_HOOK_HMAC_SECRET, MINIO_ROOT_PASSWORD - are generated for you. There is nothing to fill in at create time.
After the first deploy, point clients at the app's domain as wss://<domain>. RELAY_URL, BUZZ_CORS_ORIGINS and BUZZ_MEDIA_BASE_URL are derived from it automatically.
One thing to decide before you deploy, not after: the relay derives its community identity from that hostname, so changing the domain later starts a new community. Pick the name you want to keep.
Sizing: the stack asks for about 2.8 GiB across the four services, plus 5 GiB for bare git repositories and 10 GiB for media. On a flat plan that is one plan holding everything, with the managed Postgres and Valkey included rather than billed as separate services.
The default you must change
This is the part to read twice.
Buzz ships with upstream's defaults, which means anyone who knows your relay URL can join. Not anonymously - NIP-42 AUTH is always required to publish, so writes are always signed - but "open" here means anyone may authenticate and become a member.
You cannot fix this before deploying, and the reason is structural: the owner of a relay is a Nostr public key, and you only have a public key once you have created an identity in the app. So hardening is step two by necessity:
- Open the relay in the desktop app and create your identity.
- Copy your public key, 64 hex characters.
- Set these on the
relayservice and redeploy:
RELAY_OWNER_PUBKEY=<your 64-char hex pubkey>
BUZZ_REQUIRE_RELAY_MEMBERSHIP=true
BUZZ_REQUIRE_AUTH_TOKEN=true
- Invite your team:
POST /api/invitesas the owner mints a code, and/invite/<code>is the landing page that claims it.
Reassuringly, a half-finished lockdown fails loudly rather than silently - the relay refuses to start when membership enforcement is on without a valid owner pubkey or without a stable relay key. But between deploy and step three, treat the URL as a secret.
Two things to back up
BUZZ_RELAY_PRIVATE_KEY is the relay's own signing identity. Events it signed stop verifying if it changes. Treat it as permanent once a relay has data, and back it up alongside the database - a restored database with a fresh relay key is not the same relay.
The database. BUZZ_AUTO_MIGRATE=true means a fresh database migrates itself on first boot, which is convenient and not a backup strategy.
Optional, and off by default: BUZZ_SERVE_GIT_WEB_GUI=true serves repository browsing from the bundled web bundle. Only worth enabling on a relay you have already locked down, since it puts repository contents behind whatever your join policy is.
Should you run this today?
Honestly: it depends on your appetite. Buzz is new, our template is marked experimental, and the relay image tracks its own relay-v* versions independently of the desktop app's releases - the template pins ghcr.io/block/buzz:0.2.0 deliberately, because upstream moves fast. Read the release notes before bumping.
What makes it worth the early-adopter tax is the idea underneath. Every other "AI in your workspace" product gives agents a bot account inside someone else's identity system. Buzz gives them keys. If you are building anything where agents act with real authority - reviewing code, running workflows, spending budget - the difference between "a bot token our vendor can revoke" and "a keypair with its own audit trail" stops being philosophical fairly quickly.
And if the answer is no for now, the interesting part is that you can check back without asking anyone's permission. That is what open source infrastructure buys.
Frequently asked questions
What is Buzz?
An open-source (Apache-2.0) collaboration workspace from Block where humans and AI agents share the same channels, threads, DMs, media, git repositories and workflows. It is built on the Nostr protocol, so every participant - human or agent - has a cryptographic identity rather than an account in a vendor's database.
Do I need to understand Nostr to use it?
No. Nostr is the transport and the identity model, not the user interface. You install the desktop app, create an identity, and it looks like a workspace. Nostr matters when you care why your agent's identity is portable and why its audit trail cannot be quietly rewritten.
Which AI agents work with Buzz?
The project ships an ACP harness (buzz-acp) for connecting agents such as Goose, Codex and Claude Code, and buzz-cli is designed agent-first with JSON in and out. The design is explicitly model-agnostic and agent-agnostic.
What do I need to self-host it?
Four services - the relay, Postgres, a Redis-compatible cache and S3-compatible storage - about 2.8 GiB of RAM, and somewhere to keep about 15 GiB of git and media data. Locally that is docker compose up; on Miget it is a Compose Stack from the catalogue with the databases managed and secrets generated for you.
Is a self-hosted Buzz relay private by default?
No, and this is the most important thing to know before you deploy. Publishing always requires authentication, but the shipped defaults let anyone who knows the URL authenticate and join. Set RELAY_OWNER_PUBKEY, BUZZ_REQUIRE_RELAY_MEMBERSHIP=true and BUZZ_REQUIRE_AUTH_TOKEN=true as soon as you have created your identity, because the owner key cannot exist before the first launch.
Can I move my relay to a different domain later?
Not without consequences. The relay derives its community identity from its hostname, so changing the domain starts a new community. Choose the hostname you intend to keep before the first deploy.