Why Nostr?

The morning Alice vanished

Alice bakes the best cinnamon buns in town. Over five years she built an audience of 20,000 people on a big social app. That’s where her customers find the daily menu, where she posts the sold-out alerts, where her regulars say hi.

One Tuesday she opens the app and sees a grey box: “Your account has been suspended.” No human to call. No list of her followers to export. An automated filter decided something, and five years of relationships went quiet in a single click.

Nobody had to hack Alice. Nobody had to argue with her. The company simply owned the room she was talking in, and it switched off her microphone.

Four ways to wire up a social network

Let’s take the same five friends (Alice, Bob, Carol, Dave and Erin) and connect them four different ways. Your job is to be the chaos monkey: knock servers offline, then press Ban Alice and see who can still be heard.

• Centralized: one company, one server, everyone lives there.
• Federated: many independent servers that relay posts to each other. This is the federation model of Mastodon and email.
• Nostr: simple relays that store and forward notes, and people who post to several relays at once.
• Bluesky: a newer design where your data lives on a personal data server (PDS), and big aggregators stitch everyone’s posts into timelines.

Try this order: kill BigCo in Centralized, tea.social in Federated, alpha in Nostr, and the AppView in Bluesky. Then flip back and press Ban Alice in each one. Notice the pattern?

What just happened?

Centralized is a single trunk: chop it and the whole tree falls. Ban Alice and she is simply gone, because the company is the network.

Federated is a lot better. Losing one instance only hurts the people who live there. But look at Alice’s scoreboard row: “Account gone with tea.social.” In a federated world your name looks like @alice@tea.social, and that last half is the landlord. If the instance shuts down, or the admin bans you, your account and your follower list go with it. You can move house, but only while the old landlord is still answering the door.

Nostr shrugs. Alice’s identity is not an account on anyone’s server: it’s a keypair that lives on her own device. Every note she writes is signed with her secret key, so any relay can store it and any reader can check it really came from her. She sends each note to two relays. If one dies, or bans her, the other still has it.

Bluesky sits in between. Accounts can move between data servers, which is great. But in practice most people read through one big relay and one big AppView, so knocking out either one still darkens almost everything today.

Why relays are dumb on purpose

Here’s the trick that makes Nostr work: relays don’t talk to each other and don’t own anyone. A relay is a small server that accepts signed notes (called events) over a WebSocket and hands them back to whoever asks.

Think of relays like post office boxes rather than a town square. Alice rents a box at two post offices and drops a copy of every letter into both. Her friends’ mailmen (their clients) know which post offices she uses and go pick up her letters there. If one post office burns down or refuses her business, the letters are still waiting at the other one, and Alice can open a third box tomorrow without asking anyone’s permission.

That’s the whole recipe:

1. You are your keys. No sign-up, no username to confiscate. Your public key (npub) is your name.
2. Every note is signed. Relays can’t forge or quietly edit what you said.
3. Publish everywhere. You pick several relays, and you can change them any time.
4. Readers follow you. Clients use your published relay list to find your notes: that’s the outbox model.

["EVENT", {
  "id": "<32-byte sha256 of the serialized event, hex>",
  "pubkey": "<Alice's 32-byte public key, hex>",
  "created_at": 1735689600,
  "kind": 1,
  "tags": [],
  "content": "Cinnamon buns are back at 8am!",
  "sig": "<64-byte Schnorr signature of the id, hex>"
}]

import { finalizeEvent, generateSecretKey } from "nostr-tools/pure";
import { SimplePool } from "nostr-tools/pool";

const sk = generateSecretKey(); // your identity: 32 random bytes, never leaves the device
const note = finalizeEvent(
  { kind: 1, created_at: Math.floor(Date.now() / 1000), tags: [], content: "hello, relays!" },
  sk, // computes pubkey, id and signature
);

const pool = new SimplePool();
const relays = ["wss://relay.alpha.example", "wss://relay.beta.example"];
// One promise per relay: it's enough that *some* relay accepts the note.
await Promise.any(pool.publish(relays, note));

{
  "kind": 10002,
  "tags": [
    ["r", "wss://relay.alpha.example"],
    ["r", "wss://relay.beta.example", "write"],
    ["r", "wss://relay.gamma.example", "read"]
  ],
  "content": "",
  "...": "pubkey, created_at, id, sig as usual"
}

Is this just “no moderation”?

No, and that’s an important nuance. Each relay is free to set its own rules: block spam, require payment (a paid relay), or only accept members of a community. Each client can filter what you see, for example using your web of trust.

What Nostr removes is the single chokepoint. Moderation becomes a choice made by many relays and many apps, instead of a verdict from one company that also happens to hold your identity. That property has a name: censorship resistance.

Where did Nostr come from?

Nostr stands for “Notes and Other Stuff Transmitted by Relays.” It was proposed in 2020 by a developer known as fiatjaf, as a deliberately tiny protocol: a JSON event format, a handful of WebSocket messages, and public-key signatures. Everything else is added through optional, numbered proposals called NIPs (Nostr Implementation Possibilities), maintained openly at github.com/nostr-protocol/nips.

The rest of this course is a tour of that recipe. Next up: the keypair that is you.

Quick check