Is Buzz Secure? Privacy, Encryption, Self-Hosting

Buzz is strong where accountability matters and weak where confidentiality matters: its identity and audit model are cryptographically robust, but message content on the hosted Block relay is not end-to-end encrypted. Every human and every agent holds its own key pair and signs every event, so who did what is verifiable — yet the relay operator sits in the middle of the content, which is exactly why privacy-sensitive teams run their own relay. Both halves are true at once, and treating only one of them as "the answer" is how teams get this wrong.

The direct answer, both halves

Buzz's cryptographic identity and audit model is genuinely strong, and its hosted transport is not confidential from the operator. Those are two different security properties, and Buzz scores very differently on each.

On identity and integrity, Buzz is better than most team chat tools. It is built on the Nostr protocol, so authorship of every event is provable by signature rather than asserted by a server-side session. On confidentiality, Buzz behaves like a conventional hosted service: the relay processes and stores content, and nothing in the public documentation claims end-to-end encryption.

Buzz is open source under Apache-2.0 and written in Rust, with 16,934 stars and 1,591 forks on the block/buzz repository as of 30 July 2026. That openness is the reason you can answer security questions about it at all — you can read the relay code instead of trusting a marketing page.

How Buzz's identity model works

Buzz identity is a cryptographic key pair, not an API token — and that difference is the single strongest security property in the product. Each human and each agent holds its own key pair, and every action is a Nostr event signed with Schnorr signatures.

The README states it plainly: "every message, reaction, workflow step, review approval, and git event is a signed event in one log. Same shape, same identity model, same audit trail, whether the author is a person or a process." Nothing in Buzz gets to be an unattributed side effect.

Agents are not shared service accounts. Per the README, agents get "their own keys, their own channel memberships, and their own audit trail" — they are scoped by cryptographic identity rather than by a permission flag on a bot user. Agent actions also carry a second signature tying the action back to the human owner, so an autonomous step is traceable to the person accountable for it.

Authentication to the relay uses NIP-42, the Nostr client-to-relay authentication spec, alongside rate limiting. The buzz-core crate handles the zero-I/O pieces — NIP-01 filters and Schnorr verification — while buzz-relay serves the Axum WebSocket and REST surface.

The practical upshot: a compromised relay cannot silently forge messages from your users, because it does not hold their signing keys. That is a real, unusual strength and it deserves to be said out loud.

What the hosted Block relay can see

A hosted Buzz relay can see message content, because signing proves authorship without hiding payloads. Signatures and encryption solve different problems, and Buzz's documented cryptography is squarely on the signature side.

The public README documents NIP-42 auth and Schnorr verification. It does not describe end-to-end encryption of channel messages, DMs, canvases or media. Absence of a documented E2EE feature is not proof of malice — it is simply the honest state of the software at v0.5.2, and you should assume content is readable server-side unless and until Block documents otherwise.

According to Block's terms for the hosted service, the operator retains the ability to access content for moderation and legal-compliance purposes. That is a normal trade-off, not a scandal: essentially every hosted communication provider that offers moderation, abuse handling and lawful-process response needs that capability. We are not quoting a specific clause here because we could not verify exact wording at the time of writing — read the current terms on buzz.xyz yourself before putting anything regulated on the hosted relay, and treat this paragraph as a prompt to check rather than a finding.

One structural detail is worth knowing: in the self-hosted deployment that ships today, one relay hosts exactly one community, and the README notes a hosted multi-tenant deployment keeps "that same semantic boundary" — a logical boundary, not a claim about physical isolation. Block is the company behind Buzz, so hosted-relay trust is a question about Block as a provider, not about the Nostr protocol.

Hosted relay vs self-hosted relay

The choice between the hosted Block relay and a self-hosted relay is a choice about who holds the risk, not about which one is "more secure" in the abstract. The table below is accurate as of July 2026 and reflects Buzz v0.5.2.

Self-hosting as the privacy answer

Self-hosting Buzz removes the third-party operator from your message path — and hands you every operational duty that operator was performing. Buzz is explicitly designed for this: the README describes it as "a self-hostable workspace where humans and AI agents share the same rooms," and the project ships a production deployment path rather than treating self-hosting as an afterthought.

For a real relay, use the production Compose bundle in deploy/compose/, not the root docker-compose.yml — that one is development only. The production stack is Docker Compose running buzz-relay with Postgres, Redis and MinIO, plus optional Caddy for TLS. Point clients at your relay by setting BUZZ_RELAY_URL before launch, or switch relays inside the app.

Be clear-eyed about what you took on: TLS renewal, OS and container patching, Postgres backups and restore testing, object-storage access policies, and upgrade discipline across a fast-moving v0.5.x release line. A self-hosted relay that nobody patches is worse than a hosted relay that someone does — the honest comparison is in our commercial vs self-hosted AI agents guide.

On hardware: a small VPS is enough to start, since the relay is Rust and the heavy compute lives in whatever agent runtime you point at it. The one-click Buzz deployment on Hostinger starts at $6.49/mo for KVM 1 and $8.79/mo for the "Most Popular" KVM 2 as of July 2026, with weekly automatic backups and Docker management included — which covers two of the operational duties above. Hostinger links in this post are affiliate/referral links; we earn a commission at no extra cost to you. If you would rather size the box against your own workload first, see our Hostinger VPS plan comparison and deployment options compared.

Agent-specific security risks

The largest realistic security risk in a Buzz workspace is not the relay — it is the agents, because agents execute code and hold credentials. Encrypting a channel does nothing if an agent in that channel has a broadly-scoped API key and a tool that can shell out.

Buzz supports Claude Code, OpenAI Codex, and Goose, an open-source agent harness created at Block and now part of the Agentic AI Foundation. Those runtimes do the work; Buzz is the room they work in. That means your threat model has two independent layers, and hardening the room does not harden the worker.

Least privilege is the whole game here. Give each agent its own credentials rather than sharing a human's, scope tokens to the minimum repositories and services needed, keep secrets out of channel messages that become permanent signed events, and remember that anything an agent posts is in the audit log forever. Our AI agent security risks guide covers the attack classes; the 3-tier hardening approach is a practical containment model you can apply to whichever runtime you attach.

Tool access deserves separate scrutiny. If your agents reach external systems through MCP servers, those servers are credential-holding network clients running next to your workspace — start with MCP security best practices before wiring production systems into a channel. One mitigating design detail: agents only act in a channel when @-mentioned, which limits accidental autonomous activity but is a usability guardrail, not a security control.

When not to use Buzz

Do not put regulated data on the hosted Block relay without a completed legal and security review. That is the single clearest "no" in this article, and it follows directly from the absence of documented end-to-end encryption.

Concretely, skip Buzz — or restrict it to a self-hosted relay with a signed DPA-equivalent process of your own — if you are handling protected health information, payment card data, attorney-client privileged material, or anything under a contractual confidentiality clause you cannot satisfy with "the provider may access content for moderation." Also skip it if your team needs mobile access today, since iOS and Android clients are listed as being wired up rather than shipped, or if you cannot commit someone to patching a v0.5.x self-hosted stack regularly.

Limitations and Tradeoffs

Buzz is early software and its security posture should be expected to change. The latest release is v0.5.2, published 29 July 2026, in a repository created on 6 March 2026 — that is a very young, very active project, and any statement in this article about what is or is not documented has a short shelf life. Re-check the README and release notes before making a decision on it.

Four honest tradeoffs, as of July 2026. First, no documented end-to-end encryption on the hosted relay means confidentiality from the operator is a trust assumption, not a cryptographic guarantee. Second, self-hosting genuinely fixes that but transfers TLS, patching, backup and incident-response risk onto you — many teams are net worse off after that transfer, not better. Third, mobile clients are not shipped, so a self-hosted relay is desktop-first today. Fourth, one relay currently serves one community, so multi-community isolation means multiple deployments.

A scoping note on this article: it is based on Buzz's public repository, README and official site rather than a penetration test or a code audit — we have not performed either, and nothing here should be read as an assurance opinion. Treat it as a map of the documented design and the questions to ask, then verify against primary sources for your own risk decision.

Related Guides

• Commercial vs Self-Hosted AI Agents: The Honest Comparison
• AI Agent Security Risks: A Practical Guide
• OpenClaw Security Hardening: The 3-Tier Approach
• MCP Security Best Practices