+ {{ footnote }} +
+Click a step to walk through each state.
+ +
+ Anyone recomputes the hash and checks sig against your
+ pubkey — tamper with one character and it fails. No server vouches for you; the math does.
+
Public key
+Your username. Share it freely — it’s how people find and follow you.
++ npub1q9x…share me +
+Private key
+Your password. Whoever has it is you. Can’t be reset. Never share it.
++ nsec1•••••••••••••••• +
++ No email, no phone, no signup. Your keys work across every Nostr + app — your follows and posts come with you. +
+You post
+A signed note
+Your write / outbox relays
+Where your content lives
+Followers read
+Their app looks there
++ Your app announces which relays you write to. + Other people’s apps read that list and go fetch your notes from the right place — + no central server required. +
++ “If you don’t know where your posts are, you might as well just stay on centralized Twitter.” + — Vitor Pamplona, Amethyst +
++ The web (HTTP) +
+ ++ One server holds your account and your data. It bans you? You’re gone. +
+Nostr
+ ++ You sign notes and broadcast to relays you choose. One drops you? The rest still have it. +
+
+ Relays actually talk over wss:// (WebSockets) — same plumbing
+ as the web. What flips is
+ who owns your identity and where your data lives.
+
| + | HTTP | +Nostr | +
|---|---|---|
| {{ row.label }} | +{{ row.http }} | +{{ row.nostr }} | +
| Role | +Who writes | +Who reads | +If you leave it empty | +
|---|---|---|---|
|
+
+ |
+ {{ row.writes }} | +{{ row.reads }} | +{{ row.empty }} | +
+ The access rules are opposite, so no single relay + fits every list — that’s the whole reason for separate sets. +
+ +nos.lol) is fine in several lists at once.
+ A paid / restricted relay (e.g. nostr.wine) must stay in its lane —
+ great for DMs, wrong for your public inbox.
+ {{ cat.name }}
+{{ cat.what }}
+→ {{ cat.tip }}
++ Don’t overthink it: set outbox, inbox and + DM with ~3 solid relays each. Amethyst suggests the rest from who you follow. +
+Remember
+Go deeper
++ {{ kicker }} +
++ {{ subtitle }} +
++ {{ tagline }} +
+The event the provider publishes when your zap is paid:
+ +p = who was zapped
+ description = who zapped (your signed 9734)
+
+ Clients trust it only if pubkey matches the
+ nostrPubkey the recipient’s provider advertised — that’s what stops fake zaps.
+
You pay a Bitcoin Lightning invoice.
++ Their profile lists a Lightning address. Your app fetches an invoice and pays it — instant, + cheap, and on its own invisible. This step is 100% Lightning; Nostr isn’t involved yet. +
+Their Lightning provider signs a zap receipt.
+
+ The provider has its own Nostr key. When the invoice clears it
+ signs a kind 9735 event — tagged with
+ who was zapped and embedding your signed request (which says who
+ zapped, how much, and any comment) — then posts it to the relays you named.
+
+ Same sats either way — the public, signed receipt is what turns a + private Lightning tip into a visible zap. +
+
+ Under the hood (NIP-57): your signed
+ zap request (kind 9734) rides along with the LNURL-pay invoice; the
+ provider advertises allowsNostr + its
+ nostrPubkey, and clients only trust a
+ 9735 receipt signed by that key. (Next: its anatomy →)
+