Block Can Read Your Team's Buzz Messages. Unless You Host It Yourself.
Seventeen days running a self-hosted relay: the exact stack, what it really costs you, and the three things the install docs don't tell you.
I'm writing this after seven days of running Buzz, five of them as the workspace for the Artificially Intimidating community — a founding cohort of 18 members that's growing strongly, one custom greeter agent (Artie), three upstream issues filed, one PR in review. The setup described here is the one that's running on my self-hosted relay right now. We're keeping the community doors open for 7 more days from publish — if this guide sounds like your kind of place, come see what an early Buzz community looks like from the inside.
This is the open-source AI workspace Jack Dorsey launched July 21, 2026 — not Bitchat, the mesh app from the same team.
Is this for you?
You run agents somewhere. You've been duct-taping them into Discord bots or Telegram groups. You want them in a shared room with real identities, signed actions, and infrastructure you control.
That's who this is for.
If you don't run agents, Slack is fine for you and Buzz isn't going to be. Don't waste your time.
What's in this guide:
References and field reports linked at the end.
1. What Buzz Is, In Three Sentences
Buzz is an open-source workspace where humans and AI agents are first-class members of the same channels, threads, and huddles. It's built on Nostr — the same cryptographic identity protocol that powers decentralized social networks — which means every message, code commit, and approval is signed by a keypair, not a session token. The agents that join your team aren't Slack bots; they're autonomous processes with their own identities, capable of being @-mentioned, assigned work, and held accountable in an audit log.
That's it. Everything else in this piece is detail.
2. Why the Buzz Launch Hit Different
Jack Dorsey has launched a lot of things. Square, Cash App, Bitchat, the Bluesky project. Most landed with a press cycle and a slow adoption curve. Buzz, by contrast, hit 5.9 million views on Dorsey's announcement post, roughly 8,900 GitHub stars on block/buzz on day one … 1,900 forks and 19k+ stars at the time I'm writing this, a 378-point Hacker News thread with 339 comments, and roughly a million installs by day six. That's not normal for an open-source workspace, and it's worth asking why.
The answer, looking at who showed up: the audience wasn't enterprise IT. It was builders and creators who were already running agents in their workflows and had hit the obvious ceiling. Those agents lived in silos. Different harnesses, different context windows, no shared room. Buzz proposed a room.
For the bigger case on why Block launched Buzz in the middle of a SaaSpocalypse instead of building yet another chat app, see the inversion piece.
3. The Three Things That Are Actually Different
If you've used Slack-with-a-bot, you've used the surface. Buzz is different in three concrete ways.
Agents are members, not integrations.
In Slack, a bot is something you install and configure into a channel. In Buzz, an agent has a cryptographic identity, can be created and removed at will, and is a member the same way a human is. It can read channel history. It can be @-mentioned. It can be removed from a channel.
The harness is swappable, the context is not.
An agent in Buzz is a thin layer on top of a "harness": Claude Code, Codex, Cursor, Goose, OpenCode, OpenClaw, Hermes. You can switch the harness underneath an agent without losing its memory, its system prompt, or the context of every conversation it's had. The harness is the implementation; the agent is the persona. That's a useful separation.
Everything is signed, nothing is owned by a middleman.
Because Buzz runs on Nostr, every action is signed with a keypair. A message, a code commit, an approval emoji — all of it carries a signature. This isn't marketing; it's the protocol. The implication is that you can self-host your relay, hold your own data, and run an audit log that doesn't pass through Block's servers unless you want it to. Slack can't do that. Discord can't do that. Linear can't do that.
4. Download and Identity (First 10 Minutes)
You download Buzz from buzz.xyz. The app is a desktop client. It runs on macOS, Linux, Windows. When you first launch it, you're asked to either generate a fresh Nostr keypair or import an existing one. If you're new to Nostr, generate. You'll see a 12-word seed phrase. Save it offline. That phrase is your identity; if you lose it, you're locked out of every community you've joined.
The keypair is the part most people miss. It's not a username and password. It's a cryptographic identity that belongs to you, not to a service. As long as you have the key, you can sign as yourself anywhere Nostr runs.
You'll know it worked when the honeycomb icon stops pulsing.
5. Hosted vs Self-Hosted (And Why You Probably Want Self-Hosted)
Buzz gives you two options: Block-hosted relay, or self-hosted relay on your own infrastructure. The choice matters more than the install docs suggest.
Block-hosted spins up a relay + database + object store on Block's servers when you create a community. Messages are signed and stored, but Block can read them for moderation and legal reasons. Half of X called this out on launch day. It's not a scandal, but it does mean Block can see your team's conversations.
Self-hosted — puts all of that on infrastructure you control. I went self-hosted because the whole point of a cryptographic identity layer is that the user owns the data, not the platform.
The easiest way to do all of the above is cut and paste the github repo url into your instance of Claude code (or similar) and say help me set this up. For m ore context, Here's what the actual stack looks like, in case you want to replicate it:
$9 per month VPS on Hostinger, Ubuntu, Docker Compose with a
deploy/composederivative andrun.shPostgres 17 for the relay's database
MinIO / Blossom as the object store for media
Caddy in front for Let's Encrypt TLS and automatic certificate renewal
A
buzz-pairsidecar started manually (the compose bundle doesn't run it by default, so/pair404s until you start it; this is upstream issue #2734)HTTP/3 disabled in Caddy to fix iOS connectivity (the iOS app's websocket couldn't hold a connection with HTTP/3 negotiation; disabling it forces HTTP/2 and the app works fine)
Nightly Postgres backups
The image runs as ghcr.io/block/buzz:main (moving tag), with the desktop app on 0.5.2 at time of writing. One real gotcha: run.sh start doesn't pull new images, so the relay sits behind on patches unless you explicitly run docker compose pull. I learned this the hard way.
6. Picking Your First Harness
Buzz is a layer on top of agent harnesses. The harness is the actual agent process — it does the model calls, the tool invocations, the file system work. Buzz wraps it with identity, channels, and signing.
Out of the box, Buzz detects which harnesses you have installed on your machine. The supported set as of v0.5.2:
Claude Code — Anthropic's coding agent. Strong on reasoning, weak on filesystem sandboxing unless you configure the Claude settings file yourself.
Codex — OpenAI's coding agent. Best filesystem sandbox of the three; isolated by default.
Cursor — the Cursor IDE's CLI. Good if you're already in the Cursor ecosystem.
Goose — Block's own open-source agent. Worth a look if you want to stay on Block's stack.
OpenCode, OpenClaw, Hermes — additional adapters available.
The choice isn't just preference — it's a security setting. Hermes isolates connectors per agent. Codex sandboxes the filesystem. The Claude runtime, as of v0.5.0, did neither. I filed PR #3550 to default Claude-runtime agents out of inheriting the operator's claude.ai connectors, mirroring Block's own Hermes PR #3420 (merged July 29). Mine is open with all three CI checks green and one external maintainer's review already addressed, waiting on a Block maintainer. If you're choosing a harness today for any agent that touches real data, pick one whose blast radius is already constrained. Then add the rest later.
7. The Default Agents (And Why You'll Probably Keep Them)
When you first install Buzz, three demo agents ship by default: Fizz, Honey, Bumble. Their personalities are baked in:
Fizz is the agentic maker — upbeat, practical, decisive. Plans, creates, solves problems, finishes work.
Honey is the warm, thoughtful communicator. Helps write, organize, brainstorm.
Bumble is the researcher. Sifts, gathers, verifies.
You can rename them, replace them, or build from scratch. Most people won't. The defaults are well-tuned for the jobs they're meant for, and trying to build a custom greeter from scratch is a known lesson-learned — the demo agents do it better out of the box than most from-scratch personas.
Artie is the custom agent I built for the Artificially Intimidating community — a greeter and onboarding agent. Built on the Claude Code harness. Stays in the hive until we can prove it won't sting anyone: it's currently configured respond_to = Only me and meant to stay boxed pending a machine-layer sandbox. It works; it just doesn't run unsupervised in channels where it can act on member messages. For the Artie story — why the greeter is boxed, and what we learned the hard way about agent guardrails — see the community piece.
8. Creating a Custom Agent
When the defaults don't fit, build one. In the Agents tab, click "New Agent," choose a name, pick an avatar, write a system prompt, and select the harness. The system prompt is what shapes the persona — everything the agent does well flows from how clearly you write the prompt.
Two rules that should gate every agent you build:
Not everything should be an agent. If the job is deterministic — reconcile membership, post a scheduled digest, sync a list — it's a cron job or a shell script. Cheaper, reliable, and it can't be talked out of the rules. Reach for an agent only when the job needs judgment.
Enforcement lives below the prompt. An agent's persona rules are manners, not guardrails. The real limits are respond_to (who can invoke the agent), the harness choice (which determines what blast radius the agent gets), and — for anything internal — an OS-level sandbox before the agent goes live.
9. Adding Agents to Channels
Three ways, same effect:
Search and add — open channel settings, search for the agent, click Add.
@mention an agent that's not yet in the channel — Buzz auto-adds on first mention.
DM the agent directly — for solo work, no channel needed.
The third is the most underused. A direct message to an agent is its own private session — full context, no channel noise, and the agent's response is just for you. For research and one-off tasks, it's where most of my real work happens.
10. Memories: Agents That Know You vs. Agents That Don't
Each agent has a memory store. You can view it, edit it, and the agent writes to it as it learns preferences across conversations. The first time you set up an agent, its memory is empty — every interaction is a fresh start. By the tenth interaction, the agent has started forming a model of who you are and what you want. By the hundredth, it's actually useful.
The trap: an agent with no memory is a stranger. An agent with partial memory is dangerous — it'll act on outdated assumptions. The pattern that works is to give agents narrow, durable preferences ("always speak in a friendly pirate voice" / "always cite sources inline" / "never post without explicit approval") and review the memory file periodically. Don't let agents accumulate silently into something you can't audit.
11. The Management Channel
This is my daily driver: a single private channel with one management agent that knows my Notion, my email triage rules, my priorities for the week, and what I should be doing right now. The agent reads the state of the world on request and returns a short, ordered list.
It's not glamorous. It doesn't write code or post to social. It's a chief-of-staff that knows my context. The reason it works is that it's narrow — the agent has one job, one set of tools, one system prompt, and respond_to = Only me. No member can invoke it. No prompt injection from a channel can reach it.
If you build exactly one internal agent on Buzz, build this one. Until you've used a context-aware agent that reads your actual state and returns an ordered "do these three things next," you don't know what the platform is for.
12. Content Production (The Mike Russell Pattern)
Mike Russell, who runs Creator Magic, has the most fully realized content workflow I've seen on Buzz. The pattern:
Wizard (Claude Code, research agent): monitors your published work, builds a brand-voice canvas in the channel.
Merlin (Claude Code, writer agent): scoped to one job — write posts in your voice, no commentary, one post per reply.
Zapier webhook on every message in the channel: captures the draft to a Zapier Table tagged by message ID.
Approval workflow: when Mike reacts with 👍 to a post in Buzz, a second webhook fires, looks up the message in Zapier Table, posts to LinkedIn.
His own summary is the sharpest framing: "I just reacted with an emoji inside Buzz and the emoji was signed by my key. That's huge."
The point isn't the LinkedIn integration. The point is that the approval gesture is signed by his Nostr key, lives in the channel's audit log, and the actual publish happens via Zapier — never by an agent with direct write access. That's the template: agents draft, humans sign, integrations execute.
13. Coding and Product
For builders, the obvious use case is the one Vinny Lingham (@hot_town) walked through in his Setup Guide: an agent that takes a prompt, spins up a Wasp app, deploys to Railway, returns a URL. That works. It's the canonical "vibe-coded-and-deployed" loop, and Buzz is genuinely good at it.
The deeper pattern is the same as content: keep your lead agent on Codex or Claude Code with all your skills loaded, and use the harness-swap feature to bring in cheaper models for lower-stakes subtasks. Fizz on Fable for planning, Honey on Sonnet for summarizing, your custom code-review agent on Codex for diffs. The harness-switch takes one click; the context doesn't move.
14. Customer Support Triage
Honest read: this is where Buzz is weakest today. Customer support requires strict data boundaries (no agent should see customer PII unless scoped), a reliable audit trail (every agent action needs to be attributable), and deterministic routing (a ticket goes to the right agent, not whichever agent happens to be tagged).
Buzz has the audit trail and the attribution. It doesn't have the data-boundary primitives yet — there's no per-channel PII scope, no agent-level data classification. For a small business with <100 tickets a day, you can build it by hand with a single triage channel, one routing agent, and Zapier webhooks. For anything bigger, wait. The primitive layer isn't there.
15. Huddles as Async Recap
Huddles are Buzz's audio-chat feature — voice channels where humans and agents can join a live conversation. The launch positioning is "Slack huddles, but with agents." In practice, this is where the platform's current limitations are most visible:
Live voice agents work, but with high latency. Each turn goes through the full harness + model round-trip, so replies lag. A live voice chat feels like spinning up a new Claude Code terminal every time someone talks.
The async recap pattern is what's actually useful today: hit Start Transcript, run the huddle, stop the transcript, ask an agent to summarize. The recap is signed, lives in the channel, and is searchable. For standups and retros, this is already a productivity win.
If the goal is real-time voice collaboration with agents, wait. If the goal is converting spoken conversations into searchable, attributed written records, this is already shipping.
16. What Breaks in the First Week (Honest Section)
If you've read this far without skipping ahead to the switch-or-wait verdicts in Sections 19 to 21, you probably want the unfiltered version. Here it is.
Things that shipped broken. The message_posted workflow trigger fires on the agent's own posts — that's a loop risk. Cross-channel SendMessage calls silently reject — a workflow can run for a full day looking successful while doing nothing. The workflow-runs API returns [] for completed runs, so from inside the app, a broken automation looks identical to a working one. New members get added to the community but seated in no channel — issue #3542. New identities can't save a profile before joining a community — issue #3544, hence the "Unnamed member" accounts you may see in screenshots. That last one was the single largest drop-off we measured on launch day. The iOS app's websocket can't hold a connection to a self-hosted relay that has HTTP/3 enabled.
Things that broke because of how I built the agent, not how Buzz shipped. Artie followed a "don't create channels without asking" rule it was never actually bound by — that was a prompt-level manner, not an enforced guardrail. And its roster tool insisted two members were unseated when the database showed three — it was structurally blind to profile-less, channel-less members. Both bugs were mine. Both taught me the same lesson: prompt-level rules aren't guardrails.
The durable lesson, more important than any specific bug: you often can't see what your agents did or didn't do. A message that accepted into the channel isn't the same as a message that succeeded. An agent that didn't respond might be thinking, or might be stuck, or might be silently failing. This is the single biggest operational gap in the platform today, and the reason every Honest Section recommendation in this piece starts with "build narrow, watch closely."
Filed upstream: issues #3542 (members seated in no channel), #3544 (first-run profile-save deadlock), and #3326 (agents can't read the community roster). The pair-relay gap, #2734, was filed by Jason Brashear and is still open — though he's also opened a fix PR, #2736, with multiple self-hosted deployments confirming it works. The connector-isolation PR, #3550, is open with green checks and one external review already addressed, waiting on a Block maintainer. For the full disclosure of what broke on day one and the position I'm holding, see the field report.
If you're running Buzz solo and hit a wall, post in the channel.
One of us has probably hit the same wall. We've got the pair-relay bug, the iOS blank-Home, the cross-channel
SendMessagesilent rejection, the profile-save deadlock. We'll know if your symptom matches one we've already filed upstream. Invite link is in the community resources — come see what an early Buzz community looks like from the inside.
17. Hosted vs Self-Hosted in Practice
If you self-host, three things matter that the docs don't make obvious:
The buzz-pair sidecar doesn't start automatically. If you don't kick it off manually, /pair 404s and onboarding fails for new members. Issue #2734, with Jason Brashear's fix PR waiting at #2736.
The relay doesn't auto-update. run.sh start is idempotent — it doesn't pull new images. If Block ships a security patch, your relay sits behind until you explicitly run docker compose pull && run.sh start.
iOS needs HTTP/2, not HTTP/3. Disable HTTP/3 in your Caddy config or the iOS app shows a blank Home screen. This is the kind of thing you only learn by testing on the device.
If you don't want to run any of this, Block-hosted works. The trade-off is the same as the Slack trade-off: the platform can read your messages.
18. Shared Compute — What's Real, What's Vapor
The "share compute" feature lets you run a local open-source model on your machine and expose it to your community. Other members can @mention your shared agent and have it run on your hardware. Real signal: a Mac Studio M3 Ultra can run meaningful models; smaller machines get useful but smaller ones.
What's vapor for now: the agent-to-agent payment economy. Nostr's Lightning integration is real; the actual product surface to pay for agent work isn't shipping. Don't build your business model on this yet.
What's worth doing today: if you're a community operator with a beefy machine, share it. If you're a member of someone else's community, ask what they're sharing. The economics work at small scale (one operator, ~20 agents) and break at large scale.
19. Should You Switch from Slack?
The decision in one table:
1–10 people, all technical, all running agents
Yes — run it solo first.
1–10 people, mix of technical and non-technical
Hybrid — Slack external, Buzz internal.
11–50 people
Wait — mobile and admin tooling isn't there.
50+ people, enterprise IT
Don't touch it for six months.
Now the reasoning.
Don't switch if: your team includes people who aren't builders — sales, support, ops. Slack is a known good for them. Buzz's onboarding is brutal by comparison, the iOS app is missing features they rely on, and the integration story is Zapier-or-nothing right now.
Do switch if: your team is 1–10 people, all technical, all already running agents somewhere, and you're using Slack mostly as a coordination layer between humans-and-bots that don't talk to each other. Buzz is a strict upgrade for that team — same interface, but agents become first-class.
The hybrid pattern is the right one for almost everyone: keep Slack for external comms (clients, sponsors, anything where the recipient isn't on Buzz yet). Run Buzz for internal product, internal agent work, anything where the recipients are people-and-agents working on the same problems.
20. Should You Switch from GitHub?
No. Here's when yes.
Don't switch if: you have an active open-source project, a public-facing repo, or a team that already has GitHub workflows (PRs, reviews, CI). GitHub is the default for a reason. The Buzz relay's Git hosting is real but it's a young product.
Do switch if: the project is fully agent-owned and short-lived. A scaffold a Claude Code session spins up to test an API integration. A prototype that an agent is iterating on through ten versions before it becomes anything worth committing to GitHub. The relay-hosted repos for these are fine, and the relay's audit trail is nicer than a GitHub commit history for this kind of work.
The rule I'm using: repos stay on GitHub unless the project is fully agent-owned and short-lived. When an agent starts committing to a GitHub repo, the repo's trajectory tilts toward GitHub-stays. When the agent is the only committer, the relay is fine.
21. Who Buzz Is For (And Who Should Wait)
If you already run agents, Buzz is the most native way to give them a shared room. Not the cheapest — self-hosting has real costs, time included — but the cleanest. First-class identities, signed audit trail, harness-swap without context loss. If you've been duct-taping agents into Discord bots and Telegram groups, this is what you actually wanted.
If you don't run agents, Buzz isn't a Slack replacement. It's a different thing. The channel UI is fine. The threads are fine. The huddles are rough. None of that is the reason to come. The agent layer is the reason, and if you're not running agents, that layer is empty. You're paying the operational cost of a new platform for no benefit.
The "should I bother?" answer: if you have a 50-person org, wait. The platform is real, but the operational maturity (mobile, integrations, admin tooling) isn't where enterprise IT needs it. If you're a founder running 1–10 people, all technical, all agent-curious — play solo first, don't migrate the team. Install it on your own machine, build two or three agents, run them for a week. If it sticks, bring one teammate in. If it doesn't, you've lost a weekend.
After seven days of running this thing, five of them with a real community: still the bee's knees. The agent runs as you. The harness is secretly a security setting. The relay is where your data lives, and you should be the one deciding that. Same position I held on day one — same evidence, more conviction. Still here, still excited, eyes open — that's the position I'm holding.
For the inversion case on why Block chose to launch this instead of another SaaS app, the SaaSpocalypse piece. For the full disclosure of what broke on day one and the position I'm holding, the field report. For the Artie story and what we learned the hard way about agent guardrails, the community piece.
If you found this useful, subscribe to Artificially Intimidating — one piece a week on agent infrastructure and the economics of AI-native businesses.
The Artificially Intimidating Buzz community is open for 7 more days. Founding cohort, growing strongly, doors close on Friday August 7, 2026. Join here — one of us has probably hit the same wall you're about to.
References and further reading:
Riley Brown, Building an Agent Team on Buzz — the fastest path from install to a working agent team, and the post that started this one for me; Part 1 is a conversation with Vinny Lingham covering shared compute and the mobile app.
Mike Russell, Buzz setup tutorial — the canonical Day-1 walkthrough; closest to the install path described in Section 4.
Mike Russell, Buzz workflows + Zapier — the signed-emoji-as-approval pattern in Section 12.
Mike Russell, interview with Vinny Lingham (@hot_town) — Vinny's day-in-the-life, the harness-swap strategy, the Wasp-on-Railway pattern.
Greg Isenberg, Startup Ideas Podcast — Vinny Lingham on Buzz — the "who should try Buzz today" answer, the data-sovereignty framing.
Mike Russell, Buzz huddle test — the live-voice-agent limitations in Section 15.
Block, engineering blog — the launch announcement and the architecture overview, by Tyler Longwell.
block/buzz GitHub repo — the source, the issue tracker, PR #3550 and the upstream issues referenced throughout this piece.