Nostr Agent Onboarding · start here · index · source: Nostr-exp/core/01-what-nostr-is.md · snapshot 2026-10-10

What Nostr is

Part 1 of the core synthesis. Read this first. Sources: NIP-01 (../sources/nip-01.md), Hodlbod's Building Nostr (../sources/hodlbod-book.md), fiatjaf's essays (../voices/fiatjaf/), and the NIPs registry (../sources/nips-readme-kinds.md).

The one-sentence version

Nostr — Notes and Other Stuff Transmitted by Relays — is an open protocol in which users sign JSON events with their own cryptographic key and publish them to any number of dumb, interchangeable servers called relays. That is the whole protocol. Everything else is convention layered on top.

The load-bearing move: signatures decouple authentication from storage

On the legacy internet, knowing that "person X said Y" requires trusting the server that stores Y. Data that is not cryptographically signed is tightly coupled to custody: only the platform can attest to its authenticity, which is exactly what makes the platform indispensable — and exactly what lets it censor, surveil, and lock users in.

Nostr's single architectural move is to break that coupling. A Nostr event carries its author's public key, a hash of its own contents (id), and a Schnorr signature over that hash. Anyone can verify it; nobody can forge it; and — crucially — it does not matter where you got it from. An event is equally valid coming from a relay, an email attachment, a USB stick, or a carrier pigeon. In Hodlbod's formulation: digital signatures decouple data storage from authentication.

Three consequences fall out, and together they are the protocol's entire value proposition:

1. Identity is user-generated. An identity is a secp256k1 keypair you mint yourself (npub…/nsec… in bech32 form). No registration, no issuer, no one who can revoke it.
2. Relays are interchangeable mirrors, not authorities. Any relay can drop you; none can silence you, because your followers can fetch the same signed events from any other relay — or from you directly.
3. Clients are replaceable views. Because data and identity live outside any application, users have credible exit: leave a client and you keep your identity, your data, and your whole social graph. Interoperability is not a feature of Nostr apps; it is the point of them.

Note a live difference in emphasis between the principals here. Hodlbod's framing (above) is key-centric: signatures are the move, relays are downstream. fiatjaf inverts it: keys on their own are "meaningless" — "having a key is meaningless if you cannot publish messages to where the people you're trying to reach can read them" — and the actual invention is clients talking to many independent, mutually-distrusting servers at once. On his account the keys exist to make that multi-relay architecture safe, not the other way around. Both framings agree on every practical consequence; keep both in your head, because each catches mistakes the other misses (key-worship without reach; relay-craft without verifiable data). See ../voices/fiatjaf/.

The event: one data type for everything

Everything on Nostr is an event:

{
  "id":         "<sha256 of the serialized event>",
  "pubkey":     "<author's public key, hex>",
  "created_at": 1682377261,            // unix seconds, author-asserted
  "kind":       1,                     // 16-bit integer content type
  "tags":       [["p", "<pubkey>"], ["e", "<event-id>", "<relay-hint>"]],
  "content":    "usually human-readable text",
  "sig":        "<schnorr signature of id>"
}

Design decisions embedded in this shape, all deliberate:

• Kinds are numbers, not names. In a system built on signed, immutable data, names can never be renamed — and names smuggle in meaning that varies by reader. Integers are meaningless, so usage determines meaning, the way natural language works. The registry of kinds (see ../sources/nips-readme-kinds.md) is a dictionary written after the fact, not a schema enforced up front.
• Tags are the data model. content is for humans; structured data goes in tags — a list of string-lists, ordered, with repeatable keys. Single-letter tags (e, p, a, d, t, …) are indexed by relays and therefore queryable; multi-letter tags are payload only.
• Timestamps are author-asserted and second-granularity. Nostr punts on distributed time on purpose: there is no ordering authority, and pretending otherwise (with millisecond precision, say) would be a lie. If you need provable time, anchor externally (NIP-03 / OpenTimestamps); otherwise the social layer — reputation — handles dishonest clocks.
• The event id is a content hash, which makes regular events referentially transparent: if you hold an id, the content can never change under you.

Kind ranges: the storage contract

The kind number also selects the relay's storage behavior — the one place where behavior and data got coupled (Hodlbod considers this a design wart, but it is load-bearing today):

Addressable events are referenced by address (kind:pubkey:d-tag, encoded as naddr…) instead of by id, because their content is expected to change. The trade-off is real: replaceability discards history and invites race conditions when two clients update the same event concurrently. Default to regular unless you can say in writing why throwing information away is correct. (More in 04-how-to-design.md.)

Relays: easy, dumb, and plural

A relay is a WebSocket server that stores events and answers queries. The full protocol surface is a handful of verbs:

• Client → relay: EVENT (publish), REQ (subscribe with filters), CLOSE
• Relay → client: EVENT (deliver), OK (accept/reject), EOSE (end of stored events), CLOSED, AUTH (NIP-42 challenge)

A filter matches on ids, authors, kinds, since/until, limit, and indexed tags (#e, #p, #t, …). That's the entire query language. Anything fancier — full-text search (NIP-50), counting, analytics — is a per-relay extension, not the protocol.

Relays are "easy," not "simple" (Rich Hickey's distinction): WebSockets over HTTP over TCP is a boring, gate-kept stack — but it is deployable by anyone this afternoon, and that is the property that matters. Because the interface is minimal, there are hundreds of independent relay implementations and thousands of running relays, and none of them is special.

What relays legitimately do beyond storage:

• Curation and access control (via NIP-42 AUTH): a relay may serve one community, one topic, paying members, or a single user. This makes relays services with intent, not commodity infrastructure — and that is a feature. A relay with no distinctive value proposition has no business model, and unfunded infrastructure re-centralizes.
• Transport brokering: because a relay is a publicly addressable mailbox, two programs can talk through one by exchanging (usually encrypted, often ephemeral) events. This is how remote signers (NIP-46), wallets (NIP-47), and data vending machines (NIP-90) work — services addressed by pubkey instead of IP address.

NIPs: the protocol is descriptive, not prescriptive

Protocol extensions are documented in NIPs — "Nostr Implementation Possibilities" — curated at https://github.com/nostr-protocol/nips. The governing norms:

• Implementation first. A NIP documents what running code already does; the repo requires interoperating implementations before merging. Anyone can ship a new kind tomorrow without asking permission — adoption, not approval, decides what becomes "the protocol."
• Specs are written for humans. Brief, readable, hackable — the opposite of standards-body prose.
• "There should be no more than one way of doing the same thing." An ideal, not a law — but the burden of proof is on the person diverging.

This is what Building Nostr calls radical openness: the protocol is defined by its implementations, standardization is discovery rather than invention, and the messiness (overloaded tags, race-prone replaceables, half-baked NIPs) is the accepted cost of a protocol no company can capture. Nostr is the JavaScript of protocols: hacked together, full of warts, alive.

Even the NIP process itself is contested from within: fiatjaf's 2025 essay "The end of NIPs" proposes dissolving the repository into a bare kind-number registry plus competing prose guides, on the grounds that spec bureaucracy confers unearned "officialness," lets dead ideas linger, and — worst — trains developers to translate event schemas into UI while skipping the actually hard part, relay choice. Whether or not the repo survives, take the diagnosis seriously: the registry function (don't collide on kinds) is the essential part; the prose is commentary.

What Nostr is not

• Not a blockchain. No consensus, no global state, no token. Events are cheap, unordered, and duplicable. (Bitcoin appears only at the payments layer, as zaps — see 04-how-to-design.md §value-for-value.)
• Not peer-to-peer. Deliberately client-server, because P2P fights the grain of the modern internet. P2P transports can be added as progressive enhancement; relays are the reliable baseline.
• Not private by default. Nostr is publicity technology. A signed public event is a permanent, attributable, analyzable record; signatures remove deniability. Privacy is opt-in per use case: NIP-44 encryption, NIP-59 gift wrap, NIP-17 DMs, closed relays. Constant's blunter version: "Nostr is a protocol for PUBLICations, it is right there in the word" — a structurally bad fit for DMs and "encrypted privacy" things in general. Design with this in mind and say it out loud in anything you build.
• Not consistent. In CAP terms Nostr chooses availability and partition tolerance, always. There is no "the network" to have a view of — only the relays you happened to ask. Any design that assumes a global view is fighting the protocol and will lose.

Why not the alternatives

One paragraph each, from Building Nostr's appendix; the pattern to notice is that every alternative gives up one of the two essentials — user-held keys or storage-independent data:

• ActivityPub / Matrix (Mastodon et al.): federation of home servers that own identity and storage. Your admin can deplatform you and your data is unsigned, so there is no credible exit — the centralized model replicated at smaller scale, with less accountable admins.
• Secure Scuttlebutt: the spiritual ancestor — cryptographic identity, dumb pubs — but events form per-device hash chains, so you must sync a whole feed to validate one message, one key can't be used from two devices, and partial replication is impossible.
• Pubky: cryptographic identity + DHT-based discovery (genuinely better bootstrapping than Nostr's), but content lives unsigned on a single home server. Right identity, wrong storage.
• Bluesky / atproto: signed data and a sophisticated architecture, but the insistence on a global network view requires firehose relays and app views so expensive that only Bluesky-the-company runs them. Centralization by capital cost.

Nostr is the only design in this space with both user-held cryptographic identity and decentralized, redundant, signed storage. It buys this with inconsistency, jank, and unsolved problems (key rotation above all). That trade is the protocol.

Vocabulary quick reference