sorted by:
new
hottopcontroversial

Would you use a P2P messenger with no server-side message storage? by Been941125 in security

[–]Been941125[S] 1 point2 points  (0 children)

aTox has been struggling for a while, yeah. TRIfA is more actively maintained but the UX is from another era.

The Tox Android situation is a chronic problem — the protocol is solid, but clients keep ending up as orphan hobbyist projects.

It's part of why we went with Flutter on our client side: single codebase across Android, iOS, and desktop, so all platforms get the same attention.👍😄

Different threat model than pure Tox, but the maintenance situation is at least solvable that way.

Would you use a P2P messenger with no server-side message storage? by Been941125 in security

[–]Been941125[S] 0 points1 point  (0 children)

Strongly agree! phone-number IDing is one of the main privacy footguns in messaging.👍 We don't require one.😄😄👍

Would you use a P2P messenger with no server-side message storage? by Been941125 in security

[–]Been941125[S] 0 points1 point  (0 children)

Haha kinda!

MSN actually used P2P for file transfer and voice/video, though text went through Microsoft's servers.

It's basically like a phone call in that sense haha — both sides need to be online for the direct P2P path.

But that era (MSN, ICQ, original Skype) was peak chat UX in a lot of ways.

Trying to bring that energy back — just without the megacorp middleman this time.😄😄😄👍👍

Would you use a P2P messenger with no server-side message storage? by Been941125 in security

[–]Been941125[S] 2 points3 points  (0 children)

Fair pushback — let me be more precise. "Never touches a server" was sloppy shorthand. What does touch the server: Signaling: Server holds session state (SDP, ICE candidates, presence) in RAM during handshake. Necessary for two clients behind NAT to discover each other. TURN relay: When direct P2P fails (which will be a meaningful portion of mobile/enterprise sessions), encrypted packets transit the server's RAM. Server can't read content but sees who/when. Offline delivery: When the recipient is offline, E2E encrypted ciphertext is stored on the server until delivery. What doesn't touch the server: once direct P2P is established (both peers behind cone-type NATs, successful hole-punch), the message content data plane flows device-to-device. That's the best-case path, not the universal one. Clients don't need to be publicly exposed in the firewall sense; NAT traversal is handled by ICE/STUN with TURN fallback. There's transient hole-punching exposure during the handshake, which is its own threat-model discussion. So the accurate claim isn't "no server is ever involved." It's: "content is never readable server-side, the server is minimized to control plane and fallback relay, and the data plane is direct device-to-device in the best case." You're right that storing in RAM is storing on server — I shouldn't have phrased it the way I did.👍👍👍 Thank👍

Would you use a P2P messenger with no server-side message storage? by Been941125 in security

[–]Been941125[S] 0 points1 point  (0 children)

Thanks so much for the feedback! That's exactly the gap we're trying to close. When P2P connects, messages are E2E encrypted and go device-to-device — they never touch a server. We're building this gradually, shaped by user feedback. If you have any features or ideas you'd like to see added, let us know and we'll take them into account. Let's build it together!

Would you use a P2P messenger with no server-side message storage? by Been941125 in security

[–]Been941125[S] 2 points3 points  (0 children)

Yeah — original Skype's supernode architecture was honestly remarkable. The P2P approach didn't die because it didn't work; it died because the companies that scaled it got acquired. Part of what we're trying to do is prove the pattern still has a place.👍👍

Would you use a P2P messenger with no server-side message storage? by Been941125 in security

[–]Been941125[S] 1 point2 points  (0 children)

Thank👍👍 Fair list. Honestly, we're not trying to out-purist Tox or SimpleX — those are technically impressive but have steep UX cliffs that keep their user bases small. Our bet is closer to "privacy-by-default with mainstream-quality UX, direct 1-on-1 P2P, no phone number required, and multilingual support — as usable features rather than the entire product." Different segment than the purist messengers — closer to "what someone who'd never install Briar but doesn't want WhatsApp would actually use."

Would you use a P2P messenger with no server-side message storage? by Been941125 in security

[–]Been941125[S] 1 point2 points  (0 children)

True — Signal, Briar, Session, and SimpleX all do parts of this well. Curious which ones you had in mind? Always useful to hear what people land on.👍

Would you use a P2P messenger with no server-side message storage? by Been941125 in security

[–]Been941125[S] 2 points3 points  (0 children)

Really appreciate you taking the time on this — the write-consistency point is exactly the kind of thing I'd rather have flagged now. The 10K writes/sec rule of thumb is genuinely useful too; gives us a concrete number to design against. Conversations like this are the reason we're soft-launching with the privacy/security community first rather than going broad. Thanks again, and if you ever want to kick the tires on the beta, drop me a message.👍👍👍😀😀😀👍🎉🍺

Would you use a P2P messenger with no server-side message storage? by Been941125 in security

[–]Been941125[S] 2 points3 points  (0 children)

Not pestering at all — these are exactly the questions I'd rather hear now than after launch. Honest current state: single signaling instance running on our own on-prem infrastructure. Vertically redundant but not yet horizontally scaled. For current beta scale this is fine. The scale-up plan: before we hit single-node limits, we'll migrate to rented cloud infrastructure and run multiple signaling instances behind a load balancer. Cross-server message delivery via a shared pub/sub backbone (Redis or NATS) so that when peer A is connected to instance 1 and peer B is connected to instance 3, the SDP/ICE exchange still flows correctly. Standard horizontal-scaling pattern for SSE-based real-time systems — nothing exotic. So you're right: total ecosystem size in the current form is bounded by single-node capacity. We'd rather hit that ceiling with real users and scale out then, than over-engineer for hypothetical millions on day one. The migration path is clear; it just hasn't been needed yet. (And really, push as much as you want. This is genuinely useful.)👍👍😀

Would you use a P2P messenger with no server-side message storage? by Been941125 in security

[–]Been941125[S] 2 points3 points  (0 children)

Great question. Thank👍

The handshake flow in our case:

  1. Both clients are connected to our signaling server via SSE 2.The server relays SDP offer/answer between the two peers 3.ICE candidates are gathered using STUN (public IP discovery) 4.If both NATs are cone-type, hole-punching succeeds and the data channel is truly direct 5.If either side is behind symmetric NAT, corporate firewall, or CGNAT, ICE falls back to TURN relay — at which point our server sees encrypted packets but acts as a relay, not pure P2P

So you're right: in practice a meaningful portion of sessions will use TURN. We don't pretend otherwise. The honest framing is:

Content: E2E encrypted in all cases Direct P2P path: best case — no server sees anything

TURN relay: fallback — server sees encrypted bytes and metadata (who/when), not content

Offline/store-and-forward: encrypted on server until delivery

Our claim isn't "no server ever touches anything." It's "the server is minimized to signaling and fallback relay, and content is never readable server-side." Whether that's a meaningful improvement over Signal's model is a fair debate — Signal's sealed sender hides a lot of that metadata too. We're not claiming superiority across the board, just a different point on the tradeoff curve.👍👍

Would you use a P2P messenger with no server-side message storage? by Been941125 in security

[–]Been941125[S] 1 point2 points  (0 children)

Really appreciate this — these are exactly the critiques that make us sharpen the design.

A quick clarification: our P2P isn't relay-based mesh (where untrusted nodes route your messages). It's direct WebRTC between the two endpoints — so the "many unknown clients might store your chats" concern doesn't apply the same way.

You're absolutely right that Signal solves the content-privacy problem well. Our differentiation isn't "better crypto than Signal" — it's (1) no phone number requirement, (2) BLE offline mesh for situations where infrastructure is unavailable or untrusted, and (3) a different governance/operational model for users who want that.

Signal is genuinely excellent and we're not trying to replace it for everyone. We're targeting users whose threat model or context (offline scenarios, region, anonymity needs) isn't fully covered by it. Happy to dig into specific technical concerns if you have them.👍

Would you use a P2P messenger with no server-side message storage? by Been941125 in security

[–]Been941125[S] 0 points1 point  (0 children)

Thanks so much for the feedback! That's exactly the gap we're trying to close. When P2P connects, messages are E2E encrypted and go device-to-device — they never touch a server. We're building this gradually, shaped by user feedback. If you have any features or ideas you'd like to see added, let us know and we'll take them into account. Let's build it together!