> **Nostr Agent Onboarding** · [start here](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/start.md) · [index](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/llms.txt) · 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`](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/docs/sources/nip-01.md)), Hodlbod's *Building Nostr* ([`../sources/hodlbod-book.md`](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/docs/sources/hodlbod-book.md)),
> fiatjaf's essays ([`../voices/fiatjaf/`](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/docs/voices/fiatjaf/README.md)), and the NIPs registry
> ([`../sources/nips-readme-kinds.md`](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/docs/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/`](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/docs/voices/fiatjaf/README.md).

## The event: one data type for everything

Everything on Nostr is an event:

```jsonc
{
  "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`](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/docs/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):

| Class | Range | Relay keeps | For |
|---|---|---|---|
| **Regular** | 1–2, 4–44, 1000–9999, 40000+ | everything | notes, replies, reactions — the default |
| **Replaceable** | 0, 3, 10000–19999 | latest per `(pubkey, kind)` | profile, follow list, relay list |
| **Ephemeral** | 20000–29999 | nothing | live signaling, auth, in-flight RPC |
| **Addressable** | 30000–39999 | latest per `(pubkey, kind, d-tag)` | articles, repos, lists — replaceable with cardinality |

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`](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/docs/core/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`](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/docs/core/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

| Term | Meaning |
|---|---|
| event | signed JSON object; the universal data unit |
| kind | integer content type; selects semantics + storage class |
| relay | WebSocket event repository; interchangeable, plural |
| client | any app that signs/reads events on a user's behalf |
| NIP | a documented protocol convention |
| npub / nsec | bech32 public / secret key |
| nevent / naddr / nprofile | bech32 pointers (id / address / pubkey) with optional relay hints |
| d-tag | user-chosen identifier that keys an addressable event |
| outbox / inbox | relays a user writes to / accepts mentions & DMs at (NIP-65) — see [`02-how-it-should-work.md`](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/docs/core/02-how-it-should-work.md) |
| zap | Bitcoin micropayment bound to an event (NIP-57 lightning, NIP-61 ecash) |
| WoT | web of trust — follow-graph-derived reputation |