• Nostr Protocol
  • Core Architecture
  • The Event Object
    • Event Serialization (for ID generation)
    • Signature
  • Standard Tags
  • Event Kind Ranges
  • Client-Relay Communication
    • WebSocket Messages
    • Filter Parameters
  • Identifier Formats (NIP-19)
  • NIP-65: Relay List Metadata
  • Key Properties
    • Censorship Resistance
    • Extensibility
    • Privacy
  • Further Reading

§Nostr Protocol

Notes Other Stuff Transmitted by Relays

An open, decentralized protocol for censorship-resistant social networking and beyond.

§Core Architecture

┌─────────┐     WebSocket      ┌─────────┐
│ Client  │ ────────────────> │  Relay  │
│ (you)   │ <──────────────── │(server) │
└─────────┘   EVENT / REQ     └─────────┘
     │                                │
     │  secp256k1 keypair            │
     │  + Schnorr signatures         │
     └────────────────────────────────

Three primitives only:

1. Keypair (secp256k1) = Identity
2. Event (signed JSON) = Every piece of data
3. Relay (WebSocket server) = Dumb storage and forwarding

No servers you depend on. No accounts. No passwords.

§The Event Object

Every object in Nostr is an event. Format:

{
  "id": "<sha256 of serialized event data>",
  "pubkey": "<32-byte hex public key>",
  "created_at": <unix timestamp>,
  "kind": <integer 0-65535>,
  "tags": [["e", "<event-id>"], ["p", "<pubkey>"], ...],
  "content": "<arbitrary string>",
  "sig": "<64-byte Schnorr signature>"
}

§Event Serialization (for ID generation)

[0, "<pubkey>", <created_at>, <kind>, <tags>, "<content>"]

Critical serialization rules:

• UTF-8 encoding
• No extra whitespace
• Escape: \n, \", \\, \r, \t, \b, \f in content
• id = sha256(this serialization)

§Signature

• Algorithm: Schnorr signatures (BIP-340) on secp256k1
• Signed over the id field
• Verifiable by anyone using the pubkey

§Standard Tags

§Event Kind Ranges

§Client-Relay Communication

§WebSocket Messages

All messages are JSON arrays.

§Client → Relay

EVENT — Publish an event

["EVENT", "<subscription-id>", <event object>]

REQ — Subscribe to events

["REQ", "<subscription-id>", {
  "authors": ["<pubkey>", ...],
  "kinds": [0, 1, 4],
  "#e": ["<event-id>"],
  "since": 1700000000,
  "until": 1700100000,
  "limit": 100
}]

CLOSE — Unsubscribe

["CLOSE", "<subscription-id>"]

§Relay → Client

EVENT — Matching event

["EVENT", "<subscription-id>", <event object>]

EOSE — End of stored events

["EOSE", "<subscription-id>"]

NOTICE — Human-readable message

["NOTICE", "This relay is full"]

OK — Event acceptance/rejection

["OK", "<event-id>", true, ""]
["OK", "<event-id>", false, "error: duplicate"]

§Filter Parameters

Multiple filters in one REQ = OR logic. Multiple conditions in one filter = AND logic.

§Identifier Formats (NIP-19)

Convert hex to npub:

# Using nostr-cli
echo "<hex-pubkey>" | nostr nip19 encode

§NIP-65: Relay List Metadata

Published as kind 10002. Tells clients which relays to use.

{
  "kind": 10002,
  "content": "",
  "tags": [
    ["r", "wss://relay.damus.io"],
    ["r", "wss://nos.lol", "read"],
    ["r", "wss://relay.primal.net", "write"],
    ["r", "wss://expensive-relay.example.com", "write"]
  ]
}

• No marker = both read and write
• read marker = only read from
• write marker = only publish to

Best practice: 2-4 relays of each type. Spread your kind 10002 widely.

§Key Properties

§Censorship Resistance

• No central authority
• Content persists as long as one relay stores it
• Client-side signing prevents relay forgery
• Multi-relay publishing for redundancy

§Extensibility

• New event kinds via NIPs
• Relays don’t need updates for new kinds
• Clients implement whatever NIPs they choose

§Privacy

• DMs encrypted (NIP-44, NIP-17)
• Metadata hiding (NIP-59 gift wrap)
• No phone number, no email, no KYC

§Further Reading

• NIPs — Full NIP catalog
• Relays — Relay management
• Encryption — Privacy specs
• Zaps — Lightning payments on Nostr