Glossary

Its address is kind:pubkey:d-tag; the newest event for that address wins. Articles (30023), lists and calendar events use it. Older docs call these parameterized replaceable events.

Other events point to one with an a tag, and it is shared as an naddr.

Bech32 (BIP-173) uses a 32-character alphabet that avoids look-alike characters such as 1, b, i and o, and a checksum that catches typos. The part before the 1 (the human-readable part) says what is inside.

NIP-19 uses plain bech32 (not bech32m) and allows strings longer than Bitcoin's 90-character limit so TLV entities like nevent fit.

You connect an app with a bunker:// URI containing the signer's pubkey, relays and an optional secret. Every signing request travels as an encrypted event, and the bunker can enforce permissions.

Nostr gets it from self-owned keys and many independent relays: any relay may refuse your events, but none can stop you publishing elsewhere or forge your words. It is resistance, not immunity; reach still depends on relays and clients carrying your content.

A client holds or talks to your signer, connects to relays, sends subscriptions and renders the events it receives. All the smarts live here: choosing relays, building timelines, verifying signatures, counting reactions.

Because your identity is just a keypair and your data is on relays, you can switch clients at any time and take your followers and posts with you.

It references events with e tags (or a tags for addressable events). Well-behaved relays stop serving them, but copies may persist on relays that ignore the request or on anyone's disk: on a public network nothing is truly deleted.

With NIP-17, relays see only gift wraps addressed to the recipients, not who sent them or what they say. Remember that a leaked private key exposes all past messages: there is no forward secrecy.

Alice computes privA × pubB and Bob computes privB × pubA; both arrive at the same point, and its x coordinate becomes the shared secret. NIP-04 uses it directly as an AES key; NIP-44 feeds it through HKDF.

Nostr encrypts only content; the event envelope (pubkey, kind, tags, timestamp) stays public unless you hide it with gift wraps. NIP-44 is the current scheme; NIP-04 is deprecated.

Sent as ["EOSE", <subscription id>]. Clients use it to stop a loading spinner or to close one-shot queries. It does not end the subscription.

Used for things that only matter right now, such as typing indicators, signer requests (kind 24133) and relay authentication (kind 22242).

Posts, profiles, reactions, follow lists, zap receipts and messages are all events. The kind number says what an event means; tags add structured references; content holds the text.

The id is the SHA-256 hash of a canonical serialization, [0, pubkey, created_at, kind, tags, content], and sig is a Schnorr signature of that id by the author's private key. Change a single byte and verification fails.

Serialize [0, pubkey, created_at, kind, tags, content] as compact JSON, encode it as UTF-8, hash it with SHA-256: that is the id. Relays and clients recompute it to detect tampering, and the signature is made over it.

In a federated network your identity (alice@server) and data live on your home server, so if the admin bans you or shuts down, you lose them. In Nostr your identity is a key and relays are interchangeable: they do not need to know about each other.

Within one filter every field must match (AND); within one field any value may match (OR). A REQ can carry several filters, and an event matches if it matches any of them. Example: {"kinds": [1], "authors": [<pubkey>], "limit": 20}.

limit only applies to the initial batch of stored events, which relays return newest first. NIP-50 adds an optional search field for relays that support full-text search.

Because it is replaceable, a client must always publish the full list; publishing a stale copy accidentally unfollows people. Each p tag may carry a relay hint and a petname.

Follow lists of everyone together form the social graph that clients use for timelines and web-of-trust ideas.

The wrap's content is a NIP-44 encrypted seal. Relays see only a random pubkey, a fuzzed timestamp and the recipient's p tag, so they cannot tell who sent it.

Cryptographic hash functions are one-way (you cannot recover the input) and collision resistant (you cannot find two inputs with the same output). Nostr uses SHA-256.

Hashing is how an event id identifies one exact event, and proof of work counts leading zero bits of that hash.

Without a central authority there is nobody to prove ownership to. Mitigations are operational: back up your nsec offline, use a signer, and if a key leaks, announce a new key from it while you still can and ask followers to switch.

Generating a keypair is instant and offline: pick 32 random bytes, multiply the secp256k1 generator point by them, and you have a public key. No server has to approve it.

The math only works one way: the public key is easy to compute from the private key, but the private key cannot be recovered from the public key.

Kinds are defined across the NIPs. Their numeric range also tells relays how to store them: 1000–9999 (plus 1, 2, 4–44) are regular and kept; 10000–19999 (plus 0 and 3) are replaceable; 20000–29999 are ephemeral and not stored; 30000–39999 are addressable.

Clients ignore kinds they do not understand, which is how new features ship without breaking old apps.

Defined by LUD-16: alice@wallet.example resolves to https://wallet.example/.well-known/lnurlp/alice, an LNURL-pay endpoint. NIP-57 clients read it from your kind 0 metadata to start a zap.

In a zap, the recipient's LNURL server returns a description-hash invoice whose description is the signed zap request; the zap receipt later carries it in a bolt11 tag.

A Lightning invoice (bolt11 string, lnbc…) commits to an amount and a payment hash; paying it reveals a preimage that proves payment. Nostr zaps are Lightning payments with a Nostr receipt.

With LNURL-pay (LUD-06) the wallet fetches the server's pay parameters, then calls its callback with an amount to receive an invoice. For zaps the server advertises allowsNostr and a nostrPubkey and accepts a nostr zap request as a parameter.

Because they are addressable, articles can be edited without breaking links. Reader apps render them like blog posts and link to them with naddr.

Kind 0 is replaceable, so updating your profile publishes a new one. Extra fields such as display_name, banner and website come from NIP-24.

In privacy discussions (chapter 8) metadata means something else: data about a communication rather than its content, such as who talks to whom, when, how often and how long. Encryption hides the content, but metadata can still reveal a lot unless it is hidden too, which is what gift wraps are for.

A NIP-19 TLV entity: type 0 is the d tag identifier, type 1 relays, type 2 the author and type 3 the kind. Because it points to an address, the link keeps working after the article is edited.

The key is encrypted with scrypt and XChaCha20-Poly1305, so a leaked backup is useless without the password.

A NIP-19 TLV entity: type 0 is the event id, type 1 a relay URL (repeatable), type 2 the author pubkey and type 3 the kind. The hints help a client find the event on relays it does not already use.

NIPs live in the nostr-protocol/nips repository on GitHub. Only NIP-01 is required; everything else is optional, and clients and relays advertise or simply implement the ones they care about.

A NIP is adopted when several independent apps implement it, not by a vote, so the protocol grows by rough consensus and running code.

If you implement NIP-01 you can publish and read on any relay. It defines the event JSON, how to serialize and hash it, Schnorr signatures, the EVENT/REQ/CLOSE client messages, the EVENT/OK/EOSE/CLOSED/NOTICE relay messages, and the regular/replaceable/ephemeral/addressable kind ranges.

NIP-04 encrypts content with AES-256-CBC using an ECDH shared secret, but the sender pubkey, the recipient p tag and the timestamp stay public, and the ciphertext has no authentication.

New apps should use NIP-17 private messages (NIP-44 encryption plus NIP-59 gift wraps) instead.

Put "nip05": "alice@example.com" in your profile; clients fetch https://example.com/.well-known/nostr.json?name=alice and check that the names entry points to your pubkey. The document may also list relays where you can be found.

It is verification of a domain relationship, not of a real-world identity, and the pubkey stays the true identity if the domain disappears.

The extension exposes getPublicKey() and signEvent(event), plus optional nip04 and nip44 encrypt/decrypt. The website builds an unsigned event; the extension shows it to you and returns it signed.

Clients fetch it from the relay's own URL (with https:// instead of wss://) before connecting, to learn whether the relay needs payment or authentication and how big events and subscriptions may be.

The chat message (kind 14) is an unsigned rumor; it is encrypted with NIP-44 into a kind 13 seal signed by the sender, which is encrypted again into a kind 1059 gift wrap signed by a throwaway key and addressed to the recipient.

Users publish a kind 10050 list of the relays where they want to receive DMs. Separate wraps are made for every recipient and for the sender's own copy.

The simple forms wrap raw 32 bytes. The TLV forms (type–length–value) pack extra fields such as relay URLs, author and kind, so a link carries enough hints to find the data.

These strings are for display and sharing only. NIP-21 adds the nostr: URI scheme (nostr:npub1…) for links.

Each article has a d tag identifier, so editing republishes the same address instead of creating a new post. Optional tags include title, summary, image and published_at.

The relay sends ["AUTH", <challenge>]; the client replies ["AUTH", <event>] where the event carries relay and challenge tags. Relays use it to restrict reading or writing, for example to paying members or to the recipients of private messages.

Relays signal that auth is needed with "auth-required:" prefixes in OK and CLOSED messages.

A conversation key is derived once per pair of keys from the ECDH shared secret with HKDF (salt "nip44-v2"). Each message gets a random 32-byte nonce, from which ChaCha20 and HMAC keys are derived; the plaintext is padded to hide its exact length and authenticated with HMAC-SHA256.

It is a building block, not a messaging protocol: NIP-17 and NIP-59 use it to build private messages, and NIP-46 uses it for signer traffic.

Requests and responses are kind 24133 events encrypted with NIP-44 between the app's temporary key and the remote signer. A connection starts from a bunker:// URI given by the signer or a nostrconnect:// URI shown by the app.

The private key never leaves the signer, which can run on your phone, a server or a hardware device and can ask you to approve each request.

The client sends a zap request to the recipient's LNURL server (it is not published to relays), pays the returned invoice, and the recipient's wallet server publishes a zap receipt with the bolt11 invoice and the original request.

The receipt is signed by the wallet server's nostrPubkey: it is that server's claim that the invoice was paid, not a proof of payment, and it does not authenticate the sender beyond the embedded signed zap request.

Three layers: the rumor (an unsigned event), the seal (kind 13, signed by the real author, rumor encrypted with NIP-44) and the gift wrap (kind 1059, signed by a random throwaway key, with a p tag for the recipient).

Timestamps on the seal and wrap are randomized into the past so relays cannot correlate messages by time.

Each relay is an r tag, optionally marked "read" or "write"; no marker means both. Clients fetch your posts from your write relays and deliver mentions of you to your read relays.

This list is the foundation of the outbox model. NIP-65 advises keeping it small, about two to four relays per category.

Nostr stands for "Notes and Other Stuff Transmitted by Relays". There is no central server and no account to create: your identity is a keypair, every message is a signed event, and relays are simple servers that store and forward events.

Because events are signed, anyone can verify who wrote them no matter which relay delivered them. If one relay bans you, you publish somewhere else and your followers can still find you.

Kind 1 is the plain-text post that timelines are made of; replies and threads are marked with e and p tags (NIP-10). The note1… string from NIP-19 wraps just the 32-byte id with no relay hints, so nevent is usually more useful.

A NIP-19 TLV entity with the pubkey (type 0) and any number of relay URLs (type 1). Prefer it to a bare npub when you want others to actually find the person's events.

Defined in NIP-19. The "npub" prefix tells you what the string is and the built-in checksum catches typos. Decoding an npub gives back exactly the same 32 bytes as the hex pubkey.

npubs are for display, sharing and QR codes; the protocol itself always uses hex.

The distinct "nsec" prefix exists so software and people can recognise a secret at a glance and refuse to paste it where it does not belong.

Treat an nsec like the master password of your whole Nostr identity: store it in a signer or password manager and never type it into a website.

Also called the gossip model. Using NIP-65 relay lists, a client looks up the write relays of everyone you follow and fetches from those, and delivers replies to the read relays of the people being mentioned.

It keeps Nostr decentralized: no single relay needs everyone's data, and small relays remain reachable.

Relays describe their policies in a NIP-11 information document (limitation.payment_required, fees) and commonly use NIP-42 auth to recognise paying members.

The private key (secret key) is a random 256-bit number between 1 and the secp256k1 curve order (points on the curve are public keys). It signs your events and, together with someone's public key, derives shared secrets for encrypted messages.

There is no password reset in Nostr: if it leaks, an attacker can post as you forever; if you lose it, the identity is gone. Keep it in a dedicated signer instead of pasting it into websites.

NIP-13 adds a ["nonce", <counter>, <target difficulty>] tag. The difficulty is the number of leading zero bits in the id; each extra bit doubles the expected work. Relays can demand a minimum difficulty.

Nostr uses BIP-340 "x-only" public keys, derived from the private key. Every event carries the author's pubkey, and anyone can use it to check the event's signature.

Inside events and relay messages pubkeys are always lowercase hex; the npub form is only for humans.

Reactions carry an e tag for the event and a p tag for its author, and may add a k tag with the reacted kind. Custom emoji use NIP-30 shortcodes.

Relays speak a tiny protocol over WebSocket (NIP-01): clients send EVENT to publish, REQ to subscribe and CLOSE to stop; relays answer with EVENT, OK, EOSE, CLOSED and NOTICE.

Relays do not talk to each other and do not own your identity. Each one sets its own rules: some are free and open, some are paid, some require authentication, and any of them may drop events it does not want. Clients usually read from and write to several relays at once.

Kinds 0, 3 and 10000–19999 are replaceable. When a relay receives a newer one it may delete the older; if two share the same created_at, the one with the lowest id wins.

The repost carries e and p tags pointing to the original and may embed the original event JSON in its content. Quoting instead is a new note with a q tag.

A relay answers a REQ with every stored event that matches, then EOSE, then keeps streaming new matching events until the client sends CLOSE or the relay sends CLOSED.

Because it is unsigned, a leaked rumor cannot be proven to come from its author, which gives private messages deniability. Authenticity comes from the seal around it, whose pubkey must match the rumor's pubkey.

Schnorr signatures are short, fast to verify and simple to reason about. Nostr signs the 32-byte event id, so the signature commits to every field of the event.

BIP-340 signing can mix in fresh randomness (auxiliary data), so signing the same event twice can produce different, equally valid signatures.

The seal proves who the author is to the recipient (and only the recipient, since it is itself hidden inside the wrap). Its tags are always empty so nothing leaks.

Private keys are numbers between 1 and the curve order (just under 2²⁵⁶); public keys are points on the curve. Nostr reuses Bitcoin's battle-tested libraries and the BIP-340 Schnorr scheme on this curve.

The same curve also powers ECDH, which NIP-04 and NIP-44 use to derive shared secrets for encryption.

An event id is SHA-256 of the UTF-8 bytes of the serialized event. SHA-256 also appears inside NIP-44 (HKDF and HMAC) and in Lightning payment hashes.

Anyone can verify a signature with just the event and the public key, so relays and clients never need to trust each other: a forged or modified event simply fails verification.

Signatures prove authorship, not truth or timing: created_at is whatever the author claimed.

Using a signer means apps never see your key, and you can approve or reject each request. Common options are NIP-07 browser extensions, NIP-46 remote signers and NIP-55 Android signer apps.

Tools include paid relays, NIP-42 authentication, NIP-13 proof of work, web-of-trust filtering in clients, mute lists and NIP-56 reports (kind 1984). Each trades some openness for less noise.

The client chooses the subscription id. Events come back as ["EVENT", <subscription id>, <event>]; EOSE marks the end of stored events; the client ends it with CLOSE, and the relay may end it with CLOSED and a reason.

Sending a new REQ with the same id replaces the old subscription on that connection.

The first element is the tag name, the rest are values. Common ones: e (event reference), p (pubkey), a (addressable event coordinate), d (identifier of an addressable event), t (hashtag).

Relays index single-letter tags, so a filter like {"#p": [<pubkey>]} finds every event that mentions a person.

It is not a single NIP but a family of client and relay techniques built on follow lists, mutes and reports. It filters spam and impersonators without a central moderator, at the cost of making new users harder to discover.

Relay URLs start with wss:// (or ws:// locally). One connection can carry many subscriptions at once, and the relay can push new events the moment they arrive, without polling.

Zaps turn likes into real value and give relays and clients a spam-resistant signal. Under the hood they follow NIP-57: zap request, Lightning invoice, payment, zap receipt.