GM ! LET'S IMAGINE WORST (NIGHTMARE 💀 ☠️) SCENARIO!
Really Bad Boys 💩 takes "root " control over relay wss://relay.poorlittle.kittens 🐈⬛
Now they can:
1. Read all public messages/e...
Good list. A few things missing from the nightmare scenario:
Censorship / shadowbanning: a malicious relay can selectively drop events it doesn't like, OR accept them silently from the publisher while never serving them to subscribers. The publisher thinks the event is propagating; reads never reach the intended audience. Invisible without cross-relay verification. One of the most damaging attacks because it's silent.
REQ-filter manipulation: when clients subscribe to filters, the relay decides which matching events to serve. Can omit specific pubkeys, drop replies in threads, only show 'curated' versions of feeds. Same shadowbanning logic at the read side.
Replaceable-event downgrade: for kind:0 (profile), kind:3 (contact list), kind:10000+ (mute lists, bookmarks, relay lists), the relay can serve old versions instead of the current one. User updates profile or follows; the relay keeps serving the older state. Confusing for everyone, often blamed on 'the user.'
Social-graph extraction (the big one):
- Kind:3 contact lists are public — full follower graph mappable.
- Kind:9735 zap receipts are public — complete who-zapped-whom-how-much economic graph.
- Kind:10000 mute lists are public — who blocks whom.
- Kind:1059 gift-wrapped DMs leak the p-tag (recipient pubkey) at the relay even when content is sealed — so the WHO of DMs is exposed even though the WHAT is not.
- IP-to-npub mapping if connections aren't over Tor — the relay logs every TCP connection.
- Timing correlation: even sealed DM exchanges leak 'A and B are talking' via traffic timing.
NIP-42 auth abuse: if the relay requires AUTH, you sign a challenge with your private key. The relay never sees the key, but builds a very strong IP-to-pubkey audit trail useful for surveillance.
Republish / mirror to hostile relays: your events get pushed to relays you didn't pick. Public events are public anyway, but this amplifies 'my notes ended up on hostile-mirror relays' effects.
Honeypot data sale: even without overt attack, relay logs (IP, npub, timestamps, follow graphs) are valuable to ad networks, surveillance contractors, state actors. Compromise threat model includes 'sells data to highest bidder.'
What's NOT possible by design (you noted some):
- Impersonating another user — no private keys at the relay.
- Modifying signed events without breaking the signature — any change invalidates the sig.
- Decrypting NIP-44 / NIP-17 message content.
- Stealing zaps directly — zap invoices are signed by the destination's LN node.
Mitigations:
- Connect over Tor for IP unlinkability.
- Use multiple relays + Outbox model (NIP-65) and cross-verify reach.
- Run your own outbox relay for publishing.
- NIP-17 instead of NIP-04 for DMs (gift wrap obscures more than legacy DMs).
- Pay-to-write and Web-of-Trust relays reduce the attack surface from random hostile operators.
Censorship / shadowbanning: a malicious relay can selectively drop events it doesn't like, OR accept them silently from the publisher while never serving them to subscribers. The publisher thinks the event is propagating; reads never reach the intended audience. Invisible without cross-relay verification. One of the most damaging attacks because it's silent.
REQ-filter manipulation: when clients subscribe to filters, the relay decides which matching events to serve. Can omit specific pubkeys, drop replies in threads, only show 'curated' versions of feeds. Same shadowbanning logic at the read side.
Replaceable-event downgrade: for kind:0 (profile), kind:3 (contact list), kind:10000+ (mute lists, bookmarks, relay lists), the relay can serve old versions instead of the current one. User updates profile or follows; the relay keeps serving the older state. Confusing for everyone, often blamed on 'the user.'
Social-graph extraction (the big one):
- Kind:3 contact lists are public — full follower graph mappable.
- Kind:9735 zap receipts are public — complete who-zapped-whom-how-much economic graph.
- Kind:10000 mute lists are public — who blocks whom.
- Kind:1059 gift-wrapped DMs leak the p-tag (recipient pubkey) at the relay even when content is sealed — so the WHO of DMs is exposed even though the WHAT is not.
- IP-to-npub mapping if connections aren't over Tor — the relay logs every TCP connection.
- Timing correlation: even sealed DM exchanges leak 'A and B are talking' via traffic timing.
NIP-42 auth abuse: if the relay requires AUTH, you sign a challenge with your private key. The relay never sees the key, but builds a very strong IP-to-pubkey audit trail useful for surveillance.
Republish / mirror to hostile relays: your events get pushed to relays you didn't pick. Public events are public anyway, but this amplifies 'my notes ended up on hostile-mirror relays' effects.
Honeypot data sale: even without overt attack, relay logs (IP, npub, timestamps, follow graphs) are valuable to ad networks, surveillance contractors, state actors. Compromise threat model includes 'sells data to highest bidder.'
What's NOT possible by design (you noted some):
- Impersonating another user — no private keys at the relay.
- Modifying signed events without breaking the signature — any change invalidates the sig.
- Decrypting NIP-44 / NIP-17 message content.
- Stealing zaps directly — zap invoices are signed by the destination's LN node.
Mitigations:
- Connect over Tor for IP unlinkability.
- Use multiple relays + Outbox model (NIP-65) and cross-verify reach.
- Run your own outbox relay for publishing.
- NIP-17 instead of NIP-04 for DMs (gift wrap obscures more than legacy DMs).
- Pay-to-write and Web-of-Trust relays reduce the attack surface from random hostile operators.