What is Nostr? The decentralized protocol explained

If you've spent any time in privacy circles lately, you've probably heard the word Nostr. It gets thrown around next to terms like decentralization, censorship resistance, and self-sovereign identity — which sounds impressive, but also raises a simple question: what actually is Nostr?

The short version: Nostr (short for "Notes and Other Stuff Transmitted by Relays") is an open, decentralized protocol for publishing and exchanging messages. No central authority, no company in the middle, no account that can be deactivated. Just cryptographic keys and a network of relays that anyone can run.

The slightly longer version — including how Nostr differs from other technologies, where its strengths and weaknesses lie, and which NIPs matter for security — is what this post is about. And because abstract protocols are best understood through real examples, we'll also look at Murmelt, a web client that puts the Nostr philosophy into practice.

What is Nostr?

At its core, Nostr is refreshingly simple. It's not a Blockchain, not a platform, and not an app. It's a protocol — a set of rules for how messages (called events) are created, signed, and shared.

The whole system rests on three building blocks:

Key pairs instead of accounts. Your identity on Nostr is a cryptographic key pair generated on your device. The public key (your npub) is your address — it's how others find and verify you. The private key is your password, your signature, and your identity in one. There's no email, no phone number, no sign-up form. You are your key.
Events instead of posts. Everything on Nostr is an event — a note, a reaction, a chat message, a profile update. Every event is signed with your private key before it leaves your device. Anyone can verify that an event really came from you, but nobody can forge one.
Relays instead of servers. Events are sent to relays — simple servers that store and forward events. Here's the crucial part: relays are dumb, interchangeable, and replaceable. Anyone can run one, clients can use several at once, and switching relays doesn't change your identity. Your keys go with you, not with the platform.

Put together, this creates a communication network where no single entity holds power. A relay can refuse to store your events — but your followers run their own relays or simply use other ones. A company can shut down its client — but other clients can read the same events, because the protocol is open.

How Nostr differs from other technologies

The easiest way to understand Nostr is to compare it with the alternatives it's often measured against.

Nostr vs. centralized platforms

On Twitter/X, WhatsApp, or Discord, one company operates everything: the user database, the message store, the moderation, the infrastructure. If your account gets banned, your entire social presence vanishes. If the company changes its policies, you have no say. And your data — messages, contacts, metadata — lives on their servers.

Nostr inverts every one of these points. Your identity is mathematically yours, your data lives wherever you (or your relays) decide, and no company can delete "your account" because there is no account to delete.

Nostr vs. ActivityPub (Mastodon)

Mastodon and the wider Fediverse use the ActivityPub protocol — and while they're decentralized in spirit, there's a catch: your identity is bound to a server. You're not @alice — you're @alice@mastodon.social. Your home instance stores your profile, your followers, your history. If that instance shuts down or blocks you, you lose your digital self. Moving between instances is possible, but cumbersome.

With Nostr, your identity exists independently of any server. Relays only ever see your events; they never own them. You can switch relays on every message if you want. Server and identity are cleanly separated by design, not loosely coupled by federation agreements.

Nostr vs. Blockchain

Nostr is often confused with Blockchain projects, but the differences are fundamental:

No global state. A Blockchain maintains one shared ledger that everyone must agree on. Nostr doesn't have a ledger at all — relays just store and forward events.
No mining, no fees. Publishing on Nostr is free and instant. There's no consensus mechanism because there's nothing to reach consensus about.
No incentive for spam resistance through cost. This is a double-edged sword, which we'll get to in the limitations.

In short: a Blockchain is a shared database with expensive agreement; Nostr is a messaging protocol with no agreement needed at all. That simplicity is its strength.

Advantages of Nostr

So what do you actually gain from this architecture? Quite a lot:

Censorship resistance. Since events are signed by keys and distributed across many relays, there's no single lever to pull to silence someone. Blocking Nostr means blocking an open protocol — which is as practical as blocking HTTPS.
Identity without registration. No email, no phone number, no personal data at sign-up — because there is no sign-up. This makes Nostr-friendly apps anonymous by default, not by policy.
Verifiable authenticity. Every event carries a cryptographic signature. Impersonation isn't just against the rules — it's mathematically infeasible.
Portability. Your identity, your contacts, and your history travel with your key. No vendor lock-in, ever.
Simplicity. The core protocol is small enough that a basic client can be built in a weekend. This low barrier keeps the ecosystem diverse and innovative.
Resilience. With thousands of independent relays, there's no single point of failure. Clients can fetch the same event from multiple sources and verify the signature each time.

Limitations of Nostr

Honesty time — Nostr is not a magic privacy solution, and it comes with real trade-offs:

Public events are public. Regular Nostr events (like notes) are signed but not encrypted. Anyone operating a relay can read them, index them, and profile them. Anonymity on the identity level doesn't mean confidentiality on the content level — unless you use encrypted messaging extensions (more on NIP-17 below).
Your private key is your everything. Lose it, and your identity is gone forever. Leak it, and someone else is you. Key management is the Achilles heel of every self-sovereign system, and it pushes responsibility onto users who may not be prepared for it.
Relays are the weak point for availability. No central authority also means no service guarantee. If your relays go offline or block you, you need alternatives — and finding good, reliable relays is an ongoing chore.
Spam and moderation are unsolved at the protocol level. Because publishing is free and anonymous, spam is cheap. Countermeasures exist (proof-of-work, paid relays, client-side filtering, web-of-trust), but none is standardized and enforced everywhere.
Metadata is hard to hide. Even encrypted events reveal that you're communicating, when, over which relays, and with whom. Perfect metadata protection is an open research problem in all of decentralized messaging.
Ecosystem fragmentation. NIPs are optional. Not every client implements every NIP, which can lead to confusing experiences where some features work in one app and silently fail in another.

None of these limitations is fatal — but they explain why thoughtful clients put so much emphasis on security standards and sensible defaults.

The most important NIPs for security

Nostr itself is deliberately minimal. Everything beyond the base protocol is defined in NIPs — Nostr Implementation Possibilities. These numbered proposals specify how clients and relays should implement features like encryption, authentication, and key handling. Not every NIP is security-relevant, but these are the ones that matter most for your safety:

NIP-01 — Basic protocol. The foundation: event format, signature verification, and the client-to-relay communication model. Everything else builds on this. If signature handling is broken here, nothing above it is trustworthy.
NIP-04 — Encrypted Direct Messages (deprecated). The original scheme for private messages: a shared secret derived from both key pairs, used to encrypt events of kind 4. It works, but it leaks metadata (the recipient is named in the event) and lacks forward secrecy. New implementations should avoid it — which is why it's marked deprecated.
NIP-17 — Private Direct Messages. The modern replacement. NIP-17 defines end-to-end encrypted private messaging with proper conversation metadata wrapped inside the encryption, so relays can't even see who you're talking to. Messages are encrypted on your device before they ever leave, and relays only ever see ciphertext. For any Nostr-based chat app, NIP-17 is the gold standard today.
NIP-44 — Improved message encryption. A modern encryption scheme for Nostr that replaces older constructions with stronger, versioned encryption (ChaCha20 with HMAC-based padding). It defines how to encrypt content securely, while NIP-17 defines how private messaging uses it. Together they form the current security backbone of Nostr messaging.
NIP-06 — Key derivation. Losing a private key is the worst-case scenario in Nostr. NIP-06 defines how to derive a Nostr key from a BIP-39 mnemonic seed phrase — the same recovery-phrase approach known from crypto wallets. Write twelve words on paper, restore your identity on any device.
NIP-07 — Browser extension signing. Entering your private key into a web client is risky — a malicious website could steal it. NIP-07 solves this by delegating key operations to a browser extension, so websites can ask for signatures without ever seeing your key. If you use Nostr on the web, a NIP-07-compatible extension is strongly recommended.
NIP-05 — Verified identifiers. This one binds your Nostr key to a human-readable identifier (like alice@domain.com) by publishing a verification file on a domain you control. It's about identity verification, not encryption — but it matters for security, because it's the main defense against impersonation and typo-squatting attacks on public figures.

The pattern across all of these: security in Nostr is layered on top of a minimal, verifiable core. Signature verification (NIP-01) guarantees authenticity. Encrypted messaging (NIP-17 with NIP-44) guarantees confidentiality. Key management (NIP-06, NIP-07) guarantees that your identity stays in your hands. Verification (NIP-05) guards the fragile link between keys and names.

Nostr and anonymity: what's real, what's not

Let's be precise, because "anonymity" is often used loosely when talking about Nostr:

What you get: No registration means no link between your identity and your real name, email, or phone number. You can generate a fresh key pair in seconds and use it for exactly one purpose. You can run clients over Tor. Your public key reveals nothing about who you are. This is pseudonymity by default — and it's a far stronger starting position than any sign-up flow.

What you don't automatically get: Confidentiality. A public Nostr note is signed plaintext, readable and indexable by every relay it passes through. Even with encrypted messaging, metadata — timing, relay usage, IP addresses of clients connecting — may still be visible to relay operators. True end-to-end anonymity requires encryption (NIP-17), careful relay choices, and network-level protection like Tor.

The honest summary: Nostr takes the identity problem out of the hands of companies, but content privacy depends on how the client implements the protocol. Which brings us to a concrete example.

A real Nostr client: Murmelt

Protocols live through their implementations, and one of the more interesting Nostr web clients right now is Murmelt — a free anonymous chat that puts the principles above into a polished product.

What makes Murmelt a good illustration of Nostr's philosophy is how strictly it follows the protocol's core ideas:

Your identity is a key on your device. No email, no phone number, no sign-up — you generate a key pair locally and that's your entire profile. Your private key never leaves your device, so nobody can impersonate you.
Messages are end-to-end encrypted with NIP-17. Encryption happens on your device before anything is sent. Relays — the servers that route and store messages — only ever see ciphertext. File transfers are sealed with AES-GCM before upload.
You pick the relays. Murmelt connects to Nostr relays of your choosing. You can switch relays anytime, and your identity travels with your key, not with a platform. No central backend ever holds your contact list or your messages.
No accounts to ban, no database to breach. There's nothing to sign up for and nothing central to subpoena. When you delete your local data, the conversation is gone from your side — no history to mine.

Beyond pure messaging, Murmelt also shows a direction that centralized apps could never take safely: a random chat roulette that matches you with a stranger — free, anonymous, and end-to-end encrypted. Meeting someone new with cryptographic guarantees instead of a platform's privacy policy is a genuinely new combination, and it only works because Nostr provides the identity and encryption layer underneath.

Murmelt won't be the right tool for everyone — the same key-management responsibility that Nostr demands applies here too. But as a demonstration of what "privacy by design, not by promise" looks like in practice, it's one of the cleanest examples around.

Conclusion

Nostr is one of those rare protocols that takes a radical idea — communication without central control — and reduces it to something small enough to actually work. Keys instead of accounts. Signatures instead of verification departments. Relays instead of servers. The result is a network that is censorship-resistant by architecture, anonymous by default, and simple enough that a single developer can build a client on a weekend.

The limitations are real: public events are plaintext, key management is hard, spam and metadata remain unsolved protocol-level problems. That's why the security-relevant NIPs — NIP-17 and NIP-44 for encryption, NIP-06 and NIP-07 for key handling, NIP-05 for verification — matter so much. They are the difference between a protocol with anonymous potential and a client with actual privacy guarantees.

For anyone who values communication that can't be switched off, deplatformed, or data-mined, Nostr is worth watching — and thanks to clients like Murmelt, it's now as easy to try as opening a website and generating a key.