NIP (Nostr Implementation Possibility)

A NIP, or Nostr Implementation Possibility, is a specification document describing how a particular feature of the Nostr protocol should work. NIPs are the agreed-upon standards that let independently written clients and relays interoperate: any developer can build a Nostr app from scratch, and if it follows the relevant NIPs, it will speak fluently with software written by strangers. They are roughly analogous to Bitcoin's BIPs — community-maintained documents that keep a decentralized network coherent without any central authority dictating the rules. The name itself is a quiet statement of philosophy: not "requirements" or "standards" but possibilities — things an implementation may choose to support.

NIP-01: the mandatory core

All of Nostr rests on one document. NIP-01 defines the basic protocol flow: the event — a signed JSON object with a public key, timestamp, kind number, tags, and content — plus the ID and Schnorr-signature scheme that makes every event self-authenticating, and the WebSocket messages clients and relays exchange to publish events and subscribe to filtered streams. NIP-01 is the only truly mandatory specification; everything else is optional extension. Because every event is signed by its author and verifiable by anyone, the network needs no accounts and no gatekeeper — a relay that misbehaves can be dropped and replaced without losing identity or data.

The extension ecosystem

Beyond the core, numbered NIPs specify features an implementation may adopt. A few landmarks show the range: NIP-05 maps human-readable, domain-based names to public keys (see NIP-05 identifier); NIP-19 defines the bech32 encodings behind npub and nsec keys; NIP-57 specifies Zaps, the Lightning Network payments attached to notes; NIP-07 lets a browser extension sign events so websites never touch your private key; and NIP-44 defines the encryption used for private payloads. Event kind numbers — the namespace that says whether an event is a profile, a note, a reaction, or something new — are catalogued across NIPs (see Nostr event kind). Clients and relays advertise which NIPs they support, and the protocol degrades gracefully: unknown kinds are simply relayed or ignored rather than breaking anything.

Rough consensus, running code

NIPs live in a public repository where anyone can propose one; adoption — not authority — decides what becomes standard. A NIP matters when multiple implementations ship it, and a NIP nobody implements is just a document. This keeps evolution honest: a feature must convince independent developers on its merits, and no company can force a change on the network. It is the same rough-consensus model that has kept Bitcoin's protocol stable and permissionless for over a decade, applied to social communication. The trade-off is familiar too — progress can be slower and messier than a platform shipping features by decree, and competing NIPs sometimes overlap until usage settles the question. Numbering is not hierarchy, either: NIP-01 is foundational because everything depends on it, not because a committee ranked it first, and ideas that lose relevance simply fall out of use rather than being formally repealed. That is the cost — and the resilience — of a protocol nobody owns.

Why it matters for sovereignty

For a sovereignty-minded user, NIPs are the guarantee that Nostr remains an open protocol rather than a product. Your identity is a keypair, your data is signed events, and the rules for both are public documents — so no client lock-in, no platform that can deprecate your account, and an exit that is always one implementation away. Anyone — including a small Canadian shop like D-Central — can read the NIPs and build or self-host compatible tooling without permission. Learn more about the broader self-hosted stack in D-Central's digital sovereignty hub.