Block Buzz review: a Nostr workspace for humans and AI agents

A technical review of Block's Buzz, its signed-event architecture, agent identity model, practical strengths, production gaps, and fit for software teams.

Buzz is Block’s answer to a question software teams are starting to encounter: where should AI agents work once they do more than answer a prompt?

The project combines team chat, code repositories, workflows, search, media, voice, and agent orchestration in one self-hostable workspace. Humans and agents use the same rooms. Each participant has a cryptographic identity, channel membership, and a signed history of actions.

Block publicly launched Buzz on 21 July 2026 under the Apache 2.0 license. Within its first week, the GitHub repository approached 15,000 stars and passed 1,200 forks. A Better Stack walkthrough passed 50,000 views within days.

The interest is understandable. Buzz presents a more coherent model for agent collaboration than adding another bot token to Slack.

It is also a pre-1.0 system with several important boundaries documented in its own architecture.

What Block Buzz is

Buzz uses the Nostr event format. A message, reaction, workflow step, review approval, canvas change, or git event becomes a signed object with an author key, type, content, and signature.

The relay is the single source of truth. It authenticates clients, verifies signatures, checks channel membership, stores events, fans them out to subscribers, indexes searchable content, records an audit trail, and triggers workflows.

The main infrastructure is conventional:

a Rust relay and desktop application;
PostgreSQL for events, channels, workflows, tokens, search, and audit data;
Redis for pub/sub, presence, and typing;
S3-compatible storage such as MinIO for media and git objects;
ACP to connect agent harnesses;
MCP to give agents tools.

Buzz supports Block’s Goose, OpenAI Codex, Claude Code, and other ACP-compatible agents. The agent-facing CLI uses JSON input and output, which is a sensible boundary for tool-driven work.

A community is selected by the URL. In the default self-hosted deployment, one host maps to one relay and one community. Hosted deployments can share infrastructure while keeping community-visible state scoped to the request host.

The strongest part is identity

Most current team integrations treat an agent as a webhook, shared service account, or API token attached to a human workspace.

Buzz gives each agent its own keypair. The relay can distinguish a human message from an agent message, check which channels that agent belongs to, and retain the signature on every accepted event.

That creates a better answer to several operational questions:

Which agent proposed this patch?
Which channel context could it read?
Which human approved the next step?
Which model or harness was connected to that agent identity?
What happened before and after the action?

Identity does not make an action correct. It makes responsibility easier to trace.

What Buzz gets right

Messages, patches, workflow events, approvals, and reactions use the same underlying event shape. An agent is not confined to a chat reply if the workspace gives it access to repositories, workflows, canvases, or huddles.

This is closer to how software teams actually need to supervise agent work: inside the project history, beside the people and artifacts affected by it.

The system is model-agnostic

ACP separates the workspace from the agent harness. MCP separates the agent from its tools. Buzz can connect different models without making the relay understand their internal implementation.

That reduces vendor coupling and gives teams a stable place to apply their own identity and access rules.

Self-hosting is part of the architecture

The repository includes a production Compose path rather than treating self-hosting as a future promise. Teams can run the relay with their own PostgreSQL, Redis, object storage, domain, and TLS termination.

This does not make operations free. It does give the organization control over the event store and deployment boundary.

The documentation states uncomfortable limits

The architecture document explains which paths are synchronous, which work is fire-and-forget, what is not implemented, and where multi-node behavior differs.

The security policy says the project is pre-1.0, supports only the current main line fully, and distinguishes tamper-evident audit data from tamper-resistant storage.

That level of specificity is more useful than a broad “enterprise-ready” label.

Where Buzz is not ready

Channel membership is a coarse permission model

Buzz currently treats channel membership as the access-control gate. A participant inside a channel can read and write there. The architecture does not implement a separate capability taxonomy.

That is understandable for people. It is too coarse for agents that can send patches, run workflows, call tools, create channels, or orchestrate other agents.

A production agent needs separate authority for reading context, proposing a change, executing a workflow, using a secret-bearing tool, approving a step, and publishing a result. Identity and channel membership are necessary, but they are not least privilege.

Rate limiting is a design target, not an enforced control

Buzz documents four proposed rate-limit tiers, but its architecture states that no Redis-backed rate limiter is currently implemented.

This matters more in an agent workspace than in ordinary chat. One faulty loop can produce thousands of messages, tool calls, workflow events, or child-agent requests before a person notices.

Approval gates are not wired end to end

The workflow engine contains approval concepts and grant/deny endpoints, but the current architecture says runs that reach an approval gate fail before creating the expected waiting state.

Human approval is central to the product story. Until that path is complete and tested under failure, teams should keep consequential actions behind an external control plane.

The audit trail has a defined threat boundary

Buzz chains audit records with hashes. This detects accidental corruption or an isolated row edit.

The chain is keyless. An attacker with database write access can modify history and recompute the chain. Buzz accurately calls this tamper-evident rather than tamper-resistant.

Teams with stronger compliance requirements would need external anchoring, immutable export, independent signing, or another control outside the same database trust boundary.

Signed events do not make hosted content private

Launch reporting notes that messages and media on Block-hosted relays are not end-to-end encrypted. Connected model providers may also receive prompts and related channel content.

Cryptographic authorship proves who signed an event. It does not encrypt the event from the relay operator or the model handling it.

Nostr is used as a protocol, not a replicated network

Buzz inherits signed identities and event shapes from Nostr. Its current architecture still has one authoritative relay per community, with no peer-to-peer exchange, gossip, or relay replication.

That design is simpler and may be correct for a company workspace. Teams should evaluate it as a sovereign single-relay system, not assume that the usual Nostr resilience properties automatically apply.

Pros and cons

Pros

separate cryptographic identity for every human and agent;
one signed event model across chat, code, workflows, and approvals;
model-agnostic ACP boundary and MCP tool integration;
Apache 2.0 source and a documented self-hosting path;
conventional, inspectable infrastructure with PostgreSQL as the event store;
explicit community boundaries for hosted multi-tenancy;
serious architecture, testing, and security documentation.

Cons

pre-1.0 with rapid change and support focused on main;
channel membership is too broad for fine-grained agent authority;
rate limiting is not currently enforced;
approval gates are not complete end to end;
the audit chain detects tampering but cannot resist a database-level attacker;
hosted content is not end-to-end encrypted;
self-hosting requires operating several stateful services;
the single authoritative relay remains a concentration of availability and trust.

How Buzz fits the HILLS Lab context model

Our Trustworthy Agent Memory guide argues that team context needs source identity, actor identity, permissions, freshness, conflict rules, and retrieval traces.

Buzz makes meaningful progress on actor identity and provenance. A signed event can retain who produced an action and where it entered the workspace. Bringing messages, code, approvals, and workflow state into one event log also reduces the fragmentation that makes agent activity difficult to review.

The next gap is authority.

An agent should not receive every capability available to a human simply because both are first-class participants. A useful team-context layer needs permissions attached to sources, retrievals, tools, and actions. It should record the permission snapshot used at the time of a decision, not only the channel in which the decision occurred.

Buzz provides a credible substrate for that direction. Its current access model does not finish it.

Our verdict

Buzz is one of the more technically coherent attempts to design a workspace around human-agent teams. The important idea is not that chat needs more AI. It is that an agent should have its own identity, history, membership, and accountable place in the project.

We would trial Buzz on a bounded internal project with:

a dedicated relay and test data;
separate identities for every agent;
narrow channel membership;
no production secrets in agent-accessible context;
external approval for deployment, deletion, payment, and permission changes;
an independent repository or export path for critical code and records.

We would not yet replace a mature Slack and GitHub setup across a company. The operational history, permission depth, recovery procedures, and approval paths need more evidence.

The repository’s speed and attention make Buzz worth following closely. The design is pointing at a genuine problem. The next test is whether its identity model can grow into a permission model strong enough for agents that do consequential work.

If your team is deciding how agents should access context, tools, and approvals inside an existing engineering workflow, talk to HILLS Lab.