Welcome back to our 10-part series on Nostr! In the previous posts, we introduced what Nostr is and why it matters, then explored its origins and evolution from fiatjaf's 2019 proposal to its current status as a growing ecosystem. If you missed those, check them out here and here. Now, we're rolling up our sleeves for a deeper dive into the mechanics. Don't worry if you're not a developer—this primer uses simple analogies and avoids jargon overload. We'll break down the architecture, key concepts like relays and events, and how NIPs keep things evolving. By the end, you'll have a solid grasp of Nostr's inner workings, whether you're a curious user or aspiring builder.
The Core Architecture: Simplicity by Design
Nostr's beauty lies in its minimalism. Unlike complex blockchains or federated systems like ActivityPub (used in Mastodon), Nostr is a lightweight protocol built on standard web technologies: JSON for data, WebSockets for real-time communication, and public-key cryptography for security. Imagine Nostr as a global bulletin board system where anyone can post notes, but instead of one big board, there are many independent ones (relays) that sync selectively.
At a high level:
- Clients: Apps you use (e.g., Damus on iOS or Primal on web) to interact with Nostr. They generate, sign, and send your messages.
- Relays: Servers that store and broadcast messages. They're like post offices—you send mail to one, and it forwards to recipients.
- Users: Identified by a public key (npub), not usernames. Your private key signs everything, proving authenticity.
Data flows like this: You create an event in your client, sign it, and push it to connected relays. Others subscribe to those relays for updates. No central database; redundancy comes from multiple relays.
To visualize, picture a diagram (insert simple ASCII art or describe: A user connects to Relay A and B; posts to both; Follower subscribes to Relay B and receives the post).
User A (Client) --> Event --> Relay 1 <--> Relay 2 <-- Subscription <-- User B (Client)
This peer-to-relay model ensures resilience—if Relay 1 censors or fails, switch to Relay 2.
Cryptographic Foundations: Keys and Signatures
Everything starts with keys. Nostr uses secp256k1 elliptic curve cryptography (same as Bitcoin) for identities.
- Public Key (npub): Your address, like a username. It's a Bech32-encoded string starting with "npub1...".
- Private Key (nsec): Your secret—never share it! It's used to sign events. Lose it, and you lose access.
Generating keys is easy: Most clients do it for you, or use tools like nostr-tool. Analogy: Public key is your mailbox number; private key is the lock's combo.
Every action is an "event"—a JSON object with fields like:
{
"id": "",
"pubkey": "",
"created_at": "",
"kind": "",
"tags": [""],
"content": "",
"sig": ""
}
The ID is a hash of the other fields (minus sig), ensuring immutability. Signatures use Schnorr for efficiency.
This setup prevents forgery: Relays verify signatures before accepting events.
Relays: The Backbone of Distribution
Relays are HTTP servers with WebSocket endpoints. They handle three main ops:
- Publishing: Clients send events via WebSocket (REQ/CLOSE/AUTH, but mainly EVENT messages).
- Subscribing: Clients request filters, e.g., "Give me all kind 1 events from pubkey X since timestamp Y."
- Storing: Relays decide what to keep—some prune old data, others charge for storage.
Anyone can run a relay using open-source software like nostr-relay (Go) or strfry (Rust). Public relays like wss://relay.damus.io are free, but paid ones (via Lightning) offer premium features like anti-spam.
Filters are powerful: JSON objects specifying authors, kinds, tags, etc. Example filter for a feed:
{"authors": ["npub1..."], "kinds": [1], "limit": 50}
Relays push matching events in real-time. For redundancy, connect to 5-10 relays.
Drawback: Relays can read your data (unless encrypted, like DMs via NIP-04). Solution: Use multiple, or run your own.
Events and Kinds: Building Blocks of Functionality
Events are versatile. The "kind" field defines type:
- Kind 0: Metadata (profile: name, picture, about).
- Kind 1: Short text notes (like tweets).
- Kind 3: Follow lists.
- Kind 4: Encrypted DMs.
- Kind 7: Reactions (likes, zaps).
- Higher kinds: Custom, like 23 for long-form articles or 30311 for live events.
Tags add context: "e" for event references (replies/quotes), "p" for pubkey mentions, "t" for hashtags.
This extensibility means Nostr isn't limited to microblogging—it's a base for apps like calendars (kind 31922) or marketplaces (kind 30017).
NIPs: Evolving the Protocol Community-Style
Nostr Implementation Possibilities (NIPs) are GitHub proposals that standardize features. Anyone can submit; community discusses and adopts.
- NIP-01: Core event structure.
- NIP-05: Verifiable identities (e.g., yourname@domain.com maps to npub via DNS).
- NIP-57: Zaps—Lightning invoices in events for tips.
- Recent ones (as of 2026): NIP-58 for badges, NIP-89 for app recommendations.
NIPs ensure interoperability: Clients supporting the same NIPs work seamlessly. Check the Nostr GitHub for the latest—over 100 now.
Putting It All Together: A Simple Workflow
- Generate keys in a client.
- Connect to relays (client suggests defaults).
- Update profile (kind 0 event).
- Post a note (kind 1).
- Follow someone: Add to kind 3 list.
- Receive feeds: Client aggregates from relays.
For devs: Interact via libraries like nostr-sdk (JS) or nostr (Rust).
Why This Design Wins
Nostr's tech enables censorship resistance (hop relays), privacy (pseudonymous, optional encryption), and scalability (distribute load). It's not perfect—discoverability relies on out-of-band sharing—but it's hackable and future-proof.
Next Up
Armed with this knowledge, you're ready for comparisons. In the next post, "Nostr vs. Centralized Social Media: The Decentralization Advantage," we'll contrast it with Big Tech.
Try tinkering: Spin up a relay or browse the protocol spec. Questions? Comment below or zap on Nostr!
What's your take on Nostr's simplicity—genius or too basic? Share!