WebRTC messenger architecture, sealed-sender push, encrypted signalling, looking for threat-model critique
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 unlinkable 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.
#infosec #privacy #WebRTC #cryptography #Android #FOSS #PeerToPeer #Opensource
