Nostr stands for "Notes and Other Stuff Transmitted by Relays." It was proposed around 2020 by a pseudonymous developer known as fiatjaf, and it drew wider attention in 2022 and 2023 as a censorship-resistant alternative to centralized social platforms. The whole protocol fits in a short specification. That minimalism is the point: Nostr tries to do as little as possible at the protocol layer and push everything else to clients.
The result is a system with genuinely interesting censorship-resistance properties and some honestly weak spots — particularly around private messaging and key management. Both deserve a clear look.
Your Public Key Is Your Account
In Nostr there is no username and password, and no signup server. You generate a key pair on the secp256k1 elliptic curve — the same curve Bitcoin uses. The public key is your identity. It's usually shown in a human-friendlier encoded form prefixed with npub, and the matching private key as nsec.
Every message you publish — Nostr calls them events — is signed with your private key. Anyone who has your public key can verify the signature, which means anyone can confirm a note genuinely came from you, without trusting the relay that delivered it. This is the foundation the whole network rests on: relays cannot forge posts in your name, because they never hold your signing key.
Because your account is a private key with no server-side recovery, losing the key means losing the identity permanently, and a leaked key means an attacker can impersonate you forever. There is no "reset password" link. This is the same uncompromising trade-off that key-based trust models always carry: total control, total responsibility.
Relays: Deliberately Unintelligent
A relay is a simple server that accepts signed events, stores them, and serves them to clients that subscribe with filters ("give me notes from these public keys" or "give me events of this kind"). That's nearly all a relay does. It runs over plain WebSockets and holds no special authority.
Crucially, you publish to many relays at once, and you read from many. If one relay blocks you, deletes your notes, or goes offline, your clients simply use the others. There is no single operator who can erase you from the network, because there is no single operator at all. To be silenced you'd have to be dropped by every relay your audience reads from — a much harder bar than deplatforming on a centralized service.
This is also Nostr's weakness as a guarantee: a relay can refuse you, and popular relays do moderate. Censorship resistance here is statistical and social, not absolute. It works because there are many relays and they don't coordinate — not because any single relay promises to carry everything.
Events, Kinds, and NIPs
Every event is a small JSON object with a kind number, a timestamp, the author's public key, optional tags, content, and a signature. The kind number determines what the event means: kind 0 is profile metadata, kind 1 is a short text note, and so on. Tags link events to other events and keys, which is how replies, mentions, and threads are built.
The protocol evolves through NIPs — Nostr Implementation Possibilities — which are the specification documents that define new event kinds and client behaviors. Anyone can propose one. A client only needs to implement the NIPs relevant to the features it offers. This keeps the core tiny while letting the ecosystem grow features at the edges.
The Direct-Message Problem
Here is where honesty matters most. Nostr's original private messaging scheme, defined in NIP-04, encrypted the message content but left the metadata wide open. Because every event carries the author's public key and a recipient tag in the clear, anyone watching a relay could see exactly which two keys were talking, how often, and when. The conversation contents were hidden; the social graph was not.
That is a serious leak. Metadata is frequently more revealing than content — who you talk to and when often tells the story on its own. NIP-04 also used an encryption construction that drew criticism for being underspecified compared to modern authenticated schemes.
Newer NIPs address this. NIP-44 defines a versioned encryption payload using ChaCha20 with a keyed MAC, replacing NIP-04's weaker scheme. And a "gift wrap" approach (NIP-59) hides the sender and wraps the real message inside an outer event so the metadata visible to relays no longer reveals who is talking to whom. The direction is right — but it's a bolt-on retrofit, and support varies across clients. If you use Nostr DMs, check which scheme your client actually uses.
A protocol that signs everything in public is excellent for verifiable broadcast and awkward for private conversation. Those are different problems, and Nostr was clearly designed for the first. — A fair summary of the design tension
What Nostr Is Good At — and What It Isn't
| Property | Nostr's answer |
|---|---|
| Censorship resistance | Strong. No single server can erase you; clients fan out across many relays. |
| Account portability | Strong. Your key works on any client and any relay. No lock-in. |
| Post authenticity | Strong. Every event is signed; relays can't forge you. |
| Private messaging | Improving but cautious. Early DMs leaked metadata; newer NIPs fix encryption and sender-hiding, with uneven client support. |
| Key recovery | None by design. Lose the key, lose the identity. Protect it like a crypto wallet seed. |
The honest framing is that Nostr is a strong protocol for public, verifiable, censorship-resistant broadcast — social posting, public notes, identity you genuinely own. It is a weaker foundation for confidential one-to-one and group conversation, where metadata protection and seamless key recovery matter more than open broadcast, and where purpose-built protocols have a head start.
Where Haven Sits in This Picture
Haven isn't built on Nostr, and the contrast is instructive. For private messaging we use the MLS protocol (RFC 9420), which was designed from the ground up for confidential group conversation with forward secrecy and sound membership changes — the exact problem Nostr's broadcast-first model handles least naturally. For account recovery, we use a recovery seed phrase so you keep self-custody of your keys without the "one mistake and it's gone forever" cliff that raw key management imposes.
Nostr is worth understanding because it shows, in the cleanest possible form, what it looks like to put cryptographic identity in the user's hands and reduce servers to dumb pipes. That idea is powerful. The lesson for anyone evaluating tools is the same as always: match the protocol's actual strengths to your actual threat model, and read past the slogans to what the encryption really covers.