Nostr Glossary
A grouped glossary that explains Nostr terms by function: identity, events, relays, clients, payments, media, trust and product consequences.
A flat glossary makes Nostr feel harder than it is. The better way is to group the words by the job they do. Once you know which words belong to identity, events, relays, clients, payments and trust, the whole map gets calmer.
Identity words
Public key, private key, npub, nsec, signature and NIP-05 all live in the identity family. The public key is the identifier. The private key signs. The signature proves authorship. NIP-19 gives safer-looking display formats. NIP-05 gives you a domain-backed name people can recognize.
The practical mistake is mixing public and private language. npub can go on a profile, a business card or a QR code. nsec should be treated like a master secret. A product that does not make that difference painfully clear is training users badly.
- npub. Public key display format.
- nsec. Private key display format.
- NIP-05. DNS-backed identifier, not custody and not recovery.
Event words
Event, kind, tag, content, id and signature belong together. An event is the signed object. The kind says what type of thing it is. Tags create references, mentions, relay hints, subjects, labels and other structured context.
This is the middle of the protocol. If you understand events, you can understand why Nostr can represent posts, profiles, follows, relays, zaps, badges, long-form articles, file metadata and more without becoming one giant app specification.
Relay words
Relay, filter, subscription, EOSE, OK, CLOSED, NIP-11 and NIP-65 are infrastructure words. A client sends an EVENT to publish or a REQ with filters to ask for matching events. A relay can accept, reject, close, rate-limit or return stored and live results.
NIP-11 lets relays describe capabilities and administrative details. NIP-65 lets a user publish preferred read and write relays. Together they help clients stop guessing, although relay discovery is still one of the rougher edges in daily Nostr use.
Client and signer words
Client, signer, extension, remote signer and Nostr Connect describe the part you actually touch. A client creates the experience. A signer protects the key by approving signatures without forcing you to paste the private key into every web app.
NIP-07 is the browser signer pattern. NIP-46 covers remote signing. The product standard is simple: if a feature asks for power, the prompt should explain the power in words a normal person can understand.
Money words
Zap, Lightning, invoice, receipt, NWC and wallet service sit in the value-flow family. NIP-57 defines zap requests and zap receipts. NIP-47 lets a client interact with a Lightning wallet through a standardized Nostr Wallet Connect flow.
Do not confuse a zap with a business model. A zap is a payment signal. Creator income, paid content, membership, venue access and awards need product rules, refunds, abuse controls, accounting and user support around the protocol event.
Media and storage words
File metadata, blob, Blossom, NIP-94 and NIP-96 explain where larger media fits. Nostr relays are not meant to become infinite video storage. A note can reference a file, but the file has to be hosted, hashed, mirrored, authorized and kept available somewhere.
Blossom is important because it treats binary data as sha256-addressed blobs on HTTP media servers while still using Nostr keys for identity. That creates a clearer split between signed social records and heavier media infrastructure.
Trust and moderation words
Mute list, block list, web of trust, report, label, relay policy, paid relay and community are social-control words. Nostr does not remove moderation. It distributes moderation decisions across clients, relays, communities and user-controlled lists.
That is not a weakness if the product explains it well. You need to know who is filtering what, whether a relay stores the event, whether a client hides it, and whether a community rule is local or network-wide.
Product words we use carefully
Portable does not mean permanent. Decentralized does not mean every part is equally distributed. Signed does not mean safe. Encrypted does not mean the whole workflow is private. Relay does not mean platform. NIP does not mean finished product.
Those distinctions keep the archive honest. You can be excited about Nostr and still speak with precision.
Event kinds you should recognize early
Kind 0 is profile metadata. Kind 1 is a short text note. Kind 3 is a contact list. Kind 4 was early encrypted direct messages and has been superseded in serious discussions by newer encryption approaches. Kind 10002 is relay list metadata. Long-form articles, badges, zaps, file metadata and many app-specific objects use other kinds.
You do not need to memorize every kind. You need to understand that kind numbers let clients and relays know what sort of signed object they are handling.
Replaceable and addressable events
Some events are ordinary one-time records. Others are replaceable: a newer event by the same author and kind replaces the older version. Addressable events add a d tag so multiple records of the same kind can exist under stable addresses. That is why naddr exists.
This matters for profiles, relay lists, long-form articles, lists, badges and app data. Without replaceable and addressable behavior, Nostr would be much worse at representing living records.
Status words in the NIP repo
Mandatory means the base protocol expects it. Optional means software can support it when useful. Draft means the idea is not settled. Final means the document is considered stable. Unrecommended means the ecosystem has a better path or the older path should no longer be preferred.
That last word is important for media. NIP-96 is now marked unrecommended in favor of Blossom, so any serious glossary needs to explain both the older HTTP file-storage path and the newer Blossom direction.
A glossary should protect you from hype
When you know the words, you can hear sloppy claims. A relay is not a platform. A NIP is not adoption. A signature is not consent if the signer prompt is unreadable. A zap is not a business model. A public key is not a verified human. A file URL is not permanent storage.
This is why the glossary is not a word dump. It is a defense against confusion.
How to place Nostr Glossary on the map
Read Nostr Glossary as part of the Start route, not as an isolated entry. Its main surface is first-principles learning: keys, clients, relays, events and the first safe mental model. That framing matters because a Nostr page is useful only when you can see which layer it belongs to and which layer it does not solve by itself.
The first question is practical: what changes for you if Nostr Glossary works well? Sometimes the answer is safer signing, sometimes better relay discovery, sometimes clearer media storage, sometimes a stronger source trail. Keep that question in front of you and the page becomes easier to judge.
- Layer. Start is the parent route, so the page should send you back to that shelf and sideways into adjacent concepts.
- Evidence. The current source trail starts with Nostr protocol repository, Nostr NIPs, nostr.how, NIP-01. Treat those as anchors, then compare product behavior and NIP support.
What Nostr Glossary should help you decide
A good page about Nostr Glossary should leave you with a decision, not just recognition. You should know whether it is a protocol primitive, a client behavior, a relay operation, a product example, a research source or our implementation question. That distinction keeps the archive from becoming a flat glossary.
The common mistake is starting with jargon before the reader knows what problem the protocol solves. We avoid that by making the claim, the evidence and the next step visible. If a statement depends on a NIP, the page should point to that NIP. If it depends on a project, the page should show the project source. If it affects user safety, the page should say what can fail.
The working example behind Nostr Glossary
Use this page with a concrete mental test: a reader should be able to explain why their identity can move before they learn every NIP number. That example is more useful than a generic definition because Nostr is not one product. The same signed event can be read by different clients, stored by different relays and interpreted through different product choices.
This is also why internal links matter. When the page mentions keys, clients, relays, events, zaps, Blossom, Cashu, FoundUPS or NIPs, those words should lead to the page that explains the concept more deeply. The goal is not to trap you in tabs; the goal is to let you move with context.
Source discipline for Nostr Glossary
The source list is part of the content, not decoration. For Nostr Glossary, use primary protocol documents first when the claim is technical, project repositories or product pages when the claim is about an app, and research or directory sources when the claim is about ecosystem position. If the sources disagree, the page should show the uncertainty instead of smoothing it away.
That source discipline is how a large archive stays trustworthy. It also helps learning: you get a short explanation first, then a route to the source that proves or complicates it. The page should feel like a guided chapter, but the evidence should still be close enough to inspect.