Nostr explained: keys, relays, zaps and Blossom

Nostr is a protocol for social networks that has no company in the middle and no server you have to trust. You are a pair of cryptographic keys, your posts are small signed JSON messages, and those messages travel through simple servers called relays, which anyone can run. The core of it fits in a few pages.

Here's where it came from, how keys, events and relays work, what Blossom is, and a few odd stories from along the way.

Where it came from #

The name is an acronym: Notes and Other Stuff Transmitted by Relays. It was created by a Brazilian developer who goes by fiatjaf. The first commits in the original repository are from November 7, 2020, with a "basic server relay code" and, two days later, "a readme explaining the idea." That README still opens with the same promise:

The simplest open protocol that is able to create a censorship-resistant global "social" network once and for all.

And right below it, the three arguments in one sentence: it doesn't rely on a trusted central server, so it's resilient; it's based on keys and signatures, so it's tamperproof; and it doesn't rely on peer-to-peer techniques, "and therefore it works." That last bit is a jab at peer-to-peer designs. fiatjaf wrote Nostr partly out of disagreement with how ActivityPub and Secure Scuttlebutt were designed.

For two years it was a small thing, followed mostly by Bitcoin developers. Then, in December 2022, Jack Dorsey, the Twitter co-founder, sent 14.17171699 bitcoin to the project, close to $250,000 at the time, to be split between fiatjaf and jb55, the developer behind Damus. A few weeks later, on February 1, 2023, Damus went live on Apple's App Store as the first Nostr app there. Two days after that it was removed from the App Store in China, following an order from the country's internet regulator.

The fight with Apple came a few months later, and it was over zaps, which we'll get to. Apple told Damus that sending bitcoin tips on posts looked like a way to pay for digital content outside in-app purchases, and threatened to remove the app. Damus stayed in the store by removing zaps on individual notes.

In 2025 Dorsey went further and put $10 million into and Other Stuff, a nonprofit collective of developers building open social tools, with Nostr at the center.

You are a pair of keys #

On Nostr there's no username and password stored in somebody's database. Your identity is a keypair on the secp256k1 curve, the same one Bitcoin uses, with Schnorr signatures. The public key is your address, and the private key is what proves a post is yours.

You'll usually see them in a friendlier format that starts with a prefix: npub1... for the public key, which you can share with anyone, and nsec1... for the private key, which you never share. Under the hood they're the same 32-byte numbers, written in bech32 so humans can tell them apart and copy them without mistakes.

This is the part people trip over. There's no "forgot my password" button, because there's no one to press it for you. If you lose your nsec, that identity is gone. If someone steals it, they are you, and there's no support team to call. That's why more and more apps avoid asking for the nsec directly. A browser extension can hold the key and sign for the websites you use (that's NIP-07, which adds a window.nostr object to the page), and a remote signer, often called a bunker, can keep the key on another device and only send back signatures (NIP-46).

The welcome page above is Nstart, a small open source wizard that creates a keypair, helps you back it up and gives you a bunker address to log into apps. It's one of the easiest ways in.

Everything is an event #

Nostr has exactly one type of object, the event. A post, a like, a profile, your follow list, a private message, a long article: all of them are events with the same shape.

{
"id": "sha256 of the serialized event",
"pubkey": "the author's public key",
"created_at": 1794506400,
"kind": 1,
"tags": [["p", "someone else's pubkey"], ["e", "the id of the note I'm replying to"]],
"content": "hello, nostr",
"sig": "Schnorr signature of the id"
}

The id is a hash of the whole event, and sig is the author's signature over that hash. That's what makes the network tamperproof: a relay can refuse to store your post, but it can't change a single letter of it without breaking the signature, and every client checks.

What changes from one event to another is the kind, a number that says what the event is. A few of the common ones:

• kind 0: profile (name, picture, bio)
• kind 1: short text note, the "tweet"
• kind 3: follow list
• kind 7: reaction (the like)
• kind 9735: zap receipt
• kind 10002: the list of relays you use
• kind 30023: long-form article

Every new feature is written down as a NIP, short for Nostr Implementation Possibilities. They're numbered documents in a public repository, and NIP-01 describes the basic protocol. Anyone can propose a new one, and clients pick which ones they support.

Relays #

A relay is a server that receives events, stores them and sends them to whoever asks. Clients talk to relays over a WebSocket, and the conversation is a handful of JSON arrays. The client publishes with EVENT, asks for things with REQ and a filter (by author, by kind, by date), and stops a subscription with CLOSE. The relay answers with the matching events, an EOSE to say "that's everything I had stored, from now on it's live", and an OK to say whether it accepted what you sent.

The drawing above is in the original Nostr repository and shows the whole idea: users with their keys, clients writing and signing, trucks of notes going to relays, and relays sending data back according to each request.

Relays are deliberately dumb. They don't talk to each other, and there's no federation between them like there is between Mastodon servers. Your client simply publishes to several relays at once and reads from several at once. If one relay bans you, deletes your posts or disappears, your posts are still on the others, and your followers can still find you, because they follow your key, not your server.

Each relay sets its own rules. Some are free and open, some charge a small fee to write, some only accept members of a community, and some ask for proof of work, a bit of computation per post that makes spam expensive. The rejections come back as readable messages, and the examples in NIP-01 have a sense of humor. One of them is ["OK", "b1a649ebe8...", false, "rate-limited: slow down there chief", "1000"].

Running your own relay is very doable on a small VPS. strfry, written in C++, is one of the most used, and khatru is a framework in Go, by fiatjaf himself, for writing relays with custom rules.

Finding people: the outbox model #

If anyone can write to any relay, how does my client know where your posts are? This was the hardest problem in the protocol, and the current answer is called the outbox model. Each user publishes a kind 10002 event (NIP-65) listing the relays where they write and the relays where they read mentions. When you follow someone, your client fetches that list and goes to read their posts where they actually publish them, instead of hoping everyone is on the same big relay.

There's a lovely animated explanation of this at how-nostr-works.pages.dev, where Penelope starts using Nostr and you watch her notes go out to five relays and her followers find them. It's worth pressing play.

A readable name: NIP-05 #

Nobody wants to tell a friend to follow npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6. NIP-05 solves that with something that looks like an email address. You put you@yourdomain.com in your profile, and on your site you serve a small file at https://yourdomain.com/.well-known/nostr.json?name=you that maps that name to your public key. The client fetches it, checks that the key matches, and shows your name with a checkmark.

If you read my guide to WebFinger, this will feel familiar: same idea, a JSON file under .well-known that turns a human address into something a machine can use. The difference is that on Nostr the domain doesn't own your account. It only vouches for a name. If the domain goes away, you lose the pretty name, but your key, your posts and your followers stay with you.

Zaps #

Zaps are Bitcoin tips sent over the Lightning Network, and they're the most visible thing that makes Nostr feel different. You tap the lightning bolt on a post, pay a few satoshis, and the recipient's wallet publishes a receipt (kind 9735) that clients show as a count under the post. NIP-57 describes the whole dance between the client, the zap request (kind 9734) and the recipient's Lightning server. Zaps are a big part of why so much of the early community came from Bitcoin, and also the reason Apple got involved, as told above.

Blossom: where the pictures live #

Relays are good at small JSON events and bad at big files. A photo or a video doesn't fit in an event, so for years clients uploaded media to some image host and put the link in the post. If that host went down, the picture went with it.

Blossom is the answer to that. The repository describes it as "Blobs stored simply on mediaservers": a small set of HTTP endpoints for servers that store files, where every file is named by its SHA-256 hash. The hash is the address. If you know the hash, you can ask any Blossom server for the file at GET /<sha256>, and when it arrives you can hash it yourself and know it's exactly the file that was posted.

The rest follows from that:

• PUT /upload sends a file, authorized by a signed Nostr event (kind 24242) instead of an account and password
• DELETE /<sha256> removes it
• PUT /mirror asks a server to copy a file from another server
• PUT /media asks the server to optimize an image or video before storing it

Each user publishes a kind 10063 event with the list of Blossom servers they use. NIP-B7 adds a nice fallback on top of that. When a client finds a media link in a post that ends in a 64-character hex string and that link is dead, it can assume the string is a SHA-256, look up the author's server list and try the same hash on the other servers. A picture survives its first host, the same way a post survives its first relay.

The specs are called BUDs (Blossom Upgrade Documents), there are thirteen so far, numbered 00 to 12, and you can browse public servers at blossomservers.com. And since files are just hashes, someone had the obvious next idea: nsites, static websites whose files live on Blossom servers and whose map of paths to hashes is a signed Nostr event (NIP-5A).

Apps #

Since the protocol is open, there's no "Nostr app". There are dozens of clients, mostly free and open source, and you can log into all of them with the same key and see the same follows and posts.

Damus is the classic on iOS, Amethyst is the big one on Android, Primal works on the web and on phones, and Coracle is a web client. And Nostr shows up in less obvious places too. Bitchat, the Bluetooth mesh messenger Dorsey released in 2025, works offline between nearby phones, but its location channels, chat rooms for a neighborhood or a city, run over Nostr relays.

A few curiosities #

• People on Nostr call themselves nostriches, a pun on ostrich, and a purple ostrich became the unofficial mascot. There's a little pink one on the Damus site above.
• Edward Snowden is on Nostr and has been one of its best-known supporters.
• There's a nostr: URI scheme (NIP-21), so a link like nostr:npub1... can open in whatever client you use, the same way mailto: opens your email.
• Mostr is a bridge between Nostr and the fediverse, running since 2023. Since July 2026 Nostr users can claim a name on it, and a name like you@mostr.pub works both as a NIP-05 identifier and as an ActivityPub handle that Mastodon users can follow.
• Bridges have a downside. In 2024, a wave of spam posted on Nostr was bridged to the fediverse and then again to Bluesky.

The rough edges #

Owning your key means carrying all the responsibility for it. Creating an account costs nothing, which is freedom and also spam, so filtering falls on relays and clients, and the experience changes a lot depending on which ones you use. Finding posts across many relays is still harder than on a centralized network, even with the outbox model. And since anything you publish is signed and copied to several servers, deleting a post is only a request: well-behaved relays honor it, but there's no guarantee all of them will.

Trying it #

The quickest path: create your keys at Nstart, save the backup somewhere safe, pick a client for your phone or browser, and follow a few people. If you have a domain, set up a NIP-05 name. Later, if you get curious, run a relay or a Blossom server of your own. The README of the original repository says the protocol spec is "very small", and it's true: NIP-01 is a pleasant evening of reading.