Nostr - Documentation

What it is¶

Nostr — "Notes and Other Stuff Transmitted by Relays" — is the architectural outlier among the protocols in this series, and the one that goes furthest in removing the server layer altogether. Where [[activitypub|ActivityPub]] federates at the instance level and [[at-protocol|AT Protocol]] federates at the account level via PDS/relay/App View layering, Nostr has no concept of an account-owning server at all: your identity is a bare cryptographic keypair, and relays are dumb, interchangeable, swappable pipes rather than authoritative homes for your data the way a Mastodon instance or atproto PDS is.

There's no foundation or company behind the protocol itself — it's a minimal core spec plus a community-maintained set of extension documents, which keeps the barrier to building a client or relay very low, at the direct cost of pushing discovery, spam handling, and moderation almost entirely outside the protocol's scope.

Architecture: keys, events, relays, clients¶

Four pieces make up the whole system:

Keys — every identity is a secp256k1 keypair. The public key is your identity (no handle, no server, no registry); the private key signs everything you publish. There's no recovery mechanism built into the protocol — losing the private key means losing the identity permanently, with nothing analogous to Mastodon's instance-admin password reset or Bluesky's account-recovery flow.
Events — the single unit of data in Nostr. Every event is a signed JSON object: an id (a SHA-256 hash of the event's contents), the author's public key, a timestamp, a numeric kind (what the event is), free-form tags for metadata/references, a content string, and a Schnorr signature over the whole thing. Common kinds include 0 (profile metadata), 1 (a short text note — the microblogging-post equivalent), and 4 (an encrypted direct message). Events are immutable once signed; there's no edit operation — a profile "update" is just a newer kind 0 event, and clients render whichever one has the latest timestamp.
Relays — plain WebSocket servers that store and forward events, nothing more. A relay doesn't interpret, verify authorship chains, or coordinate with any other relay — it just accepts events matching its own (self-chosen) policy and answers client queries against what it's holding. Because relays don't talk to each other, a client typically connects to several at once to get a reasonably complete picture of the network, and there's no guarantee any two relays hold the same data.
Clients — everything else lives here: key management, choosing which relays to use, signing outgoing events, and rendering what comes back. To publish, a client signs an event locally and pushes it to its configured relays; to read, it sends a filter (by author, kind, time range, etc.) and relays return whatever matching events they happen to have.

NIPs: how the protocol actually grows¶

The base protocol (NIP-01) is deliberately tiny — just the event/relay/filter mechanics above. Everything else — encrypted DMs (NIP-04, later superseded by NIP-44), domain-based identity verification (NIP-05, see below), Lightning Network tipping/"zaps" (NIP-57), long-form content (NIP-23) — is defined in separate, independently proposed NIPs (Nostr Implementation Possibilities), maintained as plain markdown documents in a community GitHub repo rather than through any formal standards body. A client or relay only needs to implement the NIPs relevant to the features it wants to support; nothing is mandatory beyond the NIP-01 core.

Identity without a registry: NIP-05¶

Because a raw public key (commonly shown bech32-encoded as npub1...) is not something anyone wants to read aloud or type, NIP-05 lets you attach a human-readable, domain-verified label on top — [email protected] — without that label ever becoming your actual identity. It works by hosting a static JSON file at https://yourdomain.tld/.well-known/nostr.json:

{
  "names": {
    "you": "<your-pubkey-in-hex>"
  }
}

A client checks that file, confirms the hex pubkey listed matches the account claiming the label, and shows a verified indicator if it does. Critically, this is purely cosmetic and advisory — unlike a Bluesky custom handle or a Mastodon account, nothing about your actual identity or your ability to post depends on the domain staying up, the file staying served, or anyone's DNS resolving correctly. If yourdomain.tld disappears tomorrow, your keypair — and every relay relationship tied to it — is entirely unaffected; you simply stop showing the verified label.

What's deliberately not in scope¶

Nostr's minimalism is a design choice, not an oversight, but it means several things other protocols in this series treat as core features are left to clients and relay operators instead:

No global state or canonical feed. There's no single ordered timeline the way atproto's firehose provides one — a client's view of "the network" is only ever the union of whatever its connected relays happen to be holding.
No built-in spam/abuse defense. Relay operators can charge for writes, require a paid subscription, or run their own allow-lists, but none of that is protocol-mandated — it's an active, still-maturing area of relay-side tooling rather than something Nostr itself solves.
No moderation layer at all. There's nothing resembling ActivityPub's defederation or atproto's composable labelers baked into the protocol; a relay can simply refuse to store events it doesn't want, and a client can filter what it displays, but there's no standardized mechanism for either.
Relays can see everything you send them in plaintext (aside from explicitly encrypted event kinds like DMs), so privacy depends on relay trust and client-side encryption choices, not on any protocol-level guarantee.

Strengths and weaknesses¶

Strengths: the simplest core protocol of the four covered here; no server or company can ever delete your identity, since it's just a keypair you hold yourself; extremely low barrier to running a relay or building a client; strong censorship resistance (ban one relay, use another, with no loss of identity or history held elsewhere).

Weaknesses: no recovery if a private key is lost; no canonical global view of the network; spam and abuse mitigation is immature and entirely pushed onto relay operators and clients; discovery is harder than on any server-mediated network, since there's no equivalent of a trending/search index anyone is obligated to maintain.