Relays and communities
A relay is the server that holds a Buzz workspace: it stores every signed event, enforces who can read what, indexes search, and hosts media and repositories. A community is the workspace that relay serves — one URL, one isolated world with its own channels, members, profiles, direct messages and search.
The relay URL is the workspace address. There is no directory to browse and no way to discover a community you have not been given the address for.
Why it matters to you
This is where the "decentralised" framing around Buzz needs care. The protocol underneath is open and multi-relay by design, but a Buzz workspace has exactly one relay. That relay is a conventional server with a database, and whoever operates it holds the data and controls access to it.
For professional work that fact is the hinge on which several other decisions turn: data residency, backup, availability, and what may be said in the workspace at all.
How to apply it
Establish early who operates the relay your workspace runs on — Block, you, or a third party — and treat that as a supplier relationship with the questions that implies.
Match the relay to the sensitivity of what will be discussed. Client and health-sector material belongs on a self-hosted relay; hosted relays are for non-sensitive work.
Ask specifically about backup and whether a restore has been tested, and record the answer in the project's risk documentation rather than carrying it in your head.
Remember that one identity can belong to several communities, so isolating clients or projects into separate communities is a workable pattern that costs the members nothing.
If you ignore this
If the relay is unavailable, nothing reads or writes — there is no offline mode and no local cache. If it is lost permanently, so is the workspace, unless someone has been keeping an export.
If the relay is operated by a party that should not hold the material, the exposure exists from the first message, not from the moment anyone notices.
Examples
The relay is the building. The community is your office inside it. You can furnish the office however you like; the landlord still has keys, and if the building closes, you are not working today.
You join a client community and your own team's community with the same key. The two are entirely separate worlds — separate channels, separate search, no leakage between them — and they may sit on different relays with different operators.
Assuming that because Nostr is an open protocol, a Buzz workspace is distributed across many relays and therefore resilient. It is not; that is a property of the protocol, not of a Buzz community.
Verified against Buzz v0.5.20 · Updated 2 Sep 2026