The short answer
Nostr is a small protocol for publishing signed messages. Not a company, not an app, not a network you sign up to. Its repository expands the name as Notes and Other Stuff Transmitted by Relays, which is nearly the whole description: you sign a note, hand it to servers called relays, and anybody who wants it fetches it and checks the signature.
The problem it addresses
On a normal platform your handle is a row the company can reassign, your posts sit on their servers, and your followers are a list you cannot take anywhere else. All three belong to one party, so losing the account loses all three at once, whether by policy decision, automated ban or bankruptcy. The account exists nowhere else, so every appeal runs through them.
Nostr splits the three apart: the identity is a key you hold, the posts are signed objects any server may store, and the follow list is itself a signed note that travels with the key.
Identity is a keypair
Your account is a public key. Your login is the matching private key. That is the whole identity system: no username table, no registration, no password.
Both appear in the bech32 forms from
NIP-19, npub1… and nsec1…,
which exist for display only: npub keys "MUST NOT be used in NIP-01 events", which use
raw hex. The construction underneath is the one in
public and private keys.
There is no password reset, and a leaked private key cannot be revoked. On a normal service the server decides who you are, so it can be told to change its mind. Nothing on Nostr decides that: the key is the identity, so whoever holds it is you, permanently, to every relay and every client. The only remedy is to abandon the identity and start a new key, leaving followers and history behind.
It is the same cost you accept holding your own bitcoin, and the reason the key belongs in a signer rather than pasted into an app.
Everything is a signed event
NIP-01 defines a single data
structure. An event is JSON with seven fields: id, pubkey, created_at, kind,
tags, content and sig. The id is a SHA-256 hash of a fixed serialisation of the
others, and sig is a Schnorr signature over that hash on secp256k1 per BIP-340, the
scheme Bitcoin adopted with Taproot. kind is an integer saying what the event is: 0 is
profile metadata, 1 a plain text note, 5 a deletion request, 10002 a relay list.
Relays and clients are strict about the signature and dumb about the content: a relay checks the id and the signature, then stores a string it does not interpret. That is why new kinds of application appear without relay operators changing anything.
Relays
A relay accepts events over a WebSocket, stores some, and returns those matching a client's filters. That is the whole job, far less than a Bitcoin node, and relays agree on nothing.
They owe you nothing. NIP-01 gives them a vocabulary for refusing an event:
blocked, rate-limited, restricted, invalid. Some charge for write access. Publish
to several, and one refusing you or shutting down costs that copy and nothing more: your
identity was never inside it. NIP-65 has clients publish that relay list, and suggests
keeping it to 2 to 4 for reading and the same for writing.
Relays are also the weak point. Reach depends on overlap: somebody who reads none of the relays you write to never sees you, and no global index fixes that. A relay also sees your IP address, which keys you ask about, and when you are online. Hard to silence is not the same as hard to watch.
Clients are interchangeable
A client is the app: it connects to relays, verifies signatures and renders events.
Because identity and data sit outside it, switching is not a migration. Point a new client at your key, it reads the same relays, and your notes and follows are there. That is the point of the design rather than a feature of it: the app becomes a preference, not a lock-in.
Zaps, and readable names
Two things connect Nostr to Bitcoin, and neither is a blockchain. Nostr has no chain and no token.
Zaps are Lightning payments attached to an event, specified in
NIP-57. Your client sends a
signed kind 9734 zap request to the recipient's LNURL-pay callback rather than to relays,
their wallet returns an invoice, and once it is paid their node publishes a kind 9735 zap
receipt that clients count. The specification states its limit: "The zap receipt is not a
proof of payment, all it proves is that some nostr user fetched an invoice."
NIP-05 turns a key into an address like [email protected], resolved by fetching a JSON
file from that domain. The specification
is explicit that it identifies rather than verifies. A domain vouches for a key, which is
not the same as establishing who holds it.
What Nostr does not do
It is not anonymous, it is pseudonymous. Your key is not your legal name, but relays see your IP address and your reading habits.
Public notes are not encrypted. A kind 1 note is a plain string anyone can read. Encrypted direct messages exist separately under NIP-17, which hides participants from relays, and only some clients implement it.
Deletion is a request. NIP-09 defines a kind 5 event asking relays to drop something. Many honour it, but the specification says outright that "it is impossible to delete events from all relays and clients".
Moderation is local. Each relay decides what it stores and each client what it shows. Nobody can remove you everywhere, and nobody can remove anyone else everywhere either.
Where to go next
The next step is a key you control and an app that never sees it, which how to log in to a Nostr app covers.