# OSS Radar #03: Buzz Is Slack on AIroids Buzz gives agents signed accounts and shared local compute. Delegation reliability and private code access remain unfinished. Block launched [Buzz](https://block.xyz/inside/introducing-buzz-where-humans-and-agents-work-together) on July 21 as an open-source workspace with team chat and signed work records for people and agents. Buzz can run Codex and Claude Code, and its Apple Silicon build lets members lend local model compute. A team assigns work and sees who acted. Restart-safe delegation and private repository reads remain unfinished. **Buzz is Slack on AIroids.** 1 key Each human or agent signs its events 12 msgs Threads and DMs load this history by default ## Agents join the same rooms Surface Buzz feature Result Workspace Channels and DMs People and agents share one room Agents Signed accounts and work history Each signed event has an author Buzz connects runtimes through the Agent Client Protocol (ACP) over stdio. Codex and Claude Code need ACP adapters. If either runtime creates a Git worktree or delegates to another agent, that runtime supplies the tool. Buzz queues the room message and records the reply. Its pool can process separate channels at once, but every process in one pool uses the same Buzz identity. ## Each agent gets a key Buzz gives each person and agent a Nostr key. In its draft owner-agent scheme, an owner signs an attestation for an agent key, and the agent signs its own events. The attestation records provenance; relay membership still controls access. Block states the rule: _“authorization does not erase authorship.”_ 1. Human identity **Human key** Signs the attestation attests to → 2. Agent identity **Agent key** Signs its own work produces → 3. Signed activity **Work events** Chat and code activity records → 4. Audit trail **Work record** Signed event history Relay check Shipped behavior Result Identity Verifies event signature and signed-in key Binds a signed event to one account Member-only access Closed workspaces and non-open channels check membership Ordinary writes honor those rules Buzz binds each accepted event to the authenticated key and verifies its channel access. A shared bot account can hide which agent announced or approved a change. Buzz keeps each agent's events separate across chat and Git. If someone steals a key, an admin can remove its relay access without changing the owner's account. The agent key does not change when its model or harness changes. Buzz should show those changes, or readers may assume the same software still runs it. ### The controls are unfinished Control Current state Gap Action rights Channel membership controls access No per-action approval Human approval Workflow creates an approval token Cannot resume after approval Buzz's workflow schema accepts schedule and HTTP webhook triggers. Owner attestation remains a draft Nostr extension that records provenance, while relay membership controls access. Human approval uses a separate workflow step that cannot yet resume a run; [Issue #2376](https://github.com/block/buzz/issues/2376) remains open and tracks the missing support. The audit fix leaves old rows behind [Issue #2637](https://github.com/block/buzz/issues/2637) reported that Postgres cut timestamp precision after Buzz hashed each audit entry. Buzz closed it on July 24 after [the fix](https://github.com/block/buzz/commit/264a56a2260ac87350bfe1f5d3ec3d89615eb47c) began hashing new entries at the precision Postgres stores. The change does not repair old rows, so operators must re-anchor chains they need. ### Some work stays outside the event log Buzz signs chat and Git events. Git objects live in another store, and voice frames never enter the event log. A reviewer can see which key announced a push or approved a change. Teams must check linked objects and later jobs elsewhere. ## Models still lose context Buzz keeps chat and agent work in one record. After a restart, an agent can search it, but only selected room history and memory enter the prompt. The relay may hold six months of chat while the model sees a small part of it. Control What the code does Limit Prompt input Channel mentions omit history; threads and DMs load 12 messages Large messages can still fill the prompt Recall Loads core memory and offers full-text search The agent must fetch notes or choose useful search words Buzz searches stored events with Postgres full-text search, which matches exact terms and may miss paraphrases. The agent must choose a query and inspect the results. Buzz loads core memory only when a new ACP session starts. Named memories require a lookup, and a long session may keep an old core record. Named memories stay out of the prompt until the agent fetches them. Room history is shared. Buzz keeps each memory note with one agent-owner pair. A team can pass facts through chat; Buzz has no common team memory store. ACP prompts carry full event IDs and tags. During a long native session, a handoff replaces old history with a model-written summary. After ten handoffs, Buzz drops older turns. > Stored history helps only when an agent loads it. When Buzz runs Codex or Claude Code through ACP, each runtime controls its own context and compaction. Buzz can track reported token use and add room history. The repository has no benchmark that compares token use with and without Buzz. One cost report [Issue #2631](https://github.com/block/buzz/issues/2631) reports one snapshot with four agents and about 220 Codex descendants. The same local history held 17.7 million cumulative tokens across 40 Buzz-created threads over three days. The reporter traced the process spike to eager 24-worker pools and notes that billed use may differ. ### Activity is not a terminal Buzz can show a parsed activity feed or raw ACP JSON-RPC frames. A local owner can stop the current turn. The view cannot attach to the agent's terminal or accept terminal input. Buzz can open a separate shell at the project checkout, but that shell does not join the running agent process. Buzz's native agent keeps sessions in memory and advertises `loadSession: false`. A restarted process starts a new ACP session and rebuilds context from the room and memory tools. It also waits for one non-streaming model response per round. Codex and Claude Code keep their own session rules behind their ACP adapters. A latency report, not a benchmark [Issue #2386](https://github.com/block/buzz/issues/2386) timed four short replies at 13 to 31 seconds. The sample has no matched run in a direct agent terminal. It cannot show whether the relay, queue, ACP session, model call, or reply publish caused the delay. ### Buzz restarts crashed agent processes The ACP layer sends one prompt at a time per channel and batches later events. If an agent process crashes, Buzz starts a new one. These controls do not replay work missed while the agent was offline. Agents can miss stored messages ACP subscribes to events from about five seconds before startup, and its default `mentions` mode accepts only tagged events. Open [issue #1743](https://github.com/block/buzz/issues/1743) reports missed offline mentions; open [issue #2270](https://github.com/block/buzz/issues/2270) reports missed untagged thread replies. ## Members can lend a local model Buzz's Apple Silicon release build includes shared compute through MeshLLM. A member picks a local model and turns on _Share this machine_. Buzz then offers that model to other members through a local OpenAI-compatible endpoint. Signed discovery data binds the member key to the serving node, and current community membership controls which nodes may serve. Part Shipped path Boundary Agent runtime Fizz runs through buzz-acp and buzz-agent Codex and Claude Code keep their own provider setup Model compute MeshLLM sends inference to a member node No price, payment, or per-member quota The runbook traces the built-in Fizz path from desktop to `buzz-acp`, `buzz-agent`, MeshLLM, and a member model. Shared compute acts as an LLM provider. It does not move a Codex or Claude Code harness to another member's machine. MeshLLM carries inference over direct QUIC or encrypted Iroh relays; the Buzz relay handles membership and discovery. The local provider caps an answer at 4,096 tokens and turns off model thinking. Buzz's code says this keeps output inside smaller local-model context windows. That choice favors short work. Buzz has no result that compares it with the same model outside Buzz. [Buzz calls Mesh a compute commons](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/VISION_MESH.md). Members who trust one relay lend spare hardware to each other, with no API key or cloud bill. Buzz plans a community compute pool. The X post adds a second idea: a market where agents or teams pay for work. ### Nostr can move the invoice. Buzz cannot price the job 1. Shipped **Signed key** Names the buyer, agent, or host signs → 2. Missing link **Job quote** Binds scope, model, price, and deadline starts → 3. Partial **Work record** Links the result and agreed use releases → 4. Missing path **Payment** Settles or cancels the invoice Buzz can record two kinds of use. When an agent runtime reports use, its [NIP-AM publisher](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-acp/src/pool.rs#L3316-L3361) stores an encrypted record with token counts and an estimated cost. A serving Mesh node also tracks requests, output tokens, and remote use. These records do not form one bill. The node keeps aggregate counters in local runtime status; neither record binds a member, one request, a price, and a payment. [Buzz's NIP-AM spec](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/docs/nips/NIP-AM.md) calls its cost estimate advisory. ### Funding shared hardware needs fewer rules than paid work Use Nostr piece Buzz gap Fund shared hardware NIP-75 goal and NIP-57 split tips Needs a wallet and funding UI Pay for an agent job NIP-90 job and NIP-47 wallet calls Needs billing and delivery rules A Buzz room could use [NIP-75](https://nips.nostr.com/75) to fund one GPU, then use [NIP-57](https://nips.nostr.com/57) to split tips among its hosts. That stays close to Buzz's current trust group: the community funds capacity, then membership grants use. It needs a wallet and UI, but no meter for each turn. [Open issue #265](https://github.com/block/buzz/issues/265) already lists NIP-57 zap events as relay work. A fixed price for an accepted job fits Buzz sooner than a token bill. Its Mesh counters cannot tie remote tokens to one member. [NIP-90](https://nips.nostr.com/90) sketches a request, bid, result, and BOLT11 invoice. Its text-generation job can name a model and cap output tokens. The Nostr project marks NIP-90 _unrecommended_ and leaves payment timing open. Buzz also [reserved its own job kinds](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-core/src/kind.rs#L379-L409) because delegation needs owner authorization chains. Buzz's relay does not accept those job kinds. [NIP-47](https://nips.nostr.com/47) could give an app or agent a separate wallet key, a wallet-set spending cap, and a way to make, pay, or hold an invoice. Buzz would still need a rule for when the parties settle or cancel it. NIP-57 can attach a tip receipt to a signed event and split the tip among keys. Buzz supports neither path. Its [relay rejects unknown event kinds](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-relay/src/handlers/ingest.rs#L195-L304), including NIP-57 receipt kind `9735`, and its [published NIP list](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-relay/src/nip11.rs#L8-L16) omits NIP-57. > Buzz has identity and usage records. It has not joined them into a price, bill, or payment. The X post's “instant zero-fee” claim goes too far. [routing nodes may charge a base fee and a rate](https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#htlc-fees). Payments can also fail when routes time out or lack capacity. NIP-57 warns that a zap receipt does not prove payment; the client trusts the wallet that signed it. A settled invoice still cannot show which model ran, whether the host counted tokens well, or whether the result met the job. The near bet is a funded compute pool inside one Buzz community. The far bet is an agent market across relays. An agent can keep one key, but its work history needs relay replication or a cross-relay index. Buzz has neither. Paid work also needs private prompts, budget controls, and a rule for bad results. Nostr supplies signed identity; Lightning moves the money. Buzz would still need the work and payment rules. ## Git review stays in Buzz Buzz runs a Git server. Its Projects preview shows pull requests and review decisions. Teams can host Git without GitHub, while runners and security tools remain outside Buzz. Private channels leave repositories readable Open [issue #2469](https://github.com/block/buzz/issues/2469) says every signed-in member of a Buzz community can read each hosted repository, including projects tied to private channels. Channel roles limit pushes while reads remain open. [PR #2539](https://github.com/block/buzz/pull/2539) adds private repository reads and remains open and unmerged. * * * ## One relay runs each community Block calls Buzz decentralized because it uses Nostr keys and signed events. One relay holds each community's record, and Buzz has no peer or relay replication. A team can run its own relay and reuse its keys on another server. Each community still depends on one operator for service and access. Who can read hosted Buzz Hosted messages and DMs lack end-to-end encryption. Block may read them or send them to outside model providers; by default, it keeps messages and media for up to 180 days. A self-hosted team controls its relay. Remote model providers may still receive prompts. The team must also run four persistent data volumes and own upgrades and recovery. ## Try one project room Trial Use it when Risk Hosted Two agents handle non-sensitive work Block and model providers may read the work Self-hosted The team can run the relay and data stores Model providers may still see prompts Wait when work needs reliable approval or offline delivery, or when code must stay private. Run the same tasks in Buzz and one direct agent runtime. Hold the inputs, model, token limit, and pass condition fixed. For shared compute, use the same local model on both paths. Measure time to the first visible step, completion time, tokens, extra messages, and task result. Stop if Buzz adds cost without cutting coordination work. ## Low-risk work is the current limit signal Delegation survives a restart Pause a code-writing run for human approval, restart the relay service, then approve it. The run should resume once. Next, mention an offline agent and restart it; the saved work should arrive once. Both tests must pass before teams trust work that waits for approval. signal Private project code follows room access A private-channel member should clone its repository. A signed-in non-member should get the same response as a missing repository. The agent account gives each agent durable authorship; shared compute lets members lend a local model. Nostr could fund that pool or turn signed jobs into paid work, but Buzz has not joined identity, use, and payment. Keep merge rights and secrets outside Buzz until the restart and private-read tests pass. Sources & Evidence Block launched Buzz on July 21 with an Apache-2.0 license and self-hosting support • Teams can inspect the code and run their own server. [Block launch](https://block.xyz/inside/introducing-buzz-where-humans-and-agents-work-together) Buzz provides Slack-like workspace tools and connects to separate agent runtimes • Teams can change the runtime without replacing the workspace. [Buzz vision](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/VISION.md) buzz-acp accepts any stdio ACP agent and can process separate channels in parallel • The runtime supplies worktrees and delegation; Buzz supplies the queue and shared identity. [ACP bridge](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-acp/README.md) Agents have their own keys and revocable relay access • An agent keeps its authorship when an owner attests to its key. [Block Engineering](https://engineering.block.xyz/blog/buzz) Owner attestation remains an optional draft Nostr extension • Relay access and action approval remain separate. [NIP-OA draft](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/docs/nips/NIP-OA.md) The relay verifies each signed event and matches its key to the signed-in key • An accepted event belongs to one authenticated account. [Relay ingest](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-relay/src/handlers/ingest.rs#L1459-L1503) Closed Buzz workspaces check membership during NIP-42 authentication • Workspace membership remains a separate access check. [Relay authentication](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-relay/src/handlers/auth.rs#L216-L238) Ordinary writes to non-open channels pass a membership check • Private channel writes require membership. [Relay access checks](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-relay/src/handlers/ingest.rs#L1762-L1802) The workflow engine fails runs that reach request\_approval • Buzz cannot yet resume work after a person approves it. [Workflow engine](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-workflow/src/lib.rs#L191-L208) The Buzz workflow schema accepts schedules and HTTP webhooks • The workflow format covers recurring work and outside triggers. [Workflow triggers](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-workflow/src/schema.rs#L33-L68) Open issue #2376 tracks work to pause and resume runs for approval • The missing approval path remained open on July 25. [Buzz issue #2376](https://github.com/block/buzz/issues/2376) Closed issue #2637 reported audit failures after timestamps lost precision • The report found why old audit chains failed verification. [Buzz issue #2637](https://github.com/block/buzz/issues/2637) Commit 264a56a hashes new audit entries at Postgres timestamp precision • New rows can verify, but the change does not repair old rows. [Audit precision fix](https://github.com/block/buzz/commit/264a56a2260ac87350bfe1f5d3ec3d89615eb47c) Large objects stay outside the event log, one relay holds each community, and ACP restarts crashed agents • Event signatures cover only part of the system; one relay and other stores remain required. [Buzz architecture](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/ARCHITECTURE.md) Buzz loads 12 messages for threads and DMs; agents must request ordinary channel history • The fixed limit uses fewer prompt tokens but leaves recall to the agent. [ACP context configuration](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-acp/src/config.rs#L364-L368) ACP prompt blocks retain full event metadata and tags • Those fields add tokens to each prompt. [ACP prompt formatting](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-acp/src/queue.rs#L1067-L1142) The native agent summarizes near its context limit, then drops old turns after repeated handoffs • The agent can lose facts during long tasks even when the room keeps them. [Native context handoff](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-agent/src/handoff.rs#L30-L107) Buzz loads core memory at session start; agents must fetch named memories • Long sessions can use old core memory, while named notes need a lookup. [Agent memory specification](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-acp/src/engram_fetch.rs) Each Buzz memory note belongs to one agent-owner pair • Shared room history does not create one common team memory store. [Agent memory records](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/docs/nips/NIP-AE.md) History retrieval uses filtered Postgres full-text search • Recall depends on useful search words. [Search query implementation](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-search/src/query.rs#L198-L323) Git clone, fetch, and push ship through standard Smart HTTP • Teams can host code on Buzz itself. [Git transport](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-relay/src/api/git/transport.rs#L1-L9) The Projects preview builds pull-request views and review decisions from signed events • Review work can happen inside Buzz. [Projects pull-request code](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/desktop/src/features/projects/projectPullRequests.mjs#L1-L114) Issue #2631 reports about 220 Codex descendants and 17.7 million cumulative tokens • Eager 24-worker pools can raise local cost; the report does not measure normal or billed use. [Buzz issue #2631](https://github.com/block/buzz/issues/2631) The activity panel can show raw ACP JSON-RPC frames and stop a local turn • People can inspect protocol activity, but they cannot attach to the live agent terminal. [Agent activity panel](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/desktop/src/features/channels/ui/AgentSessionThreadPanel.tsx#L276-L363) The native Buzz agent uses non-streaming model calls and cannot load a saved session • A process restart loses its in-memory session, and each model round arrives as one response. [Native agent](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-agent/README.md) The project terminal command opens a separate shell at the project checkout • It does not attach the user to the agent’s live process. [Project terminal](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/desktop/src-tauri/src/commands/project_terminal.rs) Issue #2386 timed four short replies at 13 to 31 seconds • The small sample flags latency but does not isolate its cause. [Buzz issue #2386](https://github.com/block/buzz/issues/2386) Open issue #1743 reports that an offline agent can miss a stored mention • The agent cannot act on a message it never receives. [Buzz issue #1743](https://github.com/block/buzz/issues/1743) Open issue #2270 reports ignored thread replies unless the agent gets a fresh tag • A person may need to tag the same agent on every turn. [Buzz issue #2270](https://github.com/block/buzz/issues/2270) ACP first subscribes from about five seconds before process startup • Older offline mentions may remain unprocessed. [ACP startup watermark](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-acp/src/lib.rs#L1325-L1353) Default ACP mention mode adds a tag filter to the relay subscription • An untagged thread reply does not reach the agent. [ACP relay filter](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-acp/src/relay.rs#L3171-L3194) Buzz enables MeshLLM shared compute in its Apple Silicon release build • The feature ships on one supported build rather than across every desktop release. [Release workflow](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/.github/workflows/release.yml) Buzz documents the Fizz path to a member model over direct QUIC or encrypted Iroh relays • The runbook traces one shared-compute path and keeps model traffic off the Buzz relay. [Shared compute runbook](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/docs/buzz-shared-compute-dev.md) The shared provider caps output at 4,096 tokens and disables model thinking • The settings bound what a shared local model can return in one round. [Shared provider settings](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/desktop/src-tauri/src/managed_agents/relay_mesh.rs#L11-L48) Buzz frames Mesh as a community-gated compute commons • Adding prices would change a trust-based pool into a market. [Buzz Mesh vision](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/VISION_MESH.md) Buzz publishes a NIP-AM record only when a runtime reports use and the agent has an owner key • A turn without reported use leaves no metric. [NIP-AM publisher](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-acp/src/pool.rs#L3316-L3361) NIP-AM marks token cost as an estimate and records it from the agent • The record can guide a budget but cannot prove what a provider should charge. [Agent turn metric spec](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/docs/nips/NIP-AM.md) A Mesh host reads request and output-token counts from its local runtime • The host sees session use but not the remote member, and both sides lack a signed bill. [Mesh serving usage](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/desktop/src-tauri/src/mesh_llm/mod.rs#L199-L269) NIP-75 defines goals that people can fund with zaps • A community could fund shared hardware without pricing each model turn. [NIP-75](https://nips.nostr.com/75) NIP-57 can link Lightning tips to events and split them among recipients • A room could reward one signed result or several hosts, though the receipt issuer remains trusted. [NIP-57](https://nips.nostr.com/57) Open issue #265 lists NIP-57 zap request and receipt kinds as relay work • Buzz has a path to store zap events, but it still needs the wallet and Lightning parts. [Buzz issue #265](https://github.com/block/buzz/issues/265) NIP-90 sketches paid compute jobs but is marked unrecommended • The closest open job-market spec leaves payment timing and bad-result rules open. [NIP-90](https://nips.nostr.com/90) Buzz reserves custom job kinds instead of NIP-90 kinds • Buzz chose owner authorization chains over the public NIP-90 job range. [Buzz job kinds](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-core/src/kind.rs#L379-L409) NIP-47 lets clients pay and hold Lightning invoices through encrypted Nostr requests • An agent could get a separate wallet key and wallet-set budget without holding the main wallet key. [NIP-47](https://nips.nostr.com/47) The Buzz relay rejects event kinds outside its write allowlist • NIP-57 receipts and Buzz job events do not pass the inspected write path. [Relay event allowlist](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-relay/src/handlers/ingest.rs#L195-L304) Buzz does not advertise NIP-47, NIP-57, or NIP-90 support • Using Nostr does not give Buzz a wallet, zap, or paid-job path. [Relay NIP list](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/crates/buzz-relay/src/nip11.rs#L8-L16) Lightning routing nodes may charge a base and proportional fee • Lightning payments can be cheap, but “zero-fee” is not a sound general claim. [BOLT 7](https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#htlc-fees) Open issue #2469 says every authenticated community member can read each hosted repository • A private project channel can expose its code to the whole community. [Buzz issue #2469](https://github.com/block/buzz/issues/2469) Open PR #2539 adds channel-scoped private repository reads but remains unmerged • Private channel code still lacks shipped read controls. [Buzz PR #2539](https://github.com/block/buzz/pull/2539) Hosted messages and DMs lack end-to-end encryption, and Block may access them • The relay operator may read sensitive work. [Buzz support](https://block.github.io/buzz/support.html) Block may send channel content to model providers and keep messages or media for up to 180 days • Outside model providers may receive workspace content. [Buzz privacy notice](https://block.github.io/buzz/privacy.html) The production stack requires four persistent data volumes • The team owns every backup and restore. [Deployment guide](https://github.com/block/buzz/blob/cfdea818dbd0a38ca6077de2bfafba755a6c7853/deploy/compose/README.md#L26-L42) ## Cite this ```bibtex @misc{koreli2026oss, author={Koreli, Goga}, title={OSS Radar #03: Buzz Is Slack on AIroids}, year={2026}, month={July}, howpublished={gkoreli.com}, url={https://gkoreli.com/oss-radar-03-buzz-is-slack-on-airoids}, note={CC BY-NC-ND 4.0} } ``` Koreli, Goga. (July 2026). "OSS Radar #03: Buzz Is Slack on AIroids". gkoreli.com. https://gkoreli.com/oss-radar-03-buzz-is-slack-on-airoids