- {{ 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 →)
-