Nostr NIPs explained: the protocol's specification documents

Nostr's evolution happens through NIPs, short specification documents anyone can propose. If you want to understand how new features like zaps or encrypted DMs get into the protocol, NIPs are the answer.

This guide covers what NIPs are, how they work as a governance mechanism, and which ones to read if you are getting technical.

NIPs are short markdown documents on GitHub that propose how to implement Nostr features. Client developers choose which to support. A NIP becomes "real" when enough implementers adopt it. The core set of widely-used NIPs is about 30; the full list is closer to 100.

When you are ready, grab your @nostr.blog address →

What a NIP actually is

A NIP is a markdown file in the github.com/nostr-protocol/nips repository. Each file describes a specific feature, format, or convention: how to sign events, what a profile metadata event looks like, how to send a direct message, what format Lightning zap requests use.

Size varies. The shortest NIPs are under a page; the longest are several thousand words. Most sit around 500 to 2000 words. They are written to be implementable from the spec alone, so they include message formats, required fields, and example events.

The naming convention is NIP-XX where XX is a number. Numbers are assigned when the NIP is merged; they do not reflect priority or importance. NIP-05 is about verified identifiers; NIP-04 is the older DM standard; NIP-01 is the core protocol. The numbers track proposal order, not feature significance.

Why "Implementation Possibilities"

The name is a deliberate choice. Compare with other specification traditions.

• RFCs (Requests for Comments) in internet protocols often end up mandatory for interoperability.
• EIPs (Ethereum Improvement Proposals) often become mandatory via network upgrade.
• NIPs are permanently optional. A client that implements 40 NIPs and a client that implements 10 are both valid Nostr clients; they just do different subsets of things.

This means NIPs never "break" existing implementations. A new NIP for some feature does not force older clients to change. The protocol grows at the edges while the core stays stable.

The NIP lifecycle

How a new NIP comes into existence:

1. Someone notices a gap or need. "We have no standard way to do X." Could be a client developer, a relay operator, or a user frustrated with a specific issue.
2. They write a draft. Format follows the existing NIPs: title, purpose, specification, examples.
3. They submit a pull request to the NIPs repository.
4. Community reviews. Developers, relay operators, and interested users comment. The draft gets revised based on feedback.
5. Merge or abandon. Merged NIPs get a number and become part of the repository. Abandoned drafts sit in the pull request history.
6. Implementation follows (or does not). Some NIPs are implemented within weeks. Some wait years. Some never get implemented widely.

The process is lightweight. No committee votes, no formal approval. If the pull request gets broadly positive feedback and addresses an obvious need, it gets merged.

NIPs that matter if you are a user

Most NIPs are invisible to users. A handful affect your daily experience:

• NIP-01: Core protocol. How events are structured and signed. You never see it, but everything else depends on it.
• NIP-05: Verified identifiers. Gives you you@domain.com readable names. Our NIP-05 guide covers it.
• NIP-07: Browser extension signing. Lets web clients sign without seeing your private key.
• NIP-19: Bech32 encoding. Why your public key looks like npub1... instead of raw hex.
• NIP-23: Long-form articles. Enables blog-style posts on Nostr.
• NIP-44: Encrypted DMs. The modern direct messaging standard (better than the older NIP-04).
• NIP-57: Zaps. Lightning tips with public receipts.
• NIP-98: HTTP auth. Lets Nostr identities authenticate to regular websites.

As a user you benefit from all of these without interacting with them. Clients handle the protocol details.

NIPs that matter if you are a developer

If you are writing or maintaining a Nostr client, the NIPs worth reading grow into dozens:

• NIP-01 through NIP-10 (core mechanics).
• NIP-11 (relay information documents).
• NIP-13 (proof of work, for spam resistance).
• NIP-17 (gift-wrapped DMs for metadata hiding).
• NIP-22 (event expiration).
• NIP-27 (text note references).
• NIP-30 (custom emoji).
• NIP-31 (event kinds).
• NIP-33 (parameterized replaceable events).
• NIP-42 (authentication of connections to relays).
• NIP-47 (Nostr Wallet Connect).
• NIP-50 (search capability).
• NIP-65 (relay list metadata).
• NIP-78 (arbitrary custom app data).

These are the ones most mainstream clients implement. A client that supports this set plus the user-facing NIPs above covers 95% of typical use.

Reading a NIP

If you want to read one directly, the repository is at github.com/nostr-protocol/nips. The structure of most NIPs:

• Title and description. What the NIP proposes.
• Motivation. Why the feature is needed.
• Specification. Exact message format, required fields, validation rules.
• Example events. Concrete JSON showing what a conforming event looks like.
• Client/relay behavior. How implementations should handle the events.

NIPs are written to be readable by developers implementing them. The specification section is the important one; it is where the actual protocol lives.

NIPs with partial adoption

Some NIPs exist but are inconsistently implemented across clients. This creates edge cases where your experience varies by client.

NIP-44 (encrypted DMs). Adopted by Damus, Primal, Amethyst, and most major clients in 2024-2025. Some older clients still only support NIP-04. If you DM someone whose client supports only NIP-04, your NIP-44 messages to them fail silently. The practical answer: use a modern client and hope your correspondent does too.

NIP-17 (gift-wrapped DMs). Metadata-hiding DMs. Adoption in 2026 is growing but not universal. The feature is great where both parties' clients support it; otherwise it silently falls back to less-private DMs.

NIP-46 (remote signers). Lets a hardware signer or bunker app sign events on behalf of a client. Supported in Amethyst, partial elsewhere.

NIP-65 (user's relay list). Lets users publish their preferred relays so clients can automatically route to the right places. Adoption is improving; older clients ignore it.

NIP-50 (search). Allows clients to query relays for text matches. Some relays support it; many do not. Search quality is inconsistent as a result.

Checking which NIPs a given client supports is a useful diagnostic when something does not work as expected. Most clients publish their NIP support matrix in their documentation.

How the NIP process keeps the protocol coherent

No central authority, so coherence comes from social dynamics. A few observations:

Bad NIPs do not propagate. A proposal that duplicates an existing NIP or solves the wrong problem gets minimal adoption and quietly dies. The community is not formal but is opinionated.

Good NIPs get implemented independently. Multiple client developers read proposals and decide independently. Good ideas accumulate adopters; bad ideas do not.

Competing NIPs sometimes emerge. Two different proposals for the same feature can coexist for a while. Usually one wins in practice because more clients implement it; sometimes they merge.

Fork-compatible evolution. Because NIPs are optional, a client can implement NIP-X-v1 and later upgrade to NIP-X-v2 without breaking anyone who only supports v1. The protocol does not split.

This is messy but functional. The protocol has evolved significantly in five years without a central governance body because the social mechanism of "implementers read, implementers decide, implementers code" has enough alignment to produce coherence.

Proposing your own NIP

If you have an idea for a new Nostr feature:

1. Check the NIPs repository first. Someone may have already proposed it.
2. If not, open a GitHub issue describing the problem you are solving.
3. Based on feedback, draft a full NIP following the existing format.
4. Submit a pull request.
5. Engage in discussion. Be willing to revise.
6. If it gets merged, great. If it does not, the problem may have a better solution; consider why.

Not every good idea becomes a NIP. Not every NIP becomes a feature. The ecosystem has more proposals than any single developer could track, and the filter is "does enough of the community implement it." That filter is the core of how Nostr stays coherent without being top-down.