Nostr: The Protocol

Core design

The whole protocol fits in two paragraphs:

1. Identity is a key. Each user has a secp256k1 keypair. The public key (npub in bech32) is the user. There is no username allocation, no registry, no email. Lose the key, lose the identity.

2. Events are signed JSON. A user signs a small JSON object (id, pubkey, created_at, kind, tags, content, sig) and publishes it over WebSocket to one or more relays. Anyone subscribing to that relay receives the event. Clients verify the signature locally; relays are dumb pipes.

That is the whole base protocol. Everything else (long-form posts, DMs, reactions, zaps, marketplaces, NIP-05 identity, gift-wrapped DMs) is layered as NIPs (Nostr Implementation Possibilities) over this minimal substrate.

How it differs from the alternatives

Nostr trades discovery convenience for sovereignty. The discovery problem is real but solved at the application layer (follow lists, web of trust, paid relays).

Event kinds (selection)

NIP registry: github.com/nostr-protocol/nips

Encrypted DMs: NIP-04 vs NIP-44 vs NIP-17

This is the central Nostr privacy story.

NIP-04 (legacy, deprecated)

ECDH between sender and recipient pubkey, AES-256-CBC. Plaintext kind=4 events leak:

• Who sent to whom (the relay sees both pubkeys).
• Length and timing.
• The DM relationship as a public fact.

NIP-44 (modern cipher)

ChaCha20 + HMAC-SHA256, with versioning and a proper KDF. The cipher itself is solid; the envelope is still public-key-tagged so the relay can route it.

NIP-17 + NIP-59 (gift wrap, current standard)

Three-layer envelope:

1. Rumor — the actual content event (unsigned).
2. Seal — rumor encrypted to the recipient's pubkey, signed by sender.
3. Gift wrap — seal encrypted to the recipient's pubkey, signed by an ephemeral pubkey, kind=1059.

The relay sees a kind-1059 gift wrap signed by an ephemeral key and addressed to the recipient’s public key in a visible p tag. The original sender is encrypted, but recipient and timing metadata remain visible.

This is a major step toward Signal-grade metadata properties without Signal's centralization.

Relays

Anyone can run one. No federation handshake. Clients connect via WebSocket and subscribe with filters. Relays are pluggable, with diversity of policies:

• Permissive: accept everything (high storage cost).
• Paid: Lightning sats per event (spam-resistant, runs on a small disk).
• Subject-restricted: relays for niche communities, DEFI traders, etc.
• Privacy-restricted: relays that only accept gift-wrapped DMs.

Robust clients connect to multiple relays simultaneously (5-10 typical) for both redundancy and reach. A user can move all their content by republishing to new relays. There is no "account migration" because there is no account.

NIP-05: human-readable names

alice@ungovernable.tech resolves via HTTPS to /.well-known/nostr.json, which maps the name to a hex-encoded public key. Resolution requires DNS and HTTPS, which is a centralization vector.

Mitigations:

• Keep the public key available independently of the alias. NIP-05 specifies DNS and HTTPS; PKARR is a separate naming mechanism, not a standardized NIP-05 transport.
• NIP-05 over Tor .onion: works, less common.

The npub is canonical; NIP-05 is just a presentation alias.

Zaps (Lightning tipping)

NIP-57 wires Lightning payments to Nostr events:

1. User A clicks "zap" on user B's note.
2. Wallet generates a Lightning invoice via B's LNURL endpoint.
3. The receipt is published as kind=9735 on relays.
4. Anyone aggregating zap receipts can compute B's earnings.

This couples Nostr's identity layer with Bitcoin's payment layer. Nostr is the only major social protocol where the speech and payment substrate are equally censorship-resistant.

Trade-offs

Strengths

• Pure pubkey identity. No KYC, no registrar, no censorship at the identity layer.
• Trivial account portability. Move relays without losing followers.
• Permissionless innovation. New kinds and NIPs deployed by anyone, immediately.
• Native Lightning integration. Zaps and paid relays.
• Simple protocol. Single-binary clients, single-binary relays, no PKI.

Limitations

• Lossy persistence. Relays may delete or rate-limit; durability depends on which relays you use.
• Sybil-prone. Anyone can mint an npub; spam mitigations live in client filters and WoT.
• Discovery is hard. Without follow graphs, finding new accounts is non-trivial.
• Key custody risk. Losing the key means losing identity. Use a dedicated signer and a recovery plan; the NIPs README marks NIP-26 delegation as unrecommended. See Nostr Key Custody and Recovery.
• Metadata leaked outside NIP-17. Plain notes are public; even with gift-wrapped DMs, posting and follow lists leak.
• Client diversity, bug surface. Many clients reimplement the protocol; some don't validate signatures correctly.

Attack surface

Tools

Recent developments (2024-2026)

• NIP-17 standardization: gift-wrapped DMs become default.
• Outbox model (NIP-65): clients publish read/write relay lists; receivers know where to post replies.
• Nostr-DVMs: Data Vending Machines, paid compute services discoverable via Nostr.
• Decentralized recovery (NIP-XX drafts): Shamir / FROST-based key recovery.
• Hardware-wallet signing: Coldcard and Keystone added Nostr event signing.

Primary sources

• NIPs registry and proposal status
• Nostr protocol overview
• NIP-01: events and relays
• NIP-17: private direct messages
• NIP-44: versioned encryption
• NIP-59: gift wrap and visible recipient tags
• Nostr NIP-05: DNS-based identifiers

For end-to-end encrypted group chat built on Nostr keys and relays, see White Noise (the Marmot protocol) and Cordn.

Continue with Secure Scuttlebutt.

Also in Secure Messaging