A WebRTC messenger where message content never touches a server and the push layer can’t see who’s messaging whom
Android app, solo-built. Trying to find out where the architecture breaks before I scale it.
The core idea. Messages travel through direct WebRTC data channels (DTLS/SRTP) between two phones. No server stores, reads, or relays content. Group chats use a gossip protocol, sender fans out to a few reachable members who relay onward; members who come online late fetch missing messages from any peer who has them.
The supporting infrastructure, and what each piece can see.
Signalling: needed to set up any WebRTC connection. I use a Cloudflare Worker (ephemeral, nothing persisted). The SDP/ICE payload is encrypted with the recipient’s public key before it leaves the sender, and the two participants are addressed by opaque per-session hashes. The relay forwards ciphertext between un-linkable identifiers.
Push wake-up: FCM, because Android. Sealed-sender design: the wake-up payload is encrypted to the recipient’s public key, and the sender’s identity is inside that envelope. The push layer sees who’s receiving (it must, that’s how push works), not who’s sending. The FCM request is also forwarded via a Cloudflare Worker so Google doesn’t see the sender’s IP either.
TURN relay: Cloudflare again, for restricted networks. Carries encrypted packets only, like any TURN.
The code is open source (GPLv3).
I wrote a detailed white paper explaining the full architecture on my landing page: https://www.mindtheclub.com/
Mainly interested in where the design assumptions break. The sealed-sender piece, I’d like to know if the threat model I’m assuming there is too generous.
Wow, this certainly seems way more robust than Briar. I especially like the Bluetooth integration. However, I’m wondering about why the white paper says nothing about offline devices. For example, what happens if you try to send a message while the other person is offline and then you yourself end up going offline when they’re online? Does that mean that the message will just never get sent until both of you are online at the same time? That’s how Briar works. Briar also warns about battery drain because of the devices’ constant searching of each other.
By the way, we can all also tell that the website is clearly vibe-coded, but you at least have the open source code going for you.
You got it right. Messages are sent as soon as both the devices are online. The retry pipeline runs on Android’s WorkManager, which cooperates with Doze and App Standby instead of fighting them, so the app doesn’t sit in a tight loop draining battery while waiting. Testing with friends and family hasn’t shown any battery drain so far, but honestly that’s a small sample, maybe a dozen devices total, and friends and family are always a little bit biased. That’s exactly why I’ve gone to Open Testing on Google Play. I need real people, on real networks, on real battery profiles, to find the cases I can’t reproduce alone. If you (or anyone reading) wants to poke at it, that’s the most useful thing you could do for the project right now.