Buzz: A Corporate Nostr Workspace, Evaluated
Reference notes on block/buzz, a self-hostable humans-and-agents workspace built as a Nostr relay. Read at commit 95fdf97, dated 2026-07-26. Every file citation below links to that commit, so the sources stay fixed as the project moves on.
1. Provenance
Block, Inc. Apache 2.0. Formerly Sprout: the workspace manifest still declares repository = "https://github.com/block/sprout", and the first substantive commit (2026-03-09) reads "Initial release, Sprout Nostr relay with enterprise extensions." 1,872 commits in under five months, roughly fifteen human contributors.
Note the author list: several hundred commits are signed by bare npubs with addresses at sprout-oss.stage.blox.sqprod.co. Their agents commit under their own keypairs. The claim is load-bearing, not decorative.
2. Languages
| Language | Tracked LOC | Where |
|---|---|---|
| Rust | 333k | 27-crate workspace: relay and every backend service |
| TypeScript + TSX | 291k | desktop/ (Tauri 2 + React), web/, admin-web/ |
| JavaScript (.mjs) | 71k | build, test harness, tooling |
| Dart | 60k | mobile/, Flutter for iOS and Android |
| Python | 4.8k | scripts |
| SQL | 3.5k | 31 Postgres migrations |
| Swift / Kotlin | 1.9k | platform shims |
3. Substrate libraries
Backend: axum 0.8 (WebSocket and REST), tokio, sqlx 0.9 against Postgres, redis 1.0 with deadpool for pub/sub, presence and typing, rust-s3 (pinned to a Block fork for EKS Pod Identity credentials) for Blossom media, rmcp 1.1 as MCP server, evalexpr + cron + serde_yaml for the YAML workflow engine, OpenTelemetry and Prometheus throughout. iroh 1.0.0-rc drives buzz-relay-mesh.
Frontend: Vite, React, Tailwind, Biome, Playwright, Tauri 2 with the keyring crate for OS-native secret storage. Mobile: hooks_riverpod, web_socket_channel, pointycastle, flutter_secure_storage.
4. Nostr libraries
Rust: nostr 0.44.3 from rust-nostr, features nip44 and nip98. Present in twenty of twenty-seven crates plus the Tauri shell. Deliberately the primitives crate, not nostr-sdk; nostr-sdk 0.44.1 appears in the lockfile only transitively, pulled in by the vendored mesh-llm tree. They have no use for a relay pool because they are the relay.
TypeScript: nostr-tools ^2.23.3 in desktop and web, used narrowly: nip19 encode/decode, pure for verifyEvent/finalizeEvent/getPublicKey, and nip42's makeAuthEvent. No NDK, no applesauce.
Dart: nostr ^2.0.0 plus pointycastle.
mesh-llm, thirty-nine crates from Mesh-LLM/mesh-llm at tag v0.73.1, vendored by git dependency. This is the Buzz Mesh shared-GPU layer, and it is the only consumer of nostr-sdk in the tree.
Protocol surface
NIP-01, 09, 10, 11, 17 (gift wrap, the only DM mechanism; NIP-04 and NIP-44 wire formats are unimplemented), 25, 29 as the spine, 34 (git patches), 42, 43, 50, 70, 98, plus Blossom BUD-01/02. The NIP-28 compatibility proxy was removed.
buzz-core registers 81 kinds and claims 40000 to 49999 as a house range. Fourteen unpublished house drafts sit in docs/nips: agent authentication, engrams, turn metrics, observability, personas, channel window, DM visibility, reminders, git object signing, identity archival, owner attestation, push leases, read-state sync, workspace profile. A fifteenth, NIP-AB (one-time secret transfer between devices over an untrusted relay), lives in crates/buzz-core/src/pairing.
5. Relays
This is where the evaluation turns.
Buzz is a relay, and it consumes no others. Default ws://localhost:3000; the packaged desktop app follows BUZZ_RELAY_URL. There is no outbound publication path anywhere in the tree, no NIP-65 outbox implementation, no cross-relay read. Kinds 10002 and 30003 are storable as list events through buzz-cli social, but nothing in the relay reads or acts on them. VISION_SOVEREIGN.md claims short notes "propagate across the nostr network"; the code does not do this today.
The named endpoints:
| Endpoint | Role |
|---|---|
wss://relay.damus.io |
default rendezvous for buzz-pair device pairing; the single point at which Buzz touches infrastructure it does not own, and only as a courier for an encrypted payload |
wss://pairing.buzz.xyz |
Block-operated alternative, set by BUZZ_PAIRING_RELAY_URL, advertised in the NIP-11 document |
https://push.buzz.xyz/v1/... |
APNs push gateway |
*.communities.buzz.xyz |
hosted multi-tenant provisioning namespace |
wss://sprout-oss.stage.blox.sqprod.co |
Block staging; the relay their agent contributors sign from |
buzz-relay-mesh deserves precision because the name misleads. It is an iroh QUIC mesh between relay runtimes, that is, pods of one deployment: membership gossip, tunnel traffic, huddle audio fan-out, with Redis holding the fencing generation as arbiter. It is horizontal scaling, not federation. Grepping the tree for "federat" returns exactly one hit, in a Helm README.
Access control: the host resolves the community, NIP-42 challenge is proactive, optional pubkey allowlist is fail-closed, NIP-43 relay membership can be mandatory, and subscriptions to p-gated kinds are rejected unless every #p value matches the authenticated pubkey.
6. Convergence with buildtall
They chose our primitives. Secp256k1 keypair as identity, signed events as the sole record, NIP-42 for authentication, Blossom for blobs, self-hosting as the default posture. VISION_SOVEREIGN.md is closer to our doctrine's register than anything else operating at that scale, down to the "What You Give Up" section that enumerates key loss, ops burden and onboarding friction without flinching.
Their agents-as-members model (own keypair, own channel memberships, own audit trail, reputation as accumulated signed history rather than a platform-assigned number) is Benkler-shaped commons production, and the relay-as-shared-medium is stigmergy in the strict sense. Their authorship posture matches ours: agent authors, humans approve.
7. Divergence, in order of consequence
1. The unit of sovereignty is the workspace, not the person. A Buzz community is one relay behind one domain, with owners, admins, rosters and moderation kinds. Our unit is the individual dataspace: a personal ontology (kind 30101) portable across relays, belonging to nobody's roster. Buzz confers a sovereign organization. We confer a sovereign human. Their own documentation states the consequence plainly: "DMs and profiles do not inherit across community domains." The key is portable; the corpus is not.
2. Terminal relay. No outbox, no gossip, no traversal. A Buzz community that dies takes its entire record with it, because nothing replicated it anywhere. Our stack assumes the opposite at every layer: r2n publishing outward, listoflists reading across relays, ithaca as home relay with writeback. This is the largest architectural gap between us, and it is the one that decides whether the thing resists enclosure at the data layer or only at the deployment layer. By our decision rules, Buzz passes the second test and fails the first.
3. The relay is the system of record. Postgres for events and full-text search, Redis for fan-out, S3 for blobs, Helm for orchestration. ARCHITECTURE.md states it outright: "Single source of truth: the relay." The clients are views. This is not local-first, and it inverts our invariant, where local SQLite holds the truth and the relay is replication substrate.
4. Custom-kind sprawl as an observed failure mode. Eighty-one kinds, a private 40000 range, fourteen unpublished drafts. Their own compatibility table concedes that kinds 40002 and 40003 "work on the wire but no standard NIP-29 client renders these." Interoperability is real at the NIP-29 boundary and abandoned above it. Worth holding as evidence: this is how an open protocol quietly becomes a private one under product pressure, and we are not immune (see kind 30101).
5. Two distributions. The README instructs Block employees to skip the OSS build and take the internal one, "pre-wired to the Block relay and agent provider." The hosted *.communities.buzz.xyz path offers the same codebase with the sovereignty delegated. Through the Carse lens the repository carries both games at once: the OSS relay is infinite play, the hosted tenancy is finite positioning. Which one compounds is not yet decided by anything in the code.
6. Different customer. Their center of gravity is agent labor inside a team: ACP harness for Goose, Codex and Claude Code, MCP tooling, personas, engrams, turn metrics. Ours is the headless lifestyle for one human. Not competitors; barely adjacent markets.
8. Directly extractable
- NIP-AB, one-time secret transfer between devices over an untrusted relay, with a working Rust implementation in crates/buzz-core/src/pairing and a Flutter counterpart. Immediately relevant to autograph key provisioning and to buildtall-android.
- git-sign-nostr and git-credential-nostr, standalone crates making a nostr key a git signing and credential identity, with NIP-GS as the accompanying spec. Their own commit log is the proof of operation.
- NIP-PL (push leases) is the most rigorous draft in the set and is worth reading whatever we think of Buzz, given we have deferred push notifications repeatedly.
- NIP-29 plus NIP-42 plus NIP-43 as a working reference for a membership-gated relay, which is precisely delos's problem.
- Confirmation that the rust-nostr 0.44 line carries production load. Cross-check only; we are on go-nostr moving to
fiatjaf.com/nostr.
9. Verdict
Buzz is the most serious corporate implementation of nostr-as-infrastructure yet built, and it is honest about its costs. It solves organizational sovereignty against GitHub and Discord. It leaves individual sovereignty to the individual: the events remain portable Nostr events, but nothing in the product replicates them anywhere, no export path exists, and the ability to take a copy lasts only as long as relay membership does.
The thing to take from it is the pairing spec, the git-signing crates, and one sharp question to hold against our own work: if the relay disappears tomorrow, what does the human still have?