NIP-01: Basic protocol flow description
The floor under every other NIP
NIP-01 is not the glamorous part of Nostr. That is exactly why it matters. It is the document that says what an event is, how an event gets its ID, how it is signed, how a relay receives it and how a client asks for it back. Without this shared floor, Nostr would be a collection of apps that all liked public keys but could not reliably read each other.
The Nostr design is intentionally sparse: a user has a keypair, software signs events, relays move those events around, and clients decide what to show. NIP-01 is where that simplicity becomes precise enough to implement. It defines the event object on the wire, the serialization rules that produce the event ID, the standard tag conventions, kind ranges, subscription filters and the message types between clients and relays.
That makes NIP-01 a product document as much as a protocol document. When a user opens a client and sees posts from multiple relays, that visible experience depends on tiny rules here: whether timestamps are filtered inclusively, whether duplicate subscriptions replace each other, whether a relay sends an OK message after an EVENT, and whether a client can index references through tags.
The event object, the relay conversation and the shape of compatibility
The core object is the event. NIP-01 gives it seven fields: id, pubkey, created_at, kind, tags, content and sig. The ID is not an arbitrary database key; it is the SHA-256 hash of a strict serialized array. That detail is unforgiving. If two libraries serialize the same human-visible event differently, they produce different IDs and the network loses agreement.
The signature model is equally central. NIP-01 uses Schnorr signatures on secp256k1, following BIP-340. A signed event is therefore not just a post; it is a portable statement by a key. Other NIPs can add encryption, wallet requests, file metadata, lists or moderation signals, but they inherit this signed-event base.
Tags are the second quiet power of NIP-01. The standard defines the general e, p and a tag conventions: references to events, people and addressable or replaceable events. It also says single-letter tag keys are expected to be indexable by relays. That expectation is why clients can ask for events that mention a person, reply to an event or point at a long-form article without every app inventing a new search API.
The relay conversation is deliberately small. Clients send EVENT, REQ and CLOSE. Relays answer with EVENT, OK, EOSE, CLOSED and NOTICE. The power is not in the vocabulary; it is in the fact that independent relay and client authors can implement the same few messages and still build very different products.
A living base layer, not a frozen postcard
The visible NIPs repository history starts with fiatjaf migrating the NIPs out of the main Nostr repository on May 1, 2022. NIP-01 has stayed active since then because the base layer keeps absorbing lessons from real clients and relays. That history matters: a mandatory standard can still be draft when the ecosystem keeps finding edge cases in production.
Several changes are worth reading as protocol archaeology. In July 2023, issue discussion around since and until showed that relay implementations disagreed about boundary behavior; the current text now makes the inclusive rule explicit. In 2024 and 2025, contributors clarified tag filters, addressable events, replaceable event tie-breaking, relay connection behavior, relay tags and the meaning of limit. Those are not decorative edits. They are places where small ambiguity creates real interoperability bugs.
The contributor trail also shows NIP-01 as a shared maintenance object. Names visible in recent file history include fiatjaf, sandwich, mattn, Vincenzo Imperati, Vitor Pamplona, Alex Gleason, Jon Staab, Arjen Stens, Arman The Parman, hodlbod and others. That does not mean each person authored the protocol. It means the standard has been shaped by people finding sharp edges while clients and relays became more serious.
Where NIP-01 becomes real software
Every serious Nostr library has to internalize NIP-01. In JavaScript that means libraries such as nostr-tools and NDK. In Rust it means rust-nostr and relay code such as nostr-rs-relay or strfry. In Go it means go-nostr. The names differ, but the test is the same: can the software construct, sign, verify, filter and exchange events in a way other implementations understand?
The difficult parts are rarely the headline fields. They are the boring corners: exact lowercase hex, JSON serialization, tag indexing, subscription replacement, EOSE handling, duplicate events, machine-readable OK/CLOSED prefixes, replaceable event tie-breaking, and how far a relay goes beyond the minimum. A client that only works against one friendly relay has not really proven its NIP-01 implementation.
For Crays, NIP-01 is the page to read before judging any higher-level feature. Zaps, wallet connect, private messages, long-form articles, communities, lists and media metadata all return here. If the event foundation is misunderstood, everything above it looks more stable than it is.
The risk is not complexity; it is hidden disagreement
NIP-01 is small enough to read in one sitting, but it is broad enough to punish sloppy assumptions. The biggest risk is hidden disagreement: a relay accepts something one way, a client queries another way, and the user only sees missing data. Because relays are autonomous, the standard can guide behavior but cannot force identical policy.
The draft status is also important. It does not mean the whole protocol is immature nonsense. It means the base layer is still being clarified as the network grows. That is normal for a live open protocol, but people needs to treat NIP-01 as a living source, not a one-time lesson memorized in 2022.
Read NIP-01 in the wild
Open NIP-01 when you want to know what every Nostr product is allowed to assume. The file defines the event shape, signature rule, client-to-relay messages, filters and relay responses that make a signed note, profile update, zap request or long-form article recognizable outside one app. That is why this page is less a beginner lesson than a floor under the whole network.
The real implementation test is boring and strict: does the same event verify, query and render across independent clients and relays? If a product only works because one relay is forgiving or one library normalizes mistakes, it is already drifting away from Nostr's shared language.
What changes when you actually use it
For you, NIP-01: Basic protocol flow description is felt when an app either behaves predictably or suddenly loses context. The visible symptom may be a missing reply, a broken link, a strange reaction count, an empty result or a relay error that looks like the whole network failed. The official terms kind 1, kind 10002, draft, relay, event, event.id are where that visible behavior begins, so the source is not background material; it is the place where the product promise gets its limits.
What changes for builders and operators
For builders, NIP-01: Basic protocol flow description is compatibility discipline. Implement kind 1, kind 10002, draft, relay, event, event.id against more than one relay and more than one library, then test malformed, missing and duplicated data. Core standards fail most painfully when the happy path looks fine and the second client exposes the shortcut.
What the official file makes concrete
The official file is organized around Events and signatures, Tags, Kinds, Communication between clients and relays, From client to relay: sending events and creating subscriptions, From relay to client: sending events and notices. Inspect kind 1, kind 10002, draft, relay, event, event.id, 0x0A, 0x0D because these are the pieces most likely to surface as product behavior. Read it beside NIP-10 before treating it as isolated.
NIP-01: Basic protocol flow description is a shared contract between independent software. The smallest field can become user-visible when two clients disagree about it.
Where it breaks
The failure mode in NIP-01: Basic protocol flow description is often indirect. Nobody complains about kind 1, kind 10002, draft, relay, event, event.id; they complain that the feed is wrong, the reply vanished or the relay behaved strangely. Use the official file to diagnose the hidden cause instead of patching only the visual symptom.
Where this appears outside the markdown
In the ecosystem, NIP-01: Basic protocol flow description is not something most people choose directly. It is the invisible grammar behind clients, relays, crawlers, search tools and archives. When a product team treats kind 1, kind 10002, draft, relay, event, event.id as implementation detail only, the mistake eventually reaches the surface as missing history, bad threading or state that cannot be reconstructed after a client switch.
The nearby-standard trap
The nearby-standard trap in NIP-01: Basic protocol flow description is assuming the base layer solves the higher-level feature. This NIP may define the common grammar, but publishing, wallets, moderation, media or groups still need their own constraints. Read NIP-10 to see where the base contract ends and the product-specific promise begins.
Language that keeps the feature honest
Good product copy for NIP-01: Basic protocol flow description does not say "the protocol handles it" and move on. It explains the visible consequence: what was sent, what was accepted, what was rejected, what is still loading and what another relay or client may show differently.
What this page does not promise
NIP-01: Basic protocol flow description does not promise a finished social product. It gives software a shared grammar. Feed design, moderation, ranking, notifications, storage duration and recovery remain separate product decisions. That distinction matters because a client can be technically compatible and still give you a weak experience if it hides relay errors, drops context or treats optional fields as if every app understood them.
Read it as a field test
Start NIP-01: Basic protocol flow description with the visible product symptom, then trace it back to kind 1, kind 10002, draft, relay, event, event.id. That order keeps the article grounded: you see why the field exists, which relay or client behavior depends on it, and where adjacent standards change the story. A core NIP is strong only when it explains both the normal path and the awkward edge case.
Where the standard earns trust
The source links give you places to test the interpretation in public: Issue #650: since/until semantics, nostr-tools, NDK, rust-nostr. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-01 source is the anchor for exact wording, and NIP-01 commit history shows how that wording moved over time. The strongest secondary clues here are Issue #650: since/until semantics, nostr-tools, NDK. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-01: Basic protocol flow description: first the human promise, then kind 1, kind 10002, draft, relay, event, event.id, then the implementation record, then the real-world failure case. That order keeps NIP-01 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can two independent clients read the same
kind 1,kind 10002,draft,relaywithout a hidden compatibility rule? - Does the UI explain relay rejection, missing context or state replacement without blaming the whole network?
- Which adjacent standard, especially NIP-10, changes the behavior once the base event leaves the happy path?
What to verify before you rely on it
- Find
kind 1,kind 10002,draft,relay,eventin the official file and check where the UI exposes the same concept. - Read NIP-10 as context before treating NIP-01 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-01: Basic protocol flow description in that order: Official NIP-01 source for the current wording; NIP-01 commit history for the change record; Issue #650: since/until semantics, nostr-tools, NDK for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
