How to Verify a NIP: GitHub History, Implementations and Product Claims
A deep guide to reading official NIP markdown, README status, Git history, implementation evidence, event kinds, libraries, relay behavior and product marketing without getting fooled.
Why this part of the NIP map matters
A NIP article is useful only if it teaches you how to verify the claim. Nostr is full of words that sound precise until you ask for the source: supports NIP-07, uses NIP-47, compatible with zaps, encrypted messages, portable identity, relay discovery, marketplace events. Sometimes the claim is true. Sometimes it is partly true. Sometimes the product supports the headline but not the edge cases that matter.
The verification habit is simple: open the official markdown, check the README status, inspect the commit history when the detail is sensitive, look for at least one implementation, test behavior across more than one client or relay and read the product surface as a set of trust boundaries. That sounds like work because it is. The reward is that you stop treating screenshots as standards.
Use this whenever a page, app, relay, wallet or person says "NIP support" as if the acronym alone proved the product. A NIP is a starting point for verification, not a stamp.
The mental model
The official markdown tells you the current wording. It does not tell you whether every product implements it well.
The README tells you status and warnings. Those warnings belong in your decision, not in the footnotes.
Git history tells you when a detail changed and who touched it. That matters when a product, article or library repeats an older interpretation.
Implementations tell you whether the standard left the page. Look for libraries, clients, relays, wallets and event inspectors that actually support the behavior.
Product claims need boundaries. Ask what is signed, stored, encrypted, relayed, paid, displayed and recoverable before you trust the feature.
Read this topic with one hand on the protocol and one hand on the product. The protocol tells you the shared format. The product tells you what a person actually sees, approves, loses, recovers or can take elsewhere. Both are necessary. One without the other creates either abstract standards talk or a pretty interface with no durable proof underneath.
Use the source links as proof, not as decoration. A useful NIP explanation gives you the mental model first, then sends you to the official markdown when exact fields, status notes, examples or implementation details matter.
The NIP pages in this topic
Basic protocol flow description
NIP-01 is the base contract: event shape, signatures, filters, client-relay messages and the meaning of tags. Everything else inherits its discipline.
Ask what Basic protocol flow description changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch kind 1, kind 10002, relay, event, event.id, kind:1 because these are the terms that usually surface as product behavior. Nearby standards: NIP-10.
Mapping Nostr keys to DNS-based internet identifiers
NIP-05 gives a public key a readable internet identifier, but it does not turn identity back into a platform login. The key remains the identity; the domain is evidence.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch "names", <name>, pubkey, "relays", npub, /.well-known/nostr.json?name=<local-part> because these are the terms that usually surface as product behavior. Nearby standards: NIP-19.
window.nostr capability for web browsers
NIP-07 is the browser-signer bridge. It lets a web app request signatures without taking the private key, but the prompt still has to make the signed event legible.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch id, pubkey, sig because these are the terms that usually surface as product behavior. Nearby standards: NIP-04, NIP-44.
Relay Information Document
Relays may provide server metadata to clients to inform them of capabilities, administrative contacts, and various server attributes. This is made available as a JSON document over HTTP, on the same URI as the relay's websocket.
Ask which relay is trusted, what it stores, how it authenticates, how clients discover it and what happens when it is missing. Watch relay, Access-Control-Allow-Methods, name, pubkey, max_subid_length, max_limit because these are the terms that usually surface as product behavior. Nearby standards: NIP-17, NIP-01, NIP-09, NIP-13, NIP-42.
Private Direct Messages
NIP-17 belongs to the modern private-message stack. It is about delivery, wrapping and metadata reduction as much as encryption.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 14, kind 15, kind 7, kind 13, kind 1059, kind 10050 because these are the terms that usually surface as product behavior. Nearby standards: NIP-44, NIP-59, NIP-42, NIP-21.
bech32-encoded entities
NIP-19 makes Nostr pointers human-shareable through npub, nsec, note, nevent, nprofile and naddr forms.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch npub, nsec, nprofile, nevent, naddr, nrelay because these are the terms that usually surface as product behavior. Nearby standards: NIP-01, NIP-05.
Long-form Content
NIP-23 turns long-form work into a portable article object with title, summary, image, tags and addressability.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 30023, kind 30024, kind 1, kind 1111, kind:30023, kind:30024 because these are the terms that usually surface as product behavior. Nearby standards: NIP-37, NIP-19, NIP-27, NIP-21, NIP-22.
Encrypted Payloads (Versioned
NIP-44 gives encrypted payloads a modern versioned format. It protects content, not every piece of metadata around it.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind, created_at, base64 is invalid, hkdf_expand(OKM, info, L), secp256k1_ec_pubkey_tweak_mul, valid.get_conversation_key because these are the terms that usually surface as product behavior. Nearby standards: NIP-01, NIP-04.
Nostr Remote Signing
NIP-46 moves signing away from the app surface and into a remote signer, which changes the trust boundary around every sensitive click.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch kind 24133, kind 4, kind 1, kind 31990, remote-signer-key, remote-signer-pubkey because these are the terms that usually surface as product behavior. Nearby standards: NIP-44, NIP-05, NIP-89.
Nostr Wallet Connect
NIP-47 is Nostr Wallet Connect: a permissioned bridge between apps and wallets. It needs budgets, scopes and revocation to stay safe.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 23194, kind 23195, kind 23197, kind 23196, kind 9734, NIP-47 info event because these are the terms that usually surface as product behavior. Nearby standards: NIP-04, NIP-44, NIP-57.
Lightning Zaps
NIP-57 is the zap standard: Lightning value becomes a signed social receipt attached to a person, note or addressable object.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 9734, zap request, zap receipt, zap, nostrPubkey, relays because these are the terms that usually surface as product behavior. Nearby standards: NIP-23, NIP-01.
Relay List Metadata
NIP-65 lets a key publish relay-list metadata so clients can find where a profile reads and writes instead of guessing from defaults.
Ask which relay is trusted, what it stores, how it authenticates, how clients discover it and what happens when it is missing. Watch kind 10002, kind:10002 because these are the terms that usually surface as product behavior.
HTTP Auth
NIP-98 signs HTTP requests with Nostr keys. It can replace a normal web login for a request, but replay and URL matching must be exact.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch kind 27235, kind 27235, content, method, kind, created_at because these are the terms that usually surface as product behavior.
Follow List
A special event with kind 3, meaning "follow list" is defined as having a list of p tags, one for each of the followed/known profiles one is following.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch ["p", <32-bytes hex key>, <main relay URL>, <petname>], .content because these are the terms that usually surface as product behavior.
OpenTimestamps Attestations for Events
OpenTimestamps Attestations for Events -------------------------------------- The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch kind 1040, kind:1040, content because these are the terms that usually surface as product behavior.
Encrypted Direct Message
A special event with kind 4, meaning "encrypted direct message". It is supposed to have the following attributes: The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 4, relay, content, "content": "<encrypted_text>?iv=<initialization_vector>", tags, ["p", "<pubkey, as a hex string>"] because these are the terms that usually surface as product behavior. Nearby standards: NIP-17.
Basic key derivation from mnemonic seed phrase
Basic key derivation from mnemonic seed phrase ---------------------------------------------- The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch m/44'/1237'/<account>'/0/0, account because these are the terms that usually surface as product behavior.
Handling Mentions
This document standardizes the treatment given by clients of inline mentions of other events and pubkeys inside the content of textnotes. The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask what Handling Mentions changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch .tags, .content because these are the terms that usually surface as product behavior. Nearby standards: NIP-27.
Event Deletion Request
A special event with kind 5, meaning "deletion request" is defined as having a list of one or more e or a tags, each referencing an event the author is requesting to be deleted. Deletion requests SHOULD include a k tag for the kind of each event being requested for deletion.
Ask what Event Deletion Request changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch relay, content, pubkey, created_at because these are the terms that usually surface as product behavior.
Text Notes and Threads
["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]
Ask what Text Notes and Threads changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch kind 1, kind:1, .content, ["e", <event-id>, <relay-url>, <marker>, <pubkey>], <event-id>, <relay-url> because these are the terms that usually surface as product behavior. Nearby standards: NIP-21, NIP-22, NIP-01.
Generic Tag Queries
NIP-12 used to define generic tag queries and now lives inside NIP-01. Keep it in the map because tag filters are one of the quiet reasons a relay can answer useful questions instead of dumping a whole feed.
Ask what Generic Tag Queries changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Nearby standards: NIP-01.
Proof of Work
This NIP defines a way to generate and interpret Proof of Work for nostr notes. Proof of Work (PoW) is a way to add a proof of computational work to a note. This is a bearer proof that all relays and clients can universally validate with a small amount of code. This proof can be used as a means of spam deterrence.
Ask what Proof of Work changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch relay, created_at because these are the terms that usually surface as product behavior. Nearby standards: NIP-01.
Subject tag in text events
This NIP defines the use of the "subject" tag in text (kind: 1) events. (implemented in more-speech)
Ask what Subject tag in text events changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch kind 1 because these are the terms that usually surface as product behavior.
Nostr Marketplace (for resilient marketplaces
Where the merchant creates, updates and deletes stalls and products, as well as where they manage sales, payments and communication with customers. The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch id, tags, content, lnurl, naddr because these are the terms that usually surface as product behavior. Nearby standards: NIP-04, NIP-19.
Event Treatment
NIP-16 used to describe how clients and relays should treat replaceable, ephemeral and regular events. Its ideas moved into NIP-01, but the old page still explains why event lifetime is part of the base model.
Ask what Event Treatment changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Nearby standards: NIP-01.
Reposts
A repost is a kind 6 event that is used to signal to followers that a kind 1 text note is worth reading.
Ask what Reposts changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch kind 6, kind 1, kind 16, kind 6, kind 1, content because these are the terms that usually surface as product behavior. Nearby standards: NIP-70, NIP-21.
Command Results
NIP-20 defines command results: the small relay response events that tell a client whether publish, close or auth-related actions succeeded, failed or need a clearer explanation.
Ask what Command Results changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Nearby standards: NIP-01.
nostr: URI scheme
This NIP standardizes the usage of a common URI scheme for maximum interoperability and openness in the network.
Ask what nostr: URI scheme changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch kind 30023, nsec, kind:30023, rel="author" because these are the terms that usually surface as product behavior. Nearby standards: NIP-19.
Comment
A comment is a threading note always scoped to a root event or an I-tag.
Ask what Comment changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch kind 1111, kind 1, kind:1111, .content because these are the terms that usually surface as product behavior. Nearby standards: NIP-73, NIP-21, NIP-10, NIP-94.
Extra metadata fields and tags
This NIP keeps track of extra optional fields that can added to events which are not defined anywhere else but have become de facto standards and other minor implementation possibilities that do not deserve their own NIP and do not have a place in other NIPs.
Ask what Extra metadata fields and tags changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch kind 0, kind 3, display_name, name, displayName, username because these are the terms that usually surface as product behavior. Nearby standards: NIP-01, NIP-02, NIP-65, NIP-73, NIP-51.
Reactions
A reaction is a kind 7 event that is used to indicate user reactions to other events. A reaction's content field MUST include user-generated-content indicating the value of the reaction (conventionally +, -, or an emoji).
Ask what Reactions changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch kind 7, kind 17, kind 7, content, id, pubkey because these are the terms that usually surface as product behavior. Nearby standards: NIP-30, NIP-73.
Delegated Event Signing
This NIP defines how events can be delegated so that they can be signed by other keypairs. The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch kind 2, relay, kind, =${KIND_NUMBER}, created_at, kind=1&created_at<1675721813 because these are the terms that usually surface as product behavior.
Text Note References
This document standardizes the treatment given by clients of inline references of other events and profiles inside the .content of any event that has readable text in its .content (such as kinds 1 and 30023).
Ask what Text Note References changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch kind 1, kind 30023, .content, nostr:nprofile1qqsw3dy8cpu...6x2argwghx6egsqstvg, nostr:npub1..., nevent1... because these are the terms that usually surface as product behavior. Nearby standards: NIP-21, NIP-18, NIP-19.
Public Chat
This NIP defines new event kinds for public chat channels, channel messages, and basic client-side moderation. The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 40, kind 41, kind 42, kind 43, kind 44, 43 - hide message because these are the terms that usually surface as product behavior. Nearby standards: NIP-29, NIP-10.
Relay-based Groups
This NIP defines a standard for groups that are only writable by a closed set of users. They can be public for reading by external users or not.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 39000, kind 39003, kind 9000, kind 39001, kind 9021, kind 9009 because these are the terms that usually surface as product behavior. Nearby standards: NIP-98, NIP-11, NIP-51.
Custom Emoji
Custom emoji may be added to kind 0, kind 1, kind 7 (NIP-25) and kind 30315 (NIP-38) events by including one or more "emoji" tags, in the form:
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 0, kind 1, kind 7, kind 30315, kind 30030, kind:pubkey:d-tag because these are the terms that usually surface as product behavior. Nearby standards: NIP-25, NIP-38, NIP-51.
Dealing with Unknown Events
When creating a new custom event kind that is part of a custom protocol and isn't meant to be read as text (like kind:1), clients should use an alt tag to write a short human-readable plaintext summary of what that event is about. The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask what Dealing with Unknown Events changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch kind 1, kind:1 because these are the terms that usually surface as product behavior. Nearby standards: NIP-89.
Labeling
This NIP defines two new indexable tags to label events and a new event kind (kind:1985) to attach those labels to existing events. This supports several use cases, including distributed moderation, collection management, license assignment, and content classification.
Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. Watch kind 1985, kind 1, kind:1985, content because these are the terms that usually surface as product behavior. Nearby standards: NIP-01, NIP-09.
Parameterized Replaceable Events
NIP-33 introduced parameterized replaceable events, now folded into NIP-01 as addressable events. The important idea is the d tag: one public key can maintain a named object over time without changing its address.
Ask what Parameterized Replaceable Events changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Nearby standards: NIP-01.
git stuff
This NIP defines all the ways code collaboration using and adjacent to git can be done using Nostr.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 1621, kind 1617, kind 1618, relays, <relay-hint>, <identifier> because these are the terms that usually surface as product behavior. Nearby standards: NIP-10, NIP-22, NIP-65, NIP-B7.
Torrents
In order to make torrents searchable by general category, you SHOULD include a few tags like movie, tv, HD, UHD etc.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 2003, kind 2004, kind 1, kind 2003, ["i", "tcat:video,movie,4k"], kind 2004 because these are the terms that usually surface as product behavior. Nearby standards: NIP-10.
Sensitive Content
Sensitive Content / Content Warning -----------------------------------
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch content-warning because these are the terms that usually surface as product behavior. Nearby standards: NIP-32.
Draft Events
This NIP defines kind 31234 as an encrypted storage for unsigned draft events of any other kind.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 1234, kind 31234, .content, expiration, kind:1234, kind:31234 because these are the terms that usually surface as product behavior. Nearby standards: NIP-40, NIP-42, NIP-65.
User Statuses
This NIP enables a way for users to share live statuses such as what music they are listening to, as well as what they are currently doing: work, play, out of office, etc.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 30315, kind:30315, content because these are the terms that usually surface as product behavior. Nearby standards: NIP-30.
Linking Profiles to Other Platforms
Linking Profiles to Other Platforms -----------------------------------
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch platform:identity, <identity>, <instance>/@<username>, <username>@<instance>, <ref>/<id>, <id> because these are the terms that usually surface as product behavior.
Expiration Timestamp
The expiration tag enables users to specify a unix timestamp at which the message SHOULD be considered expired (by relays and clients) and SHOULD be deleted by relays.
Ask what Expiration Timestamp changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch relay, expiration because these are the terms that usually surface as product behavior.
Authentication of clients to relays
Authentication of clients to relays -----------------------------------
Ask which relay is trusted, what it stores, how it authenticates, how clients discover it and what happens when it is missing. Watch kind 4, kind 22242, relay, kind: 4, AUTH, OK because these are the terms that usually surface as product behavior.
Relay Access Metadata and Requests
This NIP defines a way for relays to advertise membership lists, and for clients to request admission to relays on behalf of users.
Ask which relay is trusted, what it stores, how it authenticates, how clients discover it and what happens when it is missing. Watch kind 13534, kind 10010, kind 8000, kind 8001, kind 28934, kind 28935 because these are the terms that usually surface as product behavior.
Counting results
Relays may support the verb COUNT, which provides a mechanism for obtaining event counts.
Ask what Counting results changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch relay, COUNT, REQ, {"count": <integer>}, {"count": <integer>, "approximate": <true|false>}, CLOSED because these are the terms that usually surface as product behavior. Nearby standards: NIP-65.
Bridged Events
Nostr events bridged from other protocols such as ActivityPub can link back to the source object by including a "proxy" tag, in the form:
Ask whether this is current guidance, historical context or compatibility material before you treat it as a product foundation. Watch <id> because these are the terms that usually surface as product behavior.
Private Key Encryption (ncryptsec
Private Key Encryption (ncryptsec) ------------------------------------
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity.
Search Capability
Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids. Specifics of the search algorithms will differ between event kinds, this NIP only describes a general extensible framework for performing such queries.
Ask which relay is trusted, what it stores, how it authenticates, how clients discover it and what happens when it is missing. Watch relay, REQ, content, .created_at, limit, kinds because these are the terms that usually surface as product behavior.
Lists
This NIP defines lists of things that users can create. Lists can contain references to anything, and these references can be public or private.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 1, kind 30023, kind 34550, kind 40, kind 30009, kind 8 because these are the terms that usually surface as product behavior. Nearby standards: NIP-44, NIP-04, NIP-02, NIP-65, NIP-72.
Calendar Events
This specification defines calendar events representing an occurrence at a specific moment or between moments. These calendar events are addressable and deletable per NIP-09.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 31924, kind 31922, kind 31923, kind 31925, calendar event, event because these are the terms that usually surface as product behavior. Nearby standards: NIP-09.
Live Streaming and Spaces
This NIP introduces event kinds to advertise live spaces and the participation of pubkeys in them.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 30311, kind 1311, kind 30312, kind 30313, kind 10312, kind:30311 because these are the terms that usually surface as product behavior. Nearby standards: NIP-19, NIP-21.
Wiki
This NIP defines kind:30818 (an addressable event) for descriptions (or encyclopedia entries) of particular subjects, and it's expected that multiple people will write articles about the exact same subjects, with either small variations or completely independent content.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 30818, kind 818, kind 30819, kind 10102, kind:30818, content because these are the terms that usually surface as product behavior. Nearby standards: NIP-21, NIP-25, NIP-51, NIP-02.
Android Signer Application
This NIP describes a method for 2-way communication between an Android signer and any Nostr client running on the same device, so that the client never needs to handle the user's private key. The signer is an Android application; the client may be another Android application or a web page.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch kind 1, com.example.signer, nostrsigner, AndroidManifest.xml, user-pubkey, package name because these are the terms that usually surface as product behavior. Nearby standards: NIP-46.
Reporting
A report is a kind 1984 event that signals to users and relays that some referenced content is objectionable. The definition of objectionable is obviously subjective and all agents on the network (users, apps, relays, etc.) may consume and take action on them as they see fit.
Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. Watch kind 1984, kind 1984, content because these are the terms that usually surface as product behavior. Nearby standards: NIP-32.
Badges
Four special events are used to define, award, display and categorize badges in user profiles:
Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. Watch name, width because these are the terms that usually surface as product behavior. Nearby standards: NIP-51.
Gift Wrap
This NIP defines a protocol for encapsulating any nostr event. This makes it possible to obscure most metadata for a given event, perform collaborative signing, and more.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch kind 13, kind 1059, kind 21059, kind 1, relay, content because these are the terms that usually surface as product behavior. Nearby standards: NIP-44, NIP-13, NIP-17, NIP-42, NIP-09.
Static Websites (nsites
This NIP describes a method by which static websites can be hosted from Blossom assets.
Ask whether this object is meaningful outside the original app or only looks like a standard because the app published an event. Watch pubkeyB36, created_at, ["app", "<kind>:<pubkey>:<d-tag>", "<relay>"], <npub>.nsite-host.com, v<snapshotIdB36>.nsite-host.com, <pubkeyB36><dTag>.nsite-host.com because these are the terms that usually surface as product behavior. Nearby standards: NIP-01, NIP-34, NIP-89.
Cashu Wallet
A cashu wallet is a wallet which information is stored in relays to make it accessible across applications.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 17375, kind 7375, kind 7376, kind 5, kind 10019, kind:17375 because these are the terms that usually surface as product behavior. Nearby standards: NIP-61, NIP-44, NIP-09, NIP-65, NIP-40.
Nutzaps
A Nutzap is a P2PK Cashu token in which the payment itself is the receipt.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 10019, kind 9321, kind 7376, event-id-1, kind:10019, kind:9321 because these are the terms that usually surface as product behavior. Nearby standards: NIP-60, NIP-65.
Request to Vanish
This NIP offers a Nostr-native way to request a complete reset of a key's fingerprint on the web. This procedure is legally binding in some jurisdictions, and thus, supporters of this NIP should truly delete events from their database.
Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. Watch relay, .pubkey, .created_at, ALL_RELAYS because these are the terms that usually surface as product behavior. Nearby standards: NIP-09, NIP-59.
Chess (PGN
This NIP defines kind:64 notes representing chess games in [PGN][pgnspecification] format, which can be read by humans and is also supported by most chess software.
Ask whether this object is meaningful outside the original app or only looks like a standard because the app published an event. Watch kind 64, kind:64, .content because these are the terms that usually surface as product behavior.
Relay Discovery and Liveness Monitoring
This NIP defines events for relay discovery and the announcement of relay monitors.
Ask which relay is trusted, what it stores, how it authenticates, how clients discover it and what happens when it is missing. Watch kind 0, kind 10002, relay, content, loki, limitations because these are the terms that usually surface as product behavior. Nearby standards: NIP-11, NIP-52.
EOSE Completeness Hint
This NIP extends the EOSE message defined in NIP-01 with an optional third element that signals the client that the relay has sent every stored event matching the subscription's filters.
Ask what EOSE Completeness Hint changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch EOSE, limit, REQ, until, created_at, until = oldest received event's created_at because these are the terms that usually surface as product behavior. Nearby standards: NIP-01, NIP-11.
Picture-first feeds
This NIP defines event kind 20 for picture-first clients. Images must be self-contained. They are hosted externally and referenced using imeta tags.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch imeta, .content because these are the terms that usually surface as product behavior. Nearby standards: NIP-71.
Peer-to-peer Order events
Peer-to-peer (P2P) platforms have seen an upturn in recent years, while having more and more options is positive, in the specific case of p2p, having several options contributes to the liquidity split, meaning sometimes there's not enough assets available for trading. If we combine all these individual solutions into one big.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch signet, liquid, name, expiration, <tag>, [tag] because these are the terms that usually surface as product behavior. Nearby standards: NIP-40.
Protected Events
A protected event is an event that can only be published to relays by its author. This is achieved by relays ensuring that the author is authenticated before publishing their own events or by just rejecting events with ["-"] outright.
Ask what Protected Events changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? Watch relay, AUTH because these are the terms that usually surface as product behavior. Nearby standards: NIP-42.
Video Events
This specification defines video events representing a dedicated post of externally hosted content.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 1, kind 6000, kind:1, .content, imeta, content-warning because these are the terms that usually surface as product behavior. Nearby standards: NIP-92, NIP-94, NIP-96.
Moderated Communities
Moderated Communities (Reddit Style) ------------------------------------ The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. Watch kind 34550, kind 4550, kind 0, kind 1111, kind 1, kind 6 because these are the terms that usually surface as product behavior. Nearby standards: NIP-29, NIP-22, NIP-09.
External Content IDs
There are certain established global content identifiers such as Book ISBNs, Podcast GUIDs, and Movie ISANs that are useful to reference in nostr events so that clients can query all the events associated with these ids.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch <id, without hyphens>, <id, without version part>, <id, lowercase>, <guid>, <chainId>, <txid, hex, lowercase> because these are the terms that usually surface as product behavior.
Zap Goals
This NIP defines an event for creating fundraising goals. Users can contribute funds towards the goal by zapping the goal event.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 9041, kind:9041, .content, amount, relays, closed_at because these are the terms that usually surface as product behavior.
Negentropy Syncing
This document describes a protocol extension for syncing events. It works for both client-relay and relay-relay scenarios. If both sides of the sync have events in common, then this protocol will use less bandwidth than transferring the full set of events (or even just their IDs).
Ask which relay is trusted, what it stores, how it authenticates, how clients discover it and what happens when it is missing. Watch relay, NEG-CLOSE, EVENT, REQ, closed, closed: you took too long to respond! because these are the terms that usually surface as product behavior. Nearby standards: NIP-01.
Application-specific data
The goal of this NIP is to enable remoteStorage-like capabilities for custom applications that do not care about interoperability.
Ask whether this object is meaningful outside the original app or only looks like a standard because the app published an event. Watch content, tags because these are the terms that usually surface as product behavior.
Forum Threads
Replies to kind 11 MUST use NIP-22 kind 1111 comments. Replies should always be to the root kind 11 to avoid arbitrarily nested reply hierarchies.
Ask whether this object is meaningful outside the original app or only looks like a standard because the app published an event. Watch kind 11, kind 1111, kind 11, kind 1111 because these are the terms that usually surface as product behavior. Nearby standards: NIP-22.
Highlights
This NIP defines kind:9802, a "highlight" event, to signal content a user finds valuable.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 9802, kind 1, kind:9802, .content, <link rel="me" href="nostr:nprofile1..." /> because these are the terms that usually surface as product behavior. Nearby standards: NIP-94.
Trusted Assertions
Certain Webs of Trust calculations require access to a large volume of events and/or computing power, making it virtually impossible to perform them directly on clients. This NIP allows users to offload such calculations to declared trusted service providers, and for these providers to publish signed "Trusted Assertion" events.
Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. Watch kind 30382, kind 30383, kind 30384, kind 30385, <pubkey>, <event_id> because these are the terms that usually surface as product behavior. Nearby standards: NIP-73, NIP-44.
Relay Management API
Relays may provide an API for performing management tasks. This is made available as a JSON-RPC-like request-response protocol over HTTP, on the same URI as the relay's websocket.
Ask which relay is trusted, what it stores, how it authenticates, how clients discover it and what happens when it is missing. Watch Content-Type, supportedmethods, ["<method-name>", "<method-name>", ...], banpubkey, unbanpubkey, listbannedpubkeys because these are the terms that usually surface as product behavior. Nearby standards: NIP-98.
Cashu and Fedimint Discoverability
This NIP describes kind:38173, kind:38172 and kind:38000: a way to discover ecash mints, their capabilities, and people who recommend them.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 38173, kind 38172, kind 38000, kind 0, kind:38173, kind:38172 because these are the terms that usually surface as product behavior. Nearby standards: NIP-01.
Polls
The response event is a kind:1018 event. It contains an e tag with the poll event it is referencing, followed by one or more response tags.
Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. Watch kind 1068, kind 1018, kind 5, kind 30000, kind:1068, kind:1018 because these are the terms that usually surface as product behavior.
Recommended Application Handlers
This NIP describes kind:31989 and kind:31990: a way to discover applications that can handle unknown event-kinds.
Ask whether this object is meaningful outside the original app or only looks like a standard because the app published an event. Watch kind 31989, kind 31990, kind 0, kind 1, kind 31337, kind:31989 because these are the terms that usually surface as product behavior. Nearby standards: NIP-01, NIP-19, NIP-31.
Data Vending Machines
This NIP defines the interaction between customers and Service Providers for performing on-demand computation. The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 5001, kind 6001, kind 5000, kind 6000, kind 7000, kind 5 because these are the terms that usually surface as product behavior. Nearby standards: NIP-04, NIP-89.
Media Attachments Metadata (imeta
Media Attachments Metadata (imeta) ------------------------------------
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch imeta because these are the terms that usually surface as product behavior.
File Metadata
The purpose of this NIP is to allow an organization and classification of shared files. So that relays can filter and organize in any way that is of interest. With that, multiple types of filesharing clients can be created. NIP-94 support is not expected to be implemented by "social" clients that deal with kind:1 notes or by.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 1, kind 30023, kind:1, kind:30023, content, <width>x<height> because these are the terms that usually surface as product behavior. Nearby standards: NIP-96.
HTTP File Storage Integration
This NIP defines a REST API for HTTP file storage servers intended to be used in conjunction with the nostr network. The API will enable nostr users to upload files and later reference them by url on nostr notes. The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 10096, Authorization, payload, expiration, content_type, filename because these are the terms that usually surface as product behavior. Nearby standards: NIP-B7, NIP-98, NIP-94.
Classified Listings
This NIP defines kind:30402: an addressable event to describe classified listings that list any arbitrary product, service, or other thing for sale or offer and includes enough structured metadata to make them useful.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 30402, kind 30403, kind:30402, kind:30403, .content, .pubkey because these are the terms that usually surface as product behavior. Nearby standards: NIP-15, NIP-23, NIP-58.
Voice Messages
This NIP defines new events kind: 1222 for root messages and kind: 1244 for reply messages to be used for short voice messages, typically up to 60 seconds in length.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 1222, kind 1244, kind: 1222, kind: 1244, content, tags because these are the terms that usually surface as product behavior. Nearby standards: NIP-22, NIP-92.
Public Messages
This NIP defines kind 24 as a simple plaintext message to one or more Nostr users.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 24, .content, expiration, nevent1, kind, kind:24 because these are the terms that usually surface as product behavior. Nearby standards: NIP-65, NIP-40, NIP-18, NIP-21, NIP-25.
Web Bookmarks
This NIP defines kind:39701 for a URI as editable web bookmark which uses the HTTP scheme.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 39701, kind 1111, kind:39701, .content, kind 39701, kind 1111 because these are the terms that usually surface as product behavior. Nearby standards: NIP-22.
Blossom
This NIP specifies how Nostr clients can use [Blossom][] for handling media.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 10063, kind:10063 because these are the terms that usually surface as product behavior.
Nostr BLE Communications Protocol
This NIP specifies how Nostr apps can use BLE to communicate and synchronize with each other. The BLE protocol follows a client-server pattern, so this NIP emulates the WS structure in a similar way, but with some adaptations to its limitations. The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask whether this object is meaningful outside the original app or only looks like a standard because the app published an event. Watch EVENT, EOSE because these are the terms that usually surface as product behavior. Nearby standards: NIP-01, NIP-77.
Code Snippets
This NIP defines a new event kind for sharing and storing code snippets. Unlike regular text notes (kind:1), code snippets have specialized metadata like language, extension, and other code-specific attributes that enhance discoverability, syntax highlighting, and improved user experience.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 1, kind 1337, kind:1, kind:1337, .content, name because these are the terms that usually surface as product behavior. Nearby standards: NIP-34.
Chats
A reply to a kind 9 is an additional kind 9 which quotes the parent using a q tag.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 9, kind 9 because these are the terms that usually surface as product behavior.
Geocaching
This NIP defines event kinds for geocaching on Nostr. These events allow users to create, share, and log geocaches in a decentralized manner.
Ask whether this object is meaningful outside the original app or only looks like a standard because the app published an event. Watch kind 37516, kind 7516, kind 1111, kind 7517, kind 37517, name because these are the terms that usually surface as product behavior. Nearby standards: NIP-22, NIP-19.
E2EE Messaging using MLS Protocol
E2EE Messaging using the Messaging Layer Security (MLS) Protocol ---------------------------------------------------------------- The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 445, kind 10051, kind 444, kind 9, kind 7, kind: 445 because these are the terms that usually surface as product behavior. Nearby standards: NIP-04, NIP-44, NIP-17, NIP-59, NIP-70.
Podcasts
This NIP defines how podcast episodes can be fetched from relays. It's intended to fit easily into existing podcast players.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 0, kind 1, kind 10154, kind 10164, kind 54, kind 10054 because these are the terms that usually surface as product behavior. Nearby standards: NIP-51.
Deep reading: where the details become product behavior
NIP-01: Basic protocol flow description
NIP-01 is the base contract: event shape, signatures, filters, client-relay messages and the meaning of tags. Everything else inherits its discipline.
Ask what Basic protocol flow description changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? In the official file, slow down around kind 1, kind 10002, relay, event, event.id, kind:1, content, pubkey. It also touches NIP-10, so do not read it as an island.
The source structure points you toward Events and signatures, Tags, Kinds, Communication between clients and relays. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-05: Mapping Nostr keys to DNS-based internet identifiers
NIP-05 gives a public key a readable internet identifier, but it does not turn identity back into a platform login. The key remains the identity; the domain is evidence.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around "names", <name>, pubkey, "relays", npub, /.well-known/nostr.json?name=<local-part>. It also touches NIP-19, so do not read it as an island.
The source structure points you toward Example, Finding users from their NIP-05 identifier, Notes, Identification, not verification. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-07: window.nostr capability for web browsers
NIP-07 is the browser-signer bridge. It lets a web app request signatures without taking the private key, but the prompt still has to make the signed event legible.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around id, pubkey, sig. It also touches NIP-04, NIP-44, so do not read it as an island.
The source structure points you toward Recommendation to Extension Authors, Implementation. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-11: Relay Information Document
Relays may provide server metadata to clients to inform them of capabilities, administrative contacts, and various server attributes. This is made available as a JSON document over HTTP, on the same URI as the relay's websocket.
Ask which relay is trusted, what it stores, how it authenticates, how clients discover it and what happens when it is missing. In the official file, slow down around relay, Access-Control-Allow-Methods, name, pubkey, max_subid_length, max_limit, limit, max_event_tags. It also touches NIP-17, NIP-01, NIP-09, NIP-13, NIP-42, so do not read it as an island.
The source structure points you toward Name, Description, Banner, Icon. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-17: Private Direct Messages
NIP-17 belongs to the modern private-message stack. It is about delivery, wrapping and metadata reduction as much as encryption.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. In the official file, slow down around kind 14, kind 15, kind 7, kind 13, kind 1059, kind 10050, kind 5, relay. It also touches NIP-44, NIP-59, NIP-42, NIP-21, so do not read it as an island.
The source structure points you toward Chat Rooms, Encrypting, Publishing, Relays. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-19: bech32-encoded entities
NIP-19 makes Nostr pointers human-shareable through npub, nsec, note, nevent, nprofile and naddr forms.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around npub, nsec, nprofile, nevent, naddr, nrelay, relay, author. It also touches NIP-01, NIP-05, so do not read it as an island.
The source structure points you toward Bare keys and ids, Shareable identifiers with extra metadata, Examples, Notes. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-23: Long-form Content
NIP-23 turns long-form work into a portable article object with title, summary, image, tags and addressability.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around kind 30023, kind 30024, kind 1, kind 1111, kind:30023, kind:30024, kind:1, .content. It also touches NIP-37, NIP-19, NIP-27, NIP-21, NIP-22, so do not read it as an island.
The source structure points you toward Format, Metadata, Editability, Linking. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-44: Encrypted Payloads (Versioned
NIP-44 gives encrypted payloads a modern versioned format. It protects content, not every piece of metadata around it.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. In the official file, slow down around kind, created_at, base64 is invalid, hkdf_expand(OKM, info, L), secp256k1_ec_pubkey_tweak_mul, valid.get_conversation_key, valid.get_message_keys, valid.calc_padded_len. It also touches NIP-01, NIP-04, so do not read it as an island.
The source structure points you toward Versions, Limitations, Version 2, Encryption. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-46: Nostr Remote Signing
NIP-46 moves signing away from the app surface and into a remote signer, which changes the trust boundary around every sensitive click.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around kind 24133, kind 4, kind 1, kind 31990, remote-signer-key, remote-signer-pubkey, user-pubkey, sign_event. It also touches NIP-44, NIP-05, NIP-89, so do not read it as an island.
The source structure points you toward Changes, Rationale, Terminology, Overview. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-47: Nostr Wallet Connect
NIP-47 is Nostr Wallet Connect: a permissioned bridge between apps and wallets. It needs budgets, scopes and revocation to stay safe.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. In the official file, slow down around kind 23194, kind 23195, kind 23197, kind 23196, kind 9734, NIP-47 info event, NIP-47 request, NIP-47 notification event. It also touches NIP-04, NIP-44, NIP-57, so do not read it as an island.
The source structure points you toward Rationale, Terms, Theory of Operation, Events. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-57: Lightning Zaps
NIP-57 is the zap standard: Lightning value becomes a signed social receipt attached to a person, note or addressable object.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. In the official file, slow down around kind 9734, zap request, zap receipt, zap, nostrPubkey, relays, content. It also touches NIP-23, NIP-01, so do not read it as an island.
The source structure points you toward Protocol flow, Reference and examples, Appendix A: Zap Request Event, Appendix B: Zap Request HTTP Request. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-65: Relay List Metadata
NIP-65 lets a key publish relay-list metadata so clients can find where a profile reads and writes instead of guessing from defaults.
Ask which relay is trusted, what it stores, how it authenticates, how clients discover it and what happens when it is missing. In the official file, slow down around kind 10002, kind:10002.
The source structure points you toward Size, Discoverability. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-98: HTTP Auth
NIP-98 signs HTTP requests with Nostr keys. It can replace a normal web login for a request, but replay and URL matching must be exact.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around kind 27235, kind 27235, content, method, kind, created_at, payload, ["payload", "<sha256-hex>"].
The source structure points you toward Nostr event, Request Flow, Reference Implementations. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-02: Follow List
A special event with kind 3, meaning "follow list" is defined as having a list of p tags, one for each of the followed/known profiles one is following.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around ["p", <32-bytes hex key>, <main relay URL>, <petname>], .content.
The source structure points you toward Uses, Follow list backup, Profile discovery and context augmentation, Relay sharing. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-03: OpenTimestamps Attestations for Events
OpenTimestamps Attestations for Events --------------------------------------
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around kind 1040, kind:1040, content.
The source structure points you toward Example OpenTimestamps proof verification flow. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-04: Encrypted Direct Message
A special event with kind 4, meaning "encrypted direct message". It is supposed to have the following attributes:
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. In the official file, slow down around kind 4, relay, content, "content": "<encrypted_text>?iv=<initialization_vector>", tags, ["p", "<pubkey, as a hex string>"], ["e", "<event_id>"], AUTH. It also touches NIP-17, so do not read it as an island.
The source structure points you toward Security Warning, Client Implementation Warning. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-06: Basic key derivation from mnemonic seed phrase
Basic key derivation from mnemonic seed phrase ----------------------------------------------
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around m/44'/1237'/<account>'/0/0, account.
The source structure points you toward Test vectors. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-08: Handling Mentions
This document standardizes the treatment given by clients of inline mentions of other events and pubkeys inside the content of textnotes.
Ask what Handling Mentions changes in the event model: does it affect IDs, tags, replies, deletion, counts, filters, URI handling or relay responses? In the official file, slow down around .tags, .content. It also touches NIP-27, so do not read it as an island.
The source structure points you toward the event fields, examples and edge cases. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
What to check before you trust a product claim
Start with the most concrete promise. Does the feature claim portable identity, encrypted messaging, relay discovery, zaps, wallet permissions, long-form publishing, moderation, search or application data? Name the promise before you open the source. Otherwise every NIP starts to look like background reading.
Open the official markdown next. Look for required fields, event kinds, tags, relay messages, status warnings and examples. Do not stop at the title. Many Nostr mistakes happen because a product advertises a NIP number while ignoring the boring edge case that actually protects the user.
Then test another implementation. If the event, payment, list, message, article, badge or relay behavior only works inside one product, the feature may still be useful, but it is not yet a strong portability claim. The second implementation is where the standard stops being a slogan.
Finally, check the risk class. Keys, private messages, money, storage, moderation and identity need more caution than a playful app format. A product can be young and promising, but the page should not ask you to trust it like a mature standard when the source trail is thin.
How this area usually fails
The first failure is overclaiming. A client says it supports a NIP, but it supports only the easiest happy path. That may be enough for a demo and not enough for real use.
The second failure is hidden custody. The app feels convenient because it quietly holds the key, routes the wallet, chooses relays or stores media in a way that makes leaving hard. Nostr is most interesting when those boundaries are visible.
The third failure is stale source material. A guide, blog post or old archive page may describe a version of the ecosystem that changed. The official repository and active implementations matter because Nostr standards are living documents.
The fourth failure is social flattening. Reports, badges, zaps, follows, labels and community events are not neutral numbers. They are signed social signals. You need to know who produced them, who displays them and what the product does with them.
The fifth failure is pretending the protocol solves product judgment. A NIP can define a format. It cannot force a client to explain it well, moderate fairly, store files forever or make a wallet prompt humane. Good pages keep that distinction clear.
Where to go next
The common thread is that a NIP is not a magic wand. It gives independent software a shared object, permission, message, tag, filter or social signal. The product still has to explain what it does with that shared shape.
If you are new to the topic, read the cards first and open only the NIP that matches your immediate question. If you are building, read the official markdown and test against more than one implementation. If you are evaluating a product, ask which parts travel with your key and which parts stay inside the product.
That is the difference between a useful NIP atlas and a numbered archive. The archive tells you that a document exists. The Wissenslexikon tells you why the document changes the way Nostr feels in your hands.
When a NIP touches keys, money, private messages, moderation or storage, slow down. Those are not decorative protocol topics. They decide who can sign, who can pay, who can read, who can hide, who can recover and who can leave.
The best Nostr product writing stays close to those consequences. It does not bury you in acronym soup, and it does not pretend every standard is equally mature. It tells you what you can do next, what you should verify, and where trust enters the room.
Direct sources
Use these sources to verify the text, not as decoration. The official repository is the canonical source; mirrors, guides and project pages help you see how the standard is explained or implemented elsewhere.