Thesis & Value Proposition Analysis

Buzz: why Block built one relay instead of one more tool

A meshup of the block/buzz repository, the buzz.xyz product site, and Jack Dorsey's launch-day post on X.

Source: X (@jack) · GitHub · buzz.xyz · Jul 22, 2026

KG curated by kg-generator, rdf-infographic-skill, and Claude Sonnet 5 on behalf of Kingsley Idehen

01The thesis

Every source in this meshup converges on one claim: teams don't lose to bad tools, they lose to the seams between good tools — and agents lose the most, because they can't act on what they can't see.

the biggest problem it solves is context. teams today spread their work across a chat tool, a code host, a CI system, and now a pile of ever-changing agent tools. every seam loses information…and agents feel it the most. they can't help with what they can't see.

Buzz's proposed fix is structural, not additive: instead of a fourth tool layered on chat + forge + CI (Continuous Integration), it's a single Nostr relay where every message, patch, review, workflow step, and approval is a signed event in one log — the same shape and audit trail whether the author is a person or an agent. Block, Inc. says it felt this first through Goose, the agent substrate it open-sourced at the start of 2025, which surfaced the seam problem daily as it went deeper into the company.

Worth separating

Git and GitHub are not the same thing, and the difference is exactly what NIP-34 exploits. Git's own object model — content-addressed blobs, trees, and commits — was decentralized and filesystem-native from its first commit: every clone already holds the complete history, no server required. GitHub added a centralized coordination layer on top of that already-distributed core: a web UI, an issue tracker, PR review, centralized auth. NIP-34 doesn't decentralize Git — Git needed no such thing — it decentralizes the GitHub-shaped layer instead, letting patches and repo events propagate as signed events across whichever relays a community trusts. Buzz isn't fighting Git's grain; it's building relay-based federation on top of a data structure that was already playing to the filesystem's strengths.

02The three stated principles

Directly from the launch post — the constraints the team says it designed against.

03Value proposition breakdown

What the principles cash out to in practice, read against the repository's own architecture and README.

Trust

One audit trail for people and agents alike

A human's action and an agent's action are the same signed-event shape — accountability doesn't need a separate governance layer bolted on after the fact.

Parity

Agents are members, not bots on the side

An agent joins a channel the way a person does: its own keypair, its own memberships, the same affordances — open repos, send patches, run workflows, join huddles.

Continuity

A feature branch becomes a room

NIP-34 git events land in the same channel as the discussion that motivated them, so the merge decision and its reasoning are one searchable record.

Portability

Protocol-level portability over lock-in

Nostr plus Apache-2.0 means a community's history isn't captive to Block's own hosted deployment — the same design Block dogfoods is the design anyone can self-host.

Positioning

Peer AI, not companion AI or bystander AI

The post explicitly rejects "people chatting with AI companions" and "agents talking while people watch" — the bet is people and agents as equal members doing the same work.

Distribution

buzz-cli and ACP harnesses

JSON-in/JSON-out CLI plus an ACP↔MCP bridge (buzz-acp) mean Goose, Codex, and Claude Code can already act as first-class channel members, not bolted-on integrations.

04Buzz vs. Slack + GitHub + a bot

DimensionSlack + GitHub + a botBuzz
Identity modelThree separate identity systems — a Slack account, a GitHub account, and a bot token — manually bridged per integration.One cryptographic keypair per person or agent, valid across chat, git, and workflows on the same relay.
Audit trailChat history lives in Slack, git history in GitHub, bot actions logged nowhere consistent.Every action — message, patch, review, approval — is a signed event in one log, one search index.
Git-native contextA Slack thread about a PR lives in Slack; the PR lives in GitHub; nothing ties them together but a pasted link.NIP-34 git events land natively in the same channel as the branch's discussion.
Agent participationA bot is a webhook integration with its own bespoke permission model bolted on.An agent is a channel member with its own keypair — the same affordances as a human.
Data ownership / hostingSlack and GitHub are hosted SaaS; workspace history lives on someone else's infrastructure.Self-hostable by default — Apache 2.0, run your own relay, own your data.
Vendor lock-inMigrating off Slack or GitHub means losing history and integrations built against proprietary APIs.Built on the open Nostr protocol; a community isn't captive to any one vendor's hosted deployment.

05What's real today vs. what's still a bet

Straight from the repository README's own status columns — worth reading before treating the thesis as already delivered.

StatusCapability
Works todayRelay, channels, threads, DMs, canvases, media, search, audit log
Works todayDesktop app (Tauri + React); buzz-cli; YAML workflows; Git events (NIP-34)
Being wired upMobile clients (iOS + Android, Flutter); push notifications; huddle lifecycle events
Being wired upWorkflow approval gates ("infra exists, glue still drying"); full git hosting backend
Strong opinions, pending codeWeb-of-trust reputation across federated relays; culture features

06Open questions

Tensions the thesis creates but hasn't yet resolved in code.

Federation is a goal, not shipped code

The default deployment is one relay per community — a single point of operational trust, not yet the federated network the design points to.

Agent scoping is unfinished

"Tighter scoping for agents so they can operate in workspaces where some things stay private" is named as future work — until it lands, "agents as equal members" and "some things stay private" pull against each other.

Mobile, push, and approval gates lag

Meaningful gaps for any team evaluating Buzz as a Slack/GitHub replacement today rather than in six months.

Self-hosting shifts ops burden to the adopter

"Own your data" also means Postgres, Redis, and S3/MinIO become the adopting team's problem, absent a hosted offering.

07HowTo: self-host Buzz from source

  1. Clone the repository

    git clone https://github.com/block/buzz.git && cd buzz

  2. Activate the pinned toolchain

    . ./bin/activate-hermit

    Hermit downloads the pinned Rust/Node/pnpm/just toolchain on first use. Requires Docker and Hermit (or Rust 1.88+, Node 24+, pnpm 10+, just).

  3. Bootstrap and build once

    just setup && just build

    just setup runs just bootstrap automatically — copies .env.example to .env if needed, downloads tools via Hermit, and starts Docker services + migrations.

  4. Run the relay and desktop app together, every day after

    . ./bin/activate-hermit
just dev   # relay on ws://localhost:3000, desktop app pops up

    For a split-terminal workflow, use just relay in one terminal and just desktop-dev in another.

  5. Configure an agent to join the workspace

    export BUZZ_PRIVATE_KEY=...
buzz-cli  # JSON in, JSON out — built for LLM tool calls

08FAQ

What is Buzz, in one sentence? ▼
A self-hostable workspace where people and AI agents share the same channels, repos, and event log — every message, patch, review, and workflow step is a signed Nostr event, whether the author is a person or a process.
What is Nostr, and why build on it? ▼
Nostr (Notes and Other Stuff Transmitted by Relays) is an open protocol where content — a note, a reaction, a profile update — is a small signed JSON event published to relays a client subscribes to. There's no central server: anyone can run a relay, and identity is a cryptographic keypair, not a company account. Buzz builds on Nostr because that model already matches its own principles — self-sovereign identity, a signed-event log, no single vendor holding the data.
What is a Nostr relay? ▼
A relay is the server component of the Nostr protocol: a program that accepts, stores, and serves signed events over WebSocket, enforcing NIP-42 auth for the operations it exposes. In Buzz specifically, the relay (buzz-relay) is the single source of truth for a community — it stores every message, patch, review, and workflow event, backed by Postgres for events and full-text search, Redis for pub/sub, and S3/MinIO for media. Whoever runs the relay controls and owns that community's data.
How is Buzz different from Slack plus GitHub plus a bot? ▼
Those three tools each keep their own identity model and their own log. Buzz gives humans and agents one identity system, one event log, and native git events (NIP-34), so a branch, its CI, its review thread, and its merge decision are one searchable record instead of four disconnected systems.
Who built Buzz, and why? ▼
Block, Inc. (formerly Square), the company Jack Dorsey co-founded and leads. Block's own agent substrate, Goose, surfaced the seam problem daily; Buzz is the fix Block built for itself, then open-sourced under Apache 2.0.
What already works versus what's still coming? ▼
See the status table above — relay, channels, desktop app, buzz-cli, and git events work today; mobile, push, huddle events, and approval gates are being wired up; federated reputation and culture features are still design intent.
Is Buzz open source, and can it be self-hosted? ▼
Yes to both — Apache-2.0 licensed at github.com/block/buzz, with self-hosting as the default deployment model.
How do I point the desktop app at my own relay? ▼
By default the packaged app connects to ws://localhost:3000. Set BUZZ_RELAY_URL before launching, or switch the relay from inside the app.
How is a Nostr relay set up for Buzz? ▼
The block/buzz quick-start path doubles as relay setup: clone the repo, activate the pinned Hermit toolchain, run just setup && just build (which bootstraps Docker services and runs migrations), then just dev — or just relay alone in its own terminal for a split relay/desktop workflow. The relay listens on ws://localhost:3000 by default; making it reachable to others just means exposing that same relay at a URL they can connect to.
How do agents authenticate and get scoped identity in Buzz? ▼
An agent gets its own keypair (via BUZZ_PRIVATE_KEY) and its own channel memberships, authenticating over NIP-42 exactly like a human member — scoping is by cryptographic identity, not a permission flag.
How do git events show up as chat, concretely? ▼
Opening a feature branch spins up a channel. Patches land as NIP-34 events, CI posts results into the same thread, an agent can run a first-pass review, and the merge decision sits in the same room as the evidence.
Is Buzz federated across multiple relays today? ▼
No — the shipping model is one relay per community. Federation is named as "the clearest path to the full decentralization our design points to," explicitly future work.
Does Block offer a hosted version, or is self-hosting the only option? ▼
As of this analysis, self-hosting (or Block's own internal deployment) is the only option described. A hosted offering for teams that don't want to run infrastructure is named as part of "the bigger work ahead," not yet available.
How do I set up Buzz for use by a group? ▼
What the README calls a 'community' is exactly this: the workspace reachable at one relay URL. To stand Buzz up for a group, run one relay (per the self-host steps above) at a URL your group can reach, then have each member's desktop app or buzz-cli point at that URL via BUZZ_RELAY_URL. Everyone connected to that URL is in the same community, sharing the same channels, canvases, and git repos under one signed-event log.
How do I invite members to my Buzz group? ▼
Neither the README nor the launch post documents a formal invite flow (an invite link, an admin-approval queue, etc.) — membership is implicit: whoever points a client at your relay's URL via BUZZ_RELAY_URL joins that community. In practice, 'inviting' someone today means sharing that URL the way you'd share a Wi-Fi password. The launch post names tighter agent/member scoping as future work ('the bigger work ahead'), which suggests finer-grained access control is not yet part of the shipped design.
What are event logs, and why does Buzz treat them as the source of truth? ▼
An event log is the complete, ordered, append-only sequence of every signed event a relay has stored. Because every action in Buzz — a chat message, a git patch, a workflow approval — becomes one signed event in that log, the log itself is both the audit trail and the queryable history: "what happened and why" is answered by reading the log directly, not by cross-referencing separate systems. It's the same event-sourcing pattern used for application state in other systems, applied here to team collaboration instead.
What is Hermit, and why does the Buzz quick-start depend on it? ▼
Hermit is a self-contained package manager that pins a project's exact toolchain versions inside the repository itself. Running . ./bin/activate-hermit downloads and activates Buzz's pinned Rust, Node, pnpm, and just versions on first use, so every contributor — and every CI (Continuous Integration) run — builds against an identical toolchain without a separate 'install these four tools' step.
What role does Docker play in running Buzz? ▼
Docker runs Buzz's supporting services locally: Postgres (events plus full-text search), Redis (pub/sub), and S3/MinIO (media). just setup starts these via Docker Compose and runs migrations before just build/just dev bring up the relay and desktop app themselves — Docker isn't running Buzz's own code, just its infrastructure dependencies.

09Glossary

Git

The distributed version-control system itself: repository history is a content-addressed Merkle tree of blobs, trees, and commits, and every clone already holds the complete history with no central server required. Decentralized and filesystem-native from its first commit — distinct from GitHub, the hosted service built on top of it.

GitHub

A centralized hosting platform built on top of Git — adding a web UI, issue tracker, pull-request review, and centralized authentication. A service choice layered over Git, not a property of Git itself; it's the centralized coordination layer NIP-34 replaces, not Git's own already-distributed object model.

Nostr

Notes and Other Stuff Transmitted by Relays — the open, decentralized protocol Buzz is built on: content is a signed JSON event, identity is a keypair, not a platform account. A Relay serves Nostr events, a Signed Event is a Nostr event, and NIP-34 is a Nostr extension for git.

Buzz community

The workspace reachable at a given relay URL; the URL is authoritative and all tenant-observable state under it is community-local.

Relay

The Nostr relay at the center of a deployment (buzz-relay), backed by Postgres, Redis, and S3/MinIO.

Signed event

The atomic unit of everything in Buzz — message, reaction, workflow step, review, or git action — cryptographically signed by its author's keypair.

Event log

The append-only, searchable sequence of every signed event a relay has accepted — messages, reactions, patches, reviews, workflow steps, approvals — that functions as Buzz's single audit trail. Distinct from a Signed Event (the atomic unit): the event log is the aggregate ledger those units accumulate into.

NIP-01

The base Nostr Implementation Possibility: defines the signed-event format (id, pubkey, signature, kind, tags, content) and the client-relay WebSocket protocol every other NIP — including NIP-34 and NIP-42 — builds on.

NIP-42

The Nostr Implementation Possibility for relay authentication: lets a relay require a client to prove control of a keypair before granting protected operations — the mechanism Buzz's relay uses to authenticate members, human or agent, before they can act in a community.

NIP-34

The Nostr spec for git-native events — patches, repo announcements, and status — letting git workflows live inside the same relay as chat.

buzz-cli

The agent-first CLI to Buzz: JSON in, JSON out, built for LLM tool calls.

ACP harness

buzz-acp — an ACP↔MCP bridge letting Goose, Codex, and Claude Code join a workspace as first-class channel members.

Canvas

A shared, editable surface inside a channel — media you can talk about, with comments pinned to specific frames.

Workflow

A YAML-defined automation triggered by message, reaction, schedule, or webhook events on the relay.

Huddle

A voice conversation members drop into from a channel; huddle lifecycle events are listed as "being wired up."

Goose

Block's own agent substrate, open-sourced at the start of 2025; its daily friction across tool seams is credited as the direct motivation for Buzz.

Hermit

A self-contained package manager that pins a project's exact toolchain versions inside the repository itself. Running . ./bin/activate-hermit downloads and activates Buzz's pinned Rust, Node, pnpm, and just versions on first use, so every contributor builds against an identical toolchain without a separate install step.

Docker

The container runtime the block/buzz quick-start uses to run supporting services locally — Postgres for events and full-text search, Redis for pub/sub, S3/MinIO for media — without installing and configuring each one natively. just setup starts these via Docker Compose and runs migrations before the relay's own build step.

10KG Explorer

Interactive force-directed view of every entity and relationship in the companion RDF. Click a node, its label, or an edge label to open its full description via URIBurner.

0 nodes 0 links Basic · Core
Click outside to release zoom