Nostr Glossary
A reader-first glossary for Nostr: not a pile of protocol trivia, but the words that help a new user understand keys, clients, relays, events, NIPs, signers, zaps and trust.
How to use this glossary
A glossary is only useful if it reduces panic. Nostr has too many small words that sound obvious to insiders and strange to everyone else: npub, nsec, relay, event, kind, signer, zap, NIP, outbox, web of trust, bunker, gift wrap. The goal here is not to turn a beginner into a protocol engineer. It is to make the next page readable.
Use this glossary as a translation layer. When a client asks for a private key, read nsec and signer. When a profile will not load, read relay and NIP-65. When a link begins with nostr:, read NIP-19 and address. When a wallet prompt appears, read zap and Nostr Wallet Connect. When a moderation debate gets abstract, read labels, web of trust and relay policy.
The deeper NIPs pages carry the full protocol detail. This page keeps the reader-level meaning and points to the right shelves.
Identity words
Public key: the public identifier for a Nostr identity. It can be represented as a hex string or as an npub. People can follow it, mention it and verify events signed by the matching private key.
Private key: the secret that signs events for a public key. It may appear as an nsec. Treat it as live authority over the identity. Do not paste a serious private key into websites unless you truly understand the trust you are granting.
npub: a bech32-encoded public key from NIP-19. It is the format many users copy and share because it is easier to recognize than raw hexadecimal.
nsec: a bech32-encoded private key. If you see nsec, think signing secret. It is not a username. It is not a profile link. It is the thing you protect.
NIP-05 identifier: a human-readable name tied to a domain, such as name@example.com. It helps recognition by letting a domain point to a Nostr public key. It does not replace the key and does not recover a lost key.
Profile metadata: a signed event, usually kind 0, containing things such as display name, about text, picture, banner, website, Lightning address and NIP-05. Clients render it differently.
Publishing words
Event: the basic Nostr data object. A note, profile update, follow list, reaction, repost, zap request, file metadata record or long-form article can be an event. Events have a kind, public key, content, tags, timestamp, id and signature.
Kind: the event type number. Kind 1 is a short text note. Kind 0 is profile metadata. Other kinds represent follow lists, relays, long-form content, zaps, wallet messages, labels and many more behaviors.
Content: the main body of an event. In a text note it is the text. In some events it can be empty or structured differently because the important data sits in tags.
Tags: arrays inside events that point to people, events, addresses, topics, relays or other structured data. Tags are how a simple event object can carry replies, mentions, references and protocol-specific details.
Signature: the cryptographic proof that the event was signed by the private key matching the public key. Clients use it to reject forged events.
Delete request: a signed event asking relays and clients to treat another event as deleted. It is not a guarantee that every copy vanishes everywhere. It is a request in an open relay ecosystem.
Relay words
Relay: a server that accepts client connections, receives events and returns events that match subscription filters. Relays can be public, paid, private, community-specific, specialized or temporary.
WebSocket: the connection style clients use to talk to relays. NIP-01 describes the client-to-relay message patterns over this connection.
EVENT: the client message used to publish an event to a relay.
REQ: the client message used to request events with filters and subscribe to new matching events.
CLOSE: the client message used to close an existing subscription.
Filter: the query shape a client sends to a relay. It can ask for authors, event ids, kinds, tag values, time ranges and limits.
Read relay: a relay a client queries to find events.
Write relay: a relay a client publishes events to.
Relay list: a user's published relay preferences, often discussed around NIP-65. It helps other clients discover where to read from and write to for that user.
Outbox discovery: the idea that clients find where authors publish by looking at relay hints and lists instead of blasting every relay with every query.
Client and signer words
Client: an app or tool that reads, writes and renders Nostr events. Mobile apps, web apps, desktop apps, bots and command-line tools can all be clients.
Signer: a tool that signs events for a client without forcing the client to hold the raw private key. Browser extensions, mobile signers and remote signers all fit this mental slot.
NIP-07: the browser signer standard. It defines a window.nostr interface that web apps can use to request a public key or event signature from an extension.
NIP-46: remote signing and Nostr Connect. It lets signing happen through a separate signer path over relays, often by approving requests on another device or service.
Bunker: a common term for a remote signer setup. It keeps signing authority away from the ordinary web page and exposes a controlled signing interface.
Permission: the practical question behind every signer prompt. What can this client request? Can it sign any event? Which event kinds? Can access be revoked? The UI needs to make that clear.
Standards words
NIP: a Nostr Implementation Possibility. NIPs document behavior that Nostr-compatible clients and relays may implement. They are not all mandatory, and a good app only implements the pieces it needs.
Draft: a standard state that signals the NIP may still change. Draft does not mean unused; it means implementation needs attention to changes.
Final: a stronger status for a NIP that has settled. Final does not mean every client supports it.
Unrecommended: a warning that a NIP or approach has known problems or has been superseded. NIP-04 encrypted DMs are a classic beginner example because newer private messaging work moved toward NIP-17 and NIP-44.
Interoperability: the reason NIPs matter. If two clients understand the same event kind and tags, they can render similar behavior without sharing one backend.
Protocol: the agreed message and data model. Product experience lives above it.
Money and media words
Zap: a Lightning payment connected to a Nostr event, usually associated with NIP-57. Zaps made small value signals visible in social clients.
Lightning address: an address-like payment identifier often shown in a Nostr profile. It is not the same thing as a Nostr public key.
Nostr Wallet Connect: NIP-47. A way for apps to request wallet actions through Nostr messages without becoming the wallet itself.
Cashu wallet: an ecash-style wallet model that appears in Nostr through NIP-60 and related tools. It has different trust and custody questions from a normal Lightning wallet.
Long-form event: a Nostr event type for article-like publishing. Nostr can carry more than short notes when clients support the relevant NIPs.
Blossom and NIP-96: media/file storage approaches. Nostr events can reference media, but large file storage is a separate product and infrastructure question.
Trust and safety words
Web of trust: using relationships, follows, attestations or other social signals to help rank, filter or trust information. It is not one universal algorithm.
Relay policy: the rules a relay applies. A relay can reject spam, require payment, block event kinds, rate limit clients or curate a community.
Client moderation: the filtering or ranking a client applies. A client can hide events without changing the protocol.
Label: a signed event used to attach classifications or moderation signals to other events or people. Labels can support distributed moderation models.
Censorship resistance: a realistic property, not a magic spell. Nostr makes single-platform control harder by separating keys, clients and relays, but infrastructure, spam, discovery and social pressure still matter.
Key rotation: moving from one key to another after a loss or compromise. Nostr does not make this as simple as a password reset. Social recovery and reputation rebuilding remain hard.
Beginner phrases that hide real decisions
"Log in with Nostr" can mean several things. It can mean read-only login with a public key, browser signing through NIP-07, remote signing through NIP-46, local key storage or a temporary identity. The phrase is friendly, but the implementation decides the risk.
"Own your identity" also hides detail. You own the signing key if you control it. You do not automatically own every copy of every event, every media file, every relay policy or every client ranking system. Identity control is real, but it is not total control over the network.
"Decentralized" is another word to handle carefully. Nostr has no central platform account database, but it still uses infrastructure. Relays, clients, app stores, DNS, hosting providers, wallet services and social trust all matter. The useful question is where power sits in a given flow.
Address and link words
note: a bech32-encoded event id. People use it to share a specific event in a friendlier format than raw hexadecimal.
nevent: a richer NIP-19 event pointer that can include relay hints. It helps clients find a specific event more reliably than a bare id.
nprofile: a NIP-19 profile pointer that can include a public key and relay hints. It is useful when a link needs to tell a client where to find profile data.
naddr: an address pointer for addressable events. It can point to long-form content or other replaceable/addressable records by kind, author and identifier.
nostr: URI: a link format that lets apps open Nostr entities. It is one bridge between web pages, native apps and protocol objects.
Private message words
NIP-04: the older encrypted direct message standard. It is widely known but no longer the preferred long-term direction for private messaging.
NIP-17: a newer private direct message flow. It works with gift wrapping and separates private message handling from the old NIP-04 model.
NIP-44: versioned encryption. It gives modern encrypted payload handling used by newer private flows.
Gift wrap: a privacy pattern associated with NIP-59. It wraps events so metadata exposure is reduced compared with naive direct-message designs.
Secret chat: a product term used by some clients for stronger local or session-style privacy. Always read the client's own documentation; product names are not protocol guarantees.
Community and governance words
Badge: a signed record that can represent recognition, membership, achievement or affiliation. Badges can be playful or serious depending on issuer and context.
List: a signed collection of people, relays, bookmarks or other entities. Lists are one of the building blocks for curation and personal organization.
Mute list: a list used to hide people, words or threads from a client view. It is personal moderation rather than universal deletion.
Relay group: a group model where a relay has a more active role in membership or moderation. NIP-29 is the common reference point.
Labeler: a service or identity that publishes labels other clients may use for moderation, trust, classification or filtering. The value depends on who labels and how clients expose choice.
Developer-facing words a reader will still see
Kind: the numeric event type. Kind 0 is profile metadata, kind 1 is a short text note, kind 3 is a follow list, and many other kinds describe richer behavior. A reader does not need to memorize all kinds, but the word appears often in clients and NIP pages.
Tag: structured data inside an event. Tags can point to people, events, relays, subjects, identifiers and more. They are how many relationships become machine-readable without turning Nostr into one giant database schema.
Filter: a client query sent to a relay. It can ask for events by author, kind, tag, time range or limit. When a client feels fast or slow, the quality of filters and relay responses often matters.
Subscription: an active client request to a relay. A client subscribes to events matching a filter, receives matching results and may keep listening for new ones. This is one reason relays feel more like live event servers than static web pages.
Product words that change risk
Signer: software that signs events without handing the private key directly to every app. Browser signers, mobile signers and remote signers can reduce key exposure when designed well.
Bunker: a remote signing setup, often discussed around NIP-46. It can let a client request signatures from a separate signing service or device. The trust and permission model matters.
Permission: what an app is allowed to ask or do. In Nostr, this can involve signing events, reading identity, connecting to a wallet or requesting payments. Friendly buttons can hide serious permissions.
Backup: the practical plan for not losing a key. Backups can include seed phrases, encrypted key storage, hardware signers or recovery workflows depending on tool. There is no universal platform reset button.
Social words that need care
Web of trust: a way to use social distance or trusted relationships to rank, filter or discover content. It can reduce spam and improve relevance, but it also creates boundaries that need transparency.
Global feed: a view of public events from selected relays or indexes. It is not the whole network and often gives beginners a distorted sense of Nostr culture.
Relay policy: the rules a relay uses for accepting, storing, rejecting or limiting events. A relay may be open, paid, invite-only, moderated, local, archival, experimental or specialized.
Client policy: the choices an app makes about ranking, filtering, moderation, supported event kinds and default relays. Two clients can show very different worlds from the same key.
Wallet and zap words
Zap: a Nostr-native Lightning payment interaction, commonly associated with NIP-57. A zap is social money, not just a like with a price tag.
Lightning address: a human-readable payment address that can receive Lightning payments. It may appear in a Nostr profile, but it belongs to a wallet or service outside the social protocol itself.
Nostr Wallet Connect: a permission model that lets apps request wallet actions from a wallet. It is powerful because clients can add payments without holding funds. It is sensitive because payment permissions deserve care.
Invoice: a Lightning payment request. If a client or wallet cannot create, read or pay the invoice correctly, the zap flow breaks even if the social side of Nostr works.
Relay words
Relay: a server that accepts, stores and returns Nostr events over the protocol. A relay is not the user account and not the whole network. It is one place a client can publish to or read from.
Paid relay: a relay that requires payment or membership. Paid relays can reduce spam, fund operations and create stronger service expectations, but they also introduce access decisions.
Archival relay: a relay focused on long-term storage or retrieval. This matters for people who care about history, public records, publishing, research or durable profiles.
Outbox model: a discovery pattern where clients learn which relays an author uses for publishing. It helps other clients find events without guessing every relay in the world.
Relay hint: a clue included in some pointers or metadata that tells a client where an event or profile may be found. Hints are not guarantees, but they improve the chance that links resolve.
Identity and verification words
Public key: the visible identity anchor. It can be shared, followed, linked and verified by clients. In bech32 form it often appears as an npub.
Private key: the secret that controls signing. It is not a password. If it is exposed, the identity can be taken over. If it is lost, recovery may be impossible without a backup or signer setup.
NIP-05: a DNS-based identifier that connects a Nostr public key to a human-readable name at a domain. It helps recognition, but it does not replace key safety.
Impersonation: a fake profile using a familiar name, avatar or bio. Nostr makes signatures verifiable, but it does not stop people from copying social signals. Readers still need source checks.
Key rotation: the difficult process of moving attention or identity from one key to another. Some tools can help announce a move, but social continuity is harder than changing a password.
Standards words
NIP: a Nostr Implementation Possibility. The name matters because NIPs are not a mandatory checklist. They describe behavior that clients, relays or tools may implement when the use case fits.
Required: a word that has meaning inside a specific NIP or protocol rule, not across every possible app. A client can be Nostr-compatible while supporting only the NIPs needed for its product.
Unrecommended: a status used for older or problematic patterns. It does not mean the feature vanished from every client. It means new implementations have better paths to consider.
Draft: a proposal or evolving document. In practice, some draft behavior can be implemented before it feels settled, which is why readers need to look at products and repositories, not only titles.
Compatibility: the practical question of whether two tools understand the same event shapes, tags, encryption patterns or link formats well enough to give the user a coherent experience.
Media and publishing words
Long-form event: a Nostr event used for articles or essays rather than short notes. Different clients may render, discover and edit long-form content with different levels of polish.
Blossom: an ecosystem around file storage and media serving that often appears in Nostr media discussions. It is related to publishing experience, but it is not the same thing as a relay.
File metadata: structured information about a file, such as type, hash, size or URL. Metadata helps clients display media and verify what they are handling.
Highlight: a clipped quotation or reference event. Highlights can turn reading into a social object, letting people cite and discuss parts of articles across clients.
Wiki event: an event pattern for shared knowledge pages. It shows how Nostr can move beyond timelines into public, addressable knowledge objects.
