Buzz Explained: Block’s Self-Hosted Agent Workspace

Block Buzz is a self-hosted agent workspace: an Apache-2.0 relay, written in Rust, where AI agents join channels as members holding their own cryptographic identity instead of borrowing a human’s credentials. Block announced it publicly on July 21, 2026, and the repository behind it has been public since the spring. This is a capability review rather than a launch report — what the identity model gets right, and what Block’s own documentation says is not finished.

The reason to care is narrow and specific. Most teams running agents today hand them a service account, a bot token, or an engineer’s own API key, then reconstruct after the fact who actually did what. Buzz takes the opposite position: give the agent a keypair, let it sign its own work, and keep the record of who authorized it separate from the record of who produced it. That is a design idea worth understanding whether or not you ever run Buzz.

What follows is built from Block’s primary material — the corporate and engineering launch posts, the self-hosting guide, and the repository’s README, ARCHITECTURE.md, SECURITY.md and VISION_AGENT.md — plus the GitHub API for repository facts. Where Block’s own two documents disagree, we show both. Where a claim reaches us only through trade press, we say so.

Buzz is a workspace — channels, threads, direct messages, canvases, media, search — with one structural difference from Slack or Discord: an AI agent is a member with its own identity rather than a bot integration posting under someone else’s name. The repository description on GitHub calls it a hive mind communication platform; the README headline promises a workspace where humans and agents build together, on a relay you own. Both are Block’s words on different surfaces, and the README line is the product positioning.

The dates matter, because the story circulated as though Buzz appeared out of nowhere. It did not. The repository block/buzz was created on March 6, 2026, and its first substantive commit three days later describes an internal codename: an initial release of a Sprout Nostr relay with enterprise extensions. Public GitHub releases began on May 3, 2026. The launch posts came later, on July 21, 2026, when Block published an announcement on its corporate site and a technical write-up on its engineering blog the same day. A self-hosting guide followed on July 31.

The interest is real: more than 24,000 stars at the time of writing. Contribution, though, is concentrated. The repository shows roughly 85 contributors, and the ten highest by commit count are Block staff accounts plus a dependency bot. That is a normal shape for a company-authored project in its first months, and worth knowing before you assume a broad maintainer bench stands behind it. The licence is Apache-2.0 and the code is genuinely public — this is an observation about maturity, not about sincerity.

One framing needs care. Trade coverage described Buzz as a replacement for Slack and GitHub inside Block. Jack Dorsey, who leads Block, announced it on X on July 21 and described it as model-agnostic, decentralized, self-sovereign and open source, built to reduce Block’s dependency on both — as reported by TechTimes and corroborated by tftc.io. Block’s own corporate post does not use the word replacement. Its engineering post frames the motivation more modestly: agents made individual work faster and teamwork slower.

Buzz is a Nostr relay. Its wire format is NIP-01, connection authentication is NIP-42, REST authentication is NIP-98, and git events use NIP-34. The shipped artifact is a single Rust binary serving the WebSocket relay, the REST API and the web UI from one process, backed by Postgres, Redis and an S3-compatible object store — MinIO in the production Docker Compose bundle, with media served over Blossom. The core crate registers 127 event kinds at the time of writing, a hedge Block prints in its own document; kinds in the 20000 to 29999 range are ephemeral and are neither stored nor audited.

This is where the launch vocabulary and the engineering documentation part company, and it is the single most important thing to get straight before you evaluate Buzz.

Both statements are true at once, and only one of them is what most readers hear. Buzz is self-sovereign in the sense that matters commercially: no vendor sits between your team and its own conversations, and no third party holds the signing keys. It is not a resilient distributed network. Your relay is your blast radius, your availability ceiling and your backup problem. Federation across relays sits in the README’s pending-code column as web-of-trust reputation across relays, which is to say it is on the roadmap and not in the build.

The harness surface is deliberately open. Block states that teams can deploy agents powered by any model or agent harness, bring their own, or build their own, and the release notes show concrete model plumbing rather than a single hard-wired provider. Block’s own ACP agent supports up to eight concurrent sessions by default, each with its own MCP servers, history and context, and self-summarises when context fills. Goose, the agent Block has published since 2024, now lives at aaif-goose/goose — which is where Block’s own launch post links it.

This is the part of Buzz worth studying even if you never deploy it. Identity is a secp256k1 keypair for every participant, human or agent, verified by Schnorr signature. There is no bot user, no shared service account and no borrowed API key in the model. An agent is a principal.

The interesting move is what Block does with delegation. The conventional pattern gives an agent a human’s credentials, at which point every action it takes is indistinguishable from that human’s actions in the log. Block’s design splits the two.

Two practical consequences follow. First, revocation is per-agent rather than per-human: if an agent key leaks you revoke the agent without replacing the human identity behind it, and removing the owner stops the agent reconnecting. Anyone who has rotated a shared service-account key across a dozen integrations at 2am will recognise what that saves. Second, attribution survives review — the record shows which agent produced a change and which human stood behind it, as two separate signatures rather than one ambiguous one. We covered the general shape of this problem in our playbook on giving each agent its own credentials rather than borrowing a human’s; Buzz is the most complete implementation of that principle we have read in a shipped codebase.

Key handling on the client side is more careful than the pre-1.0 label suggests. Desktop private keys live in the OS keyring — macOS Keychain, Windows Credential Manager, Linux Secret Service — and plaintext keys are migrated on upgrade with a read-back verification before the plaintext copy is deleted. Migration is skipped entirely if the keyring is unreachable, so a transient outage cannot resurrect a rotated key. Headless installs fall back to an owner-only file, and the BUZZ_PRIVATE_KEY environment variable always takes precedence, which is how harnessed agents and CI receive identity.

Most coverage of Buzz implies fine-grained agent permissions. Block’s own security document says the opposite, in one sentence.

This is coarse, and it is deliberate. The README frames it as scoping by identity rather than by permission flags, the same way you would scope a teammate: you do not write a capability policy for a colleague, you decide which rooms they are in. As an architectural position it is defensible and it is legible, which matters more than it sounds — a permission model an operations lead can hold in their head gets audited, and a capability taxonomy usually does not.

What it is not is least-privilege scoping. You cannot express “this agent may read this channel but not post to it”, or “this agent may call this tool but not that one”, inside the membership model. Membership is closed by default and administered explicitly — a member is added with a public key and a role, which publishes a roster event — so the door is shut until someone opens it. But once it is open, it is open in both directions.

Two adjacent details are worth carrying into any security review. Search does not enforce access control on its own: the search crate returns candidate hits and the relay re-authorizes each one against channel membership before delivering it. That is architecturally fine as shipped, and it is a landmine if you fork the code and wire search to a different consumer.

The larger caveat is the shell. Block’s development MCP server gives an agent a shell and a file editor, with process-group kill on every exit path and bounded output — and Block’s own agent document states that the shell runs at the operator’s trust level, like bash itself. Channel membership does not constrain what that shell can do on the host. An agent scoped to one quiet channel still has the operator’s privileges on the machine it runs on. That is under-reported, and it is the sentence to put in front of whoever signs off on the pilot.

Buzz keeps a hash-chained audit log. Each entry chains to the previous one through a SHA-256 previous-hash field, the genesis entry uses a fixed all-zero hash, and a verification routine recomputes the chain to detect tampering. Ten actions are logged: event created, event deleted, channel created, channel updated, channel deleted, member added, member removed, authentication success, authentication failure and rate limit exceeded.

Block states that the log is designed for SOX-grade compliance and eDiscovery. That is design intent, and it is worth reading as exactly that — a stated goal, not a certification, an attestation or an audit opinion. Nothing in the repository claims otherwise, and neither should any deck built on it.

There are also two documented blind spots. Authentication events of the Nostr auth kind are not written to the audit log, and ephemeral events never reach the audit pipeline at all. So the chain is a record of the actions Block chose to record, verifiable against casual edits, held in the same database an administrator can write to. For an internal engineering record that is entirely reasonable. For a regulated evidentiary record it is not sufficient on its own, and the fix is the standard one: ship the chain somewhere the application cannot rewrite it. Our guide to what a defensible agent audit trail needs covers the write-once destination and the separation-of-duties argument in more depth.

Give Block credit for the disclosure. A vendor that writes down the precise limit of its own tamper-evidence is easier to trust than one that ships the word immutable in a feature list. The honest read is that Buzz gives you a strong integrity signal and a weak custody story, and those are different products.

The most useful document in the repository is not the README. It is section nine of ARCHITECTURE.md, which opens by describing its contents as verified gaps in the current implementation rather than design aspirations. Six of them are listed. Read against the README’s crate map and maturity table, they produce a diff that we have not seen published anywhere else — and one outright contradiction.

The table below is our comparison, assembled entirely from Block’s own two documents: what the README leads a reader to expect, what the architecture document states, and what the difference costs a team running a pilot.

The rate-limiting row is the one that deserves its own paragraph, because it is the only place where the two documents contradict each other outright rather than describing different levels of detail. The README’s crate map assigns rate limiting to the authentication crate as a responsibility. The architecture document states that no Redis-backed rate limiter exists anywhere in the codebase, that the sole implementation is a test stub that always allows, and that the four configured tiers — human, agent-standard, agent-elevated and agent-platform — are a design target rather than an enforced policy. Both statements are Block’s. The fair reading is that the README describes the crate’s intended responsibility and the architecture document describes shipped reality, and a reader who only sees the README will assume protection that is not there.

That matters more here than it would elsewhere. A workspace pitched at teams pointing large numbers of agents at a problem is precisely the workload an unenforced limiter fails to contain, and the audit log has a rate-limit-exceeded action defined for events that cannot currently fire. The approval-gate row is the second one to internalise: a run that reaches a human-approval step does not wait, it fails. If your governance design assumes a person can intervene mid-run, read our guide to human-in-the-loop escalation design and keep that control wherever it lives today, because Buzz cannot hold it for you yet.

Block documents three self-hosting paths plus its own hosted option, in separate places. Side by side, the trade-offs are clearer — and so is the gap where a price should sit, because Block publishes none for the hosted tier.

Two relay-level keys govern a self-hosted deployment. The relay’s own signing key is advertised in the relay information document, and rotating it breaks verification of everything the relay previously signed — treat it as a root key, back it up before first launch, and plan never to rotate it casually. The relay-owner public key designates the one account the admin tool cannot remove, which makes it your recovery path if administrative access is lost. Neither key has a self-service reset.

Three more details belong in the deployment brief. The relay does not enforce TLS by design, so a self-hoster who skips the reverse proxy is running plaintext. The Windows desktop asset is not code-signed — the file name says so and the README warns that SmartScreen will complain. And Block tells its own employees not to build from source or use the open-source release, but to use the internal build that comes pre-wired to Block’s relay and agent provider. That last one is a fair, sourced observation about the distance between the public artifact and the product Block runs internally; it is not an accusation, and it should not be inflated into one.

On the security process itself, Block publishes a vulnerability contact with a 48-hour acknowledgement commitment and a seven-day target for a full response including a fix timeline, enforces a no-unsafe-code attribute across all crates, and runs a dependency audit in CI. Workflow webhook actions resolve their targets against a private and loopback blocklist to blunt server-side request forgery, response bodies are size-limited, and workflow condition expressions are sandboxed and time-bounded. If you are still weighing the hosting decision itself, our SaaS versus self-hosted versus hybrid decision matrix is the framework we use with clients, and our guide to when self-hosting an open-source agent is worth it covers the running-cost side.

The marketing claim underneath Buzz is that agents become real teammates. That is testable. The grid below converts the claim into eight governance controls and marks what Buzz enforces today, with the mechanism and the Block document that states it. Every row is sourced to Block’s own material, and the same grid works as a scorecard for any competing tool you evaluate next.

Read the grid as a shape rather than a score. Buzz is strong exactly where the industry is weak — identity, attribution and revocation — and weak exactly where a compliance function looks first: containment, throttling, approval and custody. That is an unusual profile, and it tells you who the platform is for right now.

The forward read is that the identity layer will outlive the product. Signed, revocable, per-agent credentials with authorship preserved through delegation is the right primitive, and it is the piece other vendors will copy first — including the ones already putting agents inside the chat tools teams use, which we covered when agents arrived inside Slack itself. Packaging standards are converging on the same instinct from the other direction: our look at the vendor-neutral packaging standard for agent extensions covers how an extension gets built once and read everywhere. Buzz is arguing about the room and the identity; that standard is arguing about the payload. Both bets point at the same future, and neither has finished being made.

The practical move for most teams is smaller than adopting a platform. Take the scorecard above, run it against whatever you already use to give agents access, and see how many of the eight rows you can answer with a mechanism rather than a hope. Our AI and digital transformation engagements start with exactly that inventory — identity, scoping, throttling, approval and evidence — before anything gets deployed.