Keys replace accounts
Your identity in Buzz is a cryptographic keypair rather than an account on someone's server. The public key — written as an npub — is your address: people mention you by it, and it identifies everything you have done. The private key — an nsec — signs your actions and never leaves your control. A readable handle in the form name@domain can be bound to the npub so people do not have to deal with the raw key.
There is no password because there is no account. Nobody issued your identity and nobody can reissue it.
Why it matters to you
This single design choice produces most of what is distinctive about Buzz. It is why your identity is portable across communities, why agent actions are attributable, why the audit trail cannot be quietly rewritten, and why nobody can lock you out of your own history.
It is also why there is no recovery. Every other workplace tool has an organisation that can restore access to a person who has lost it. Here, no such party exists — not as a policy choice, but because no one ever held a copy.
How to apply it
Treat the key as the credential it is. The app can make an encrypted backup for you — Settings → private key → Create backup — with a generated passphrase and a flow that tests the backup actually restores you. Do that before anything else, store the file and the passphrase in different places, and never paste the key anywhere, including a Buzz channel or a message asking for help.
Expect to explain this to everyone you bring into a workspace. It takes one sentence and no official document contains that sentence, so write yours and reuse it.
When bringing a colleague or external stakeholder into a workspace, do the key conversation before their first message rather than after their first laptop replacement.
Watch item: federated identity (NIP-FI)
A draft relay extension published alongside v0.5.19 would let an organisation's identity provider — corporate SSO — bind its identities to Nostr keys, with the relay authorising an operation only when the provider's assertion, fresh proof of the key, the current binding and local policy all agree. The provider never signs events and an assertion never replaces the key. Nothing to set up yet: it is a specification, not a feature. It is the answer to "can this work with our SSO?" that a client's IT department will ask, so know it exists and that it is optional and unshipped. Last checked: Buzz v0.5.20, 2026-09-02.
If you ignore this
If the key is lost, that identity ends. Channel memberships, the signature on everything approved, and the agents that inherit access from it are all bound to a key only the holder has.
If the key is compromised, someone else can act as you indistinguishably — and because every event is signed, their actions look exactly as legitimate as yours.
Both failures are quiet until they are not, and neither has a recovery path. This makes key custody the highest-consequence, lowest-effort precaution in the entire toolset.
Examples
A personal wax seal rather than a login. Anyone can verify a document sealed with it; only you have the seal; and if you lose it, no one can make you another that means the same thing.
The same npub works in your own team's community and in a client community. Your display name and avatar differ between them; the identity behind both is one key.
Treating the key like a password you can reset "if something goes wrong". There is no reset — that mental model is what produces the loss.
Verified against Buzz v0.5.20 · Updated 2 Sep 2026