# Buzz's shape: one relay holds one community, and the dev compose ships admin/admin

> Buzz is a self-hostable Nostr relay that doubles as a developer workspace, where agents hold keypairs of their own and land in the same signed event log as people. The three things that decide whether you can actually run it are the tenancy rule, an unsigned Windows build, and a development compose file with default credentials.

**block/buzz** — A hive mind communication platform. Buzz A workspace where humans and agents build together, on a relay you own.

- Repository: https://github.com/block/buzz
- Stars: 34,444 · Forks: 4,565
- Language: Rust
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/block-buzz

## One relay holds one community, and the URL is the tenant boundary

A community in Buzz is not a setting you toggle. It is the workspace a user reaches by URL, and in the single-relay setup that ships today, the relay URL selects exactly one community. A hosted operator can serve many communities behind many domains or subdomains, and the client-facing rule stays the same: the URL is authoritative for the workspace, and all tenant-observable state under that URL is community-local. Even in a hosted multi-tenant deployment, where the backend shares Postgres, Redis, and object storage, each community keeps that semantic boundary.

So the scaling question is not how many communities one process holds. It is how many relays you operate. If you want a staging community and a production community out of one deployment, the default topology does not give it to you, and the routes are a second relay or a hosted operator serving them behind separate domains. The payoff of the rule is that isolation is a property of the address rather than a filter somebody has to remember to apply when adding a query.

## Agents arrive with their own keypairs, not bot tokens

The identity model is the reason this is an event log written in Rust. Every message, reaction, workflow step, review approval, and git event is a signed event in one log, with the same shape and the same audit trail whether the author is a person or a process. Git work rides the same log through NIP-34, which covers patches, repo announcements, and status.

An agent joins a channel the way a person does, and what it gets is its own keys, its own channel memberships, and its own audit trail. The scoping is by identity rather than by permission flags, described as the way you would scope a teammate. Once inside, the surface matches a human member's: open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into voice huddles, and create channels. The difference from a bot holding an admin token is attribution. The cost is that an agent can do everything a member can do in the rooms it has joined, so the room list is the whole of your access model.

## The Windows build is unsigned and the relay URL is an environment variable

Packaged builds come from the latest release page, and the artifact names tell you which machine you need. The Windows file is `Buzz_<version>_x64-setup_alpha-unsigned.exe`, and it is not code-signed, so SmartScreen shows Windows protected your PC on first launch and you click More info, then Run anyway. Mac users are told to open the Apple menu, then About This Mac, where Chip: Apple means Apple Silicon and the aarch64 disk image, and Processor: Intel means the x64 one. Linux x86 has an AppImage and a deb.

Connection defaults matter just as much. The app connects to `ws://localhost:3000` unless you set `BUZZ_RELAY_URL` before launching, or switch the relay from inside the app. The variable is read at launch, so a managed rollout has to set it in the launch environment rather than in a settings screen after the fact. And the unsigned Windows artifact is an endpoint policy exception somebody has to approve before it lands on staff machines.

## The dev compose file ships known credentials and a database console

The compose file at the repository root is a development stack, and it is worth reading before copying it anywhere. Postgres runs as `postgres:17-alpine` with user `buzz`, password `buzz_dev`, and database `buzz`, capped at 512m of memory. Redis runs as `redis:7-alpine`, capped at 128m. Adminer runs as `adminer:latest` on `127.0.0.1:8082:8080` with `ADMINER_DEFAULT_SERVER` set to `postgres`, so a database console is part of the stack by default. Keycloak runs as `quay.io/keycloak/keycloak:26.0` with the `start-dev --http-port=8080` command, `KC_DB` set to `dev-mem`, and the administrator credentials set to `admin` and `admin`.

The loopback port bindings are the only thing keeping this configuration out of production. Lift the file into a shared environment without editing it and you have deployed a database whose password is written in the repository, an admin console pointed at it, and an identity provider whose admin account is the word admin twice. The per-service memory limits are sized for a laptop as well. Nothing here is presented as a production compose file.

## Git hosting works because the container keeps git installed

The published relay image is `ghcr.io/block/buzz:<tag>`, built by a single Dockerfile that produces the `buzz-relay` binary with Rust 1.95 plus the `buzz-web` static bundle with pnpm and vite, then assembles them into a debian-slim runtime. That slim image deliberately keeps `git` available, and the build file explains why in as many words: the relay shells out to git for repo hydrate, receive-pack, and upload-pack, in the code under `crates/buzz-relay/src/api/git`. Git hosting is therefore a subprocess against storage the relay can write to, not a library call inside the process.

Two build details reach past the compile. Multi-architecture is handled by running that same Dockerfile on native amd64 and native arm64 runners, and the file says not to add platform pins, so a layer cache keyed on platform will not match. And the Dockerfile accepts optional build arguments for an extra certificate bundle and an npm registry, both empty by default so public builds are unaffected. Neither is a runtime knob. If your build sits behind a TLS-intercepting proxy, the certificate has to be supplied at build time or the cargo and pnpm stages fail on fetch.

## The desktop shell is deliberately outside the Cargo workspace

The workspace manifest excludes the desktop Rust code outright:

```toml
exclude = ["desktop/src-tauri"]
```

That is the Tauri and React application, the one the release artifacts are built from, and it does not build as part of the thirty-odd crates in the workspace members. The JavaScript side of that shell is managed separately again: the root `package.json` is named `buzz-workspace`, is marked private, and pins pnpm 11.4.0 as its package manager. Its entire script list is one entry, `pnpm -r check`, with Biome as the only development dependency and Tailwind typography as the only runtime dependency. So there is no root build command, no root test command, and no root lint command. Three toolchains, three invocations, each from its own subtree. A change that touches the desktop shell and a crate is two check runs in two directories, and a green result in one tells you nothing about the other.

## The Rust crates say 0.1.0 while the release tags read 0.5.26

The workspace package block is short:

```toml
version = "0.1.0"
edition = "2021"
rust-version = "1.88.0"
license = "Apache-2.0"
```

The release stream is named for the desktop app instead: desktop-v0.5.24 on 2026-09-23, desktop-v0.5.25 on 2026-09-24, and desktop-v0.5.26 on 2026-09-29, with the last push to main dated 2026-09-25 and the repository not archived. There is no single version number for the project here, so a version read off a crate is not the version on the releases page, and the crates have sat at 0.1.0 through a run of 0.5.x desktop tags.

Two smaller details in the same block matter. The Rust floor is 1.88.0 while the container builds with Rust 1.95, so a local build on an older toolchain is refused rather than quietly miscompiled. And the repository field reads `https://github.com/block/sprout`, which is not the repository the manifest sits in. The field is the first thing any packaging or documentation tooling reads to resolve where the code lives, and here it points somewhere else.

## Approval gates, mobile clients, and huddle events are still on the list

The project keeps a three-column status table, and the honesty in it is the most useful thing in the README. Working today: the relay with channels, threads, DMs, canvases, media, search, and an audit log; the desktop app; `buzz-cli`, described as agent-first with JSON in and JSON out, plus an ACP harness for Goose, Codex, and Claude Code; YAML workflows triggered by a message, a reaction, a schedule, or a webhook; NIP-34 git events; and the git hosting backend.

Being wired up: mobile clients for iOS and Android in Flutter, workflow approval gates where the infrastructure exists but the glue is still described as drying, and huddle lifecycle events. Behind strong opinions with code pending: web-of-trust reputation across relays, push notifications, and culture features, with a request not to plan a compliance program around that column. Two gaps have direct consequences. A release process that depends on a human thumbs-up gating the ship is leaning on the piece that is not finished. And while every other surface writes to the one signed log, huddle lifecycle events are not emitted yet, so voice has no entry in the audit trail.

## Conclusion

Buzz fits a team that wants one substrate for chat, patches, workflows, and git events, and that is willing to run Postgres, Redis, and a relay on its own hardware. It does not fit a team that needs a signed Windows build, mobile clients, or finished workflow approval gates on day one, and the development compose file must never reach a shared environment unedited. Before committing, check which pending items your rollout leans on, settle your relay URL plan, and decide who holds the agent keypairs.

## FAQ

### What is the Buzz app used for?

It is a self-hostable workspace where humans and AI agents share the same rooms, built as a Nostr relay. What works today covers the relay itself with channels, threads, DMs, canvases, media, search, and an audit log, plus a desktop app, YAML workflows, NIP-34 git events, and a git hosting backend.

### How does Buzz work?

A community is whatever workspace a URL points at, and in the setup that ships today one relay URL selects exactly one community. Every message, reaction, workflow step, review approval, and git event is a signed event in a single log, and the desktop app connects to ws://localhost:3000 by default unless you set BUZZ_RELAY_URL before launching.

### What does Buzz AI do inside a workspace?

Agents hold their own keys, their own channel memberships, and their own audit trail, and are scoped by identity rather than by permission flags. Inside a room they open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, join voice huddles, and create channels.

### Is Buzz free to use?

The code is released under the Apache 2.0 license and the whole relay is meant to be self-hosted, with packaged desktop builds published on the releases page for macOS, Linux, and Windows. Nothing in the project describes a paid tier, a seat count, or a hosted price.

### How does Buzz compare with Slack?

The project does not publish a feature comparison against Slack. What it does state is the bet that one community can do the work teams currently spread across chat, forges, bots, CI dashboards, release tools, search indexes, and glue code, with one substrate instead of seven tabs that only pretend to know about each other.

## Sources

- [Official README](https://github.com/block/buzz#readme)
- [Project repository](https://github.com/block/buzz)
- [Release notes](https://github.com/block/buzz/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/block-buzz