Nostr explained: keys, relays, zaps and Blossom

╶── gemlog · 2026-11-12

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.

The Nstart onboarding page. Big letters say "WELCOME TO NOSTR" next to an illustration of an old purple device with a joystick and a cable. The text explains that you create your Nostr profile yourself, with no permissions required, that each user is identified by a cryptographic keypair, "just a strong password that you will have to keep safe", and that the wizard helps you create and manage it. A pink button reads "Let's Start".

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.

An illustrated map titled "This is the NOSTR: Notes and Other Stuff Transmitted by Relays". Little orange octopus-like users holding a private key and a public key live in purple houses labeled CLIENT, and delivery trucks carry stacks of notes along roads to white warehouses labeled RELAY. One bubble shows the inside of a client, where a user writes content, kind, tags, pubkey and created\_at, adds id and sig, and sends it off on a conveyor belt. Another shows the inside of a relay server, where robots store received notes and send them out, under a sign that reads "REQ received! id, filter, kind".

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.

The first frame of the "how nostr works" animation, drawn in a handwritten style. The title says "Penelope starts using Nostr". A green circle labeled Penelope sits on the left, and to its right is a column of five colored boxes, each one a relay: nostr.wine, relay.nostr.bg, nos.lol, relay.damus.io and offchain.pub. A play button sits at the top.

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.

how-nostr-works.pages.dev

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.

guide to WebFinger

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 Blossom Servers directory, with a pink flower logo and the heading "Find a Blossom server: discover, review and check the status of public Blossom media servers". Counters show 3 servers with reports, 30 known servers and 26 reviews. Below are cards for servers such as nostrcheck.me, nostr.download, blossom.primal.net, nosto.re, blossom.ditto.pub and blossom.nostr.hu, each with a response time, star ratings, tags like Uploads, Mirroring, Auth required and Free uploads, and an "Add to my list" button.

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).

blossomservers.com

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.

The Damus website on a dark background. The headline reads "The social network you control", followed by "Your very own social network for your friends or business. Available Now on iOS, Android, and Desktop" and a button to download Notedeck for desktop. On the right, three phones lean against each other showing the Damus app with a feed of notes, lightning zap counts and a "Welcome to Damus" screen. A small pink ostrich icon sits next to a link about Damus Purple.

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.

Nstart

──╴ end of transmission

Gemlog

Home