NIP

Basics13 min readStandards and compatibility

NIP

NIPs are not marketing badges. They are working agreements about how independent software handles Nostr data.

What NIP means

NIP stands for Nostr Implementation Possibility. The phrase is useful because it avoids the wrong mental model. A NIP is not an app, not a company rule and not a guarantee that every product behaves the same way. It is a shared document that describes how a certain part of Nostr-compatible software can work.

The NIPs repository is the main source for these documents. It covers the base protocol, identifiers, signing interfaces, encryption, wallet flows, zaps, relay behavior, labels, search, long-form content, app handlers and many other patterns. Some NIPs are foundational. Some are widely implemented. Some are experimental, replaced, optional or marked unrecommended.

For a reader, the important point is not to memorize every number. The point is to understand that Nostr grows through small agreements. When enough clients and relays implement the same agreement, a feature can move across products.

Not a mandatory checklist

The NIPs repository itself warns that software is not expected to implement every NIP. That matters. A photo client, a relay, a signer, a wallet and a long-form editor have different jobs. They should not all claim the same standards surface just to look complete.

A good product implements the NIPs that match its role. A web client should care about signing flows and safe key handling. A relay should care about client-relay messages, authentication, storage policy and relay metadata. A wallet app should care about wallet connection and zap flows. A long-form product should care about addressable events and rendering.

This is why the NIPs hub should be read through product consequences, not as a spreadsheet of numbers. The question is always: what does this standard let a user, builder or operator actually do?

Why standards matter

Nostr's base is intentionally small. A public key signs events. Clients publish to and query relays. That tiny base is powerful, but it does not explain every product behavior. Without shared standards, one client might invent one format for a profile, another for a long-form article, another for encrypted messages and another for zaps. The network would splinter into private dialects.

NIPs give the ecosystem a way to coordinate without becoming one platform. They let separate products agree on event kinds, tags, encodings, signing interfaces, encryption methods and relay conventions. A NIP does not need a central app store to matter. It matters when independent software adopts it and users can carry behavior across tools.

That coordination is the quiet reason Nostr can have many clients. Replaceable apps only help if they can read enough of the same data.

The first NIPs a reader should know

NIP-01 is the base. It defines the event structure and the client-relay protocol. If a reader understands nothing else, they should know that this is where signed events, filters and relay messages come from.

NIP-05 connects public keys to DNS-based identifiers. NIP-07 gives browser clients a way to talk to signers. NIP-19 defines bech32 entities such as npub, nsec, note, nevent and naddr. NIP-44 describes versioned encryption for payloads. NIP-46 covers remote signing. NIP-57 defines zap request and receipt flow. NIP-65 helps clients discover relay lists.

Those examples show the range. Some NIPs affect identity. Some affect UX. Some affect privacy. Some affect payments. Some affect discovery. They are not all the same kind of document, which is why every NIP article needs its own explanation rather than generic filler.

Product consequences

The fastest way to understand a NIP is to ask what breaks without it. Without NIP-19, shareable keys and event pointers become harder for people to recognize. Without NIP-07 or NIP-46, many clients fall back to direct private-key handling. Without NIP-65, relay discovery becomes more guesswork. Without NIP-57, zaps are not a shared product pattern. Without NIP-44, modern encrypted payloads lose a common frame.

This is why standards are not abstract bureaucracy. They decide whether a client can open a link from another client, whether a signer can approve a web app action, whether a relay list can travel with a profile, whether a zap receipt can be understood elsewhere and whether a user can switch products without starting from zero.

Good Nostr writing should therefore translate a NIP into reader consequences: what changes for users, builders, operators, clients, relays, wallets and trust.

How to read a NIP

Start with the title and status, then ask which software role the NIP touches. Is it for clients, relays, signers, wallets, event formats or human-readable references? Then look for event kinds, tag conventions, request and response messages, security warnings and implementation notes. Finally ask whether the NIP is widely used or mostly experimental.

The mistake is to treat every NIP number as equally important. NIP-01 is foundational. NIP-05 is user-facing identity. NIP-07 and NIP-46 affect key custody. NIP-57 affects payments. Some others are niche or historical. A reader needs a map, not a number memorization exercise.

This is also why the Crays NIPs route explains standards through use cases. A protocol document may be precise, but the wiki page needs to tell the reader why that precision matters.

Limits and fair criticism

NIPs do not automatically create good products. A client can claim support for a standard and still implement it poorly. A standard can be too early, too narrow or replaced by better practice. A feature can be technically compatible while still confusing for ordinary users. Some NIPs encode old assumptions that the ecosystem later moves away from.

The open standards model also creates reading friction. There are many documents, uneven adoption and a lot of protocol vocabulary. That is why a large Nostr wiki should not dump the raw NIP list and call the job finished. It should explain which NIPs matter, where they are implemented, what they changed and where the rough edges remain.

The reader-level memory is this: NIPs are shared implementation agreements. They are how Nostr avoids becoming one app while still letting many apps understand the same network.

A NIP also has a lifecycle. Some begin as drafts because builders are still testing the shape. Some become widely used because clients and relays converge around them. Some are optional by nature because they apply only to certain products. Some are marked unrecommended when the ecosystem learns that the older pattern is unsafe, confusing or superseded. A reader should therefore care about status and adoption, not only the number.

The numbers can also create false importance. A low number is not always the feature a particular user needs today, and a high number is not automatically marginal. The useful reading order depends on the question. If the question is identity, open NIP-05 and NIP-19. If it is web signing, open NIP-07. If it is remote signing, open NIP-46. If it is relays and discovery, open NIP-65. If it is zaps, open NIP-57. If it is private messages, the encryption and gift-wrap NIPs matter quickly.

Implementation evidence matters as much as the standard text. A NIP can be elegant and still barely used. Another can be messy but widely adopted because it solved a real product problem early. Good wiki writing should therefore connect NIPs to clients, relays, wallets, SDKs and repositories. Which apps use it? Which libraries support it? Which failure mode does it address? Which old behavior does it replace?

Security warnings deserve special care. A NIP that touches signing, encryption, wallet permission, relay authentication or private messages is not only a compatibility note. It changes risk. A good explainer should say what the standard protects, what it does not protect and which product decisions still matter. For example, a signing NIP can keep the raw key away from a website, but a confusing approval prompt can still train the user to sign blindly.

Event kinds are another place where standards become practical. A kind number tells clients what sort of event they are looking at. Profiles, notes, contact lists, long-form articles, reactions, relay lists and wallet-related messages are not the same shape of data. If clients agree on the kind and tags, they can render the event meaningfully. If they do not, the event may degrade into an unknown object.

The most useful NIP articles therefore translate structure into behavior. A tag is not just a tag; it may identify a referenced event, a public key, a relay hint, a subject, a hashtag, a coordinate or a payment target. A relay message is not just JSON; it decides how a client asks for data. A signer method is not just an API; it decides where key custody sits.

Readers should also know when to leave the NIP page. If a standard is mentioned inside an app article, open the app and see how it behaves. If a relay claims support, inspect the relay metadata and test with a client. If a wallet flow depends on a NIP, test with tiny amounts first. Standards explain the possible agreement; products reveal the lived agreement.

This is why the NIPs shelf belongs beside Basics, Apps, Relays, Wallets and Privacy. It is the connective tissue between protocol text and product reality. The right question is never "which number sounds important?" The right question is "what can independent tools do together because this agreement exists?"

There is also a social process behind NIPs. Developers propose changes, argue in issues and pull requests, test implementations and sometimes revise the text when real products expose edge cases. That process is lighter than a formal standards body, which fits Nostr's culture, but it also means readers should look at repositories, discussions and implementation trails when a NIP is important to a claim.

A NIP page should therefore link to more than the raw document when the ecosystem evidence exists. GitHub history can show who proposed or changed a standard. Client repositories can show adoption. Relay software can show support. Wallet documentation can show how a payment flow is presented to users. Without those links, the article risks treating standards as abstract scripture instead of living engineering agreements.

Compatibility also has layers. Two clients can both support the same NIP and still disagree on defaults, presentation, edge cases or user warnings. One may support reading but not writing. Another may support writing but not all tags. Another may support the standard only behind an experimental setting. The label "supports NIP-X" should invite inspection, not end it.

Deprecation and replacement are part of the story. Some older direct-message patterns are still visible because old clients and data exist, while newer encrypted approaches are safer or more current. Some event kinds remain in the wild even when better patterns appear. A reader needs to know whether a NIP describes the future path, legacy compatibility or an experiment that never became normal.

For app comparisons, NIPs give useful but incomplete evidence. A client that supports NIP-07 may still train users badly if the signing UI is vague. A relay that supports NIP-42 may still have unclear policy. A wallet flow that supports NIP-47 may still request broad permissions. A media app that uses file metadata may still depend on fragile storage. Standards are necessary; product taste and operational honesty finish the job.

For builders, the healthy habit is to start from the user outcome. Do you need a human-readable identifier, relay discovery, remote signing, encrypted payloads, wallet connection, app handler, long-form article or content label? Then read the relevant NIP and inspect how working products use it. Implementing a NIP because it exists is weaker than implementing it because it solves a visible interoperability problem.

For readers, the healthy habit is to translate every NIP number into a plain sentence. NIP-05 helps names point to keys. NIP-07 helps web apps ask signers instead of taking raw keys. NIP-19 makes keys and event pointers shareable. NIP-57 makes zaps legible. NIP-65 helps clients find relays. Once the number becomes a sentence, the standards shelf becomes much less intimidating.

The deeper promise is that NIPs let Nostr remain unfinished without becoming incoherent. Builders can experiment, but successful patterns can become shared. Products can differ, but they do not have to start from zero. Users can move, but only when enough tools agree on what the movement means. That is why standards deserve real articles, not one-line definitions.

NIPs also help separate protocol facts from ecosystem habits. A client may popularize a feature before the standard is stable. A relay may support an extension before most clients care. A wallet flow may become common because one strong implementation made it feel easy. The standard can then capture the useful shape, or the ecosystem may decide the experiment should remain local. That back-and-forth is normal in a young protocol.

The danger is pretending that every draft is settled truth. A draft can be useful evidence, but it should be presented with its uncertainty. Readers deserve to know whether they are looking at a canonical base, a widely used optional convention, a niche implementation pattern or a proposal that mainly matters to developers. The word "standard" should not be used lazily.

Some NIPs are best read alongside code. NIP-07 makes more sense when you inspect browser signers and web clients. NIP-46 makes more sense when you see bunker URLs, remote signer sessions and permission prompts. NIP-47 makes more sense when you test an NWC wallet connection with small amounts. NIP-65 makes more sense when you watch clients discover where someone writes. Standards become clearer when behavior is visible.

Other NIPs are best read historically. They show how Nostr moved from a simple public-note model toward encrypted messages, long-form publishing, wallets, app handlers, labels, file metadata and relay discovery. That history matters because it explains why the ecosystem can feel uneven. Newer standards often coexist with older events, older clients and older habits.

For maintainers, NIP adoption creates support obligations. If a client publishes a certain event kind, users will expect other clients to understand it. If a relay advertises support for a standard, clients will build assumptions around it. If a wallet implements a permission flow, users will trust the spending boundary. A NIP is not just documentation; it becomes a promise when software ships it.

For users, the practical question is always smaller than the standards list. Do I need a name people can verify? Do I need a safer signer? Do I need a link that another app can open? Do I need zaps? Do I need relay discovery? Do I need private messages that use current encryption practice? Follow that need to the relevant NIP instead of trying to swallow the whole repository at once.

This page is the entry point, not the final map. The NIPs hub should carry the reader from this mental model into individual standards, implementation links, GitHub history, app examples, relay behavior and honest caveats. That is how a standards shelf becomes useful to people who are not protocol maintainers.

It also keeps the rest of the wiki honest. When an app claims safer signing, the relevant signer NIPs should be nearby. When a wallet claims Nostr Wallet Connect, the wallet standard should be linked. When a relay claims discovery support, the relay-list standard should be visible. The standards page is the bridge between product language and checkable source material.

The reader should leave with patience rather than overwhelm. Nostr standards are many because the ecosystem is trying to make many independent tools cooperate. The first job is not to master every document. It is to know that these agreements exist, that they have statuses and tradeoffs, and that each serious product claim should be traceable back to one or more of them.

Sources worth opening