Message content in MindTheClub travels directly between two devices over an encrypted peer-to-peer channel. No MindTheClub server, and no third party, stores the content of your messages.
To establish that direct connection, two devices need to exchange a small amount of setup information and, if one device is asleep, a signal to wake it. Those two supporting steps are the only places a server is involved, and below we describe precisely what each one can and cannot see.
Before any of that happens, the two devices need to know each other's identity. We describe that first, because every later step in this page builds on it.
Every encrypted step that follows relies on one assumption: each peer is using the real public key of the other, not one substituted by a provider in between. We achieve this with a single out-of-band exchange and a sealed reply, so both sides are verified after one QR scan or one tap on an invite link.
Your QR code contains your user identifier and a fingerprint of your public key, a short cryptographic hash that uniquely identifies it. Your invite link carries the same two things, embedded in the link itself. So, whether someone scans your code or taps your link, their device receives the same fingerprint to check against. Showing the QR face-to-face is the strongest channel, but in both cases the guarantee below holds: the directory provider can never substitute your key undetected.
When the other person scans or taps, their device fetches your public key from the directory and computes its fingerprint locally. If it matches the one in the QR or link, the key is accepted; if not, it's rejected and not stored. A substituted key produces a mismatch, and the device refuses it.
Their device then sends you a contact request with their own fingerprint sealed inside, encrypted with your verified key. Only you can decrypt it. Your device runs the same check in reverse, accepting the contact only if the fingerprints match.
After one scan or tap, both peers have independently verified each other's key, and a provider holding the directory cannot substitute either one without breaking a check it has no power to fake.
MindTheClub uses WebRTC data channels to carry messages. A WebRTC data channel is a direct, encrypted connection between two devices. Once it is established between two peers:
Large files are split into chunks and sent over the same direct channel, with retry logic on the sending device to guarantee eventual delivery. The chunks travel peer-to-peer like everything else.
Sometimes two devices cannot open a direct path (restrictive NATs, mobile carrier firewalls). In that case WebRTC falls back to a TURN relay to pass the encrypted media through. MindTheClub uses Cloudflare's TURN service for this fallback. The relay forwards encrypted packets, it is a standard part of how WebRTC works when a direct connection isn't possible. This fallback affects the network path of the encrypted stream only; it does not change the fact that the content is end-to-end between the two devices.
Before a WebRTC channel can open, the two devices must exchange "signalling" information: connection descriptions and candidate network addresses (in WebRTC terms, the SDP offer/answer and ICE candidates). This is a universal requirement of WebRTC, every WebRTC application, including video-call sites, does this. The information is small and is only needed to establish the connection, it is not your message content.
The question is who carries that signalling, and what can they see. In MindTheClub:
We designed the signalling, so the relay learns as little as possible:
If Bob's phone is asleep or the app isn't running, Alice's device needs a way to wake it so it can join the connection. For this, MindTheClub uses Firebase Cloud Messaging (FCM), Google's push service, because it is the mechanism Android provides to reliably wake an app from the background.
The contents of the wake-up payload are encrypted with the recipient's public key before leaving the sender. Critically, the sender's identity is inside that encrypted payload, it is not visible to the push infrastructure. This is a "sealed sender" design, the party delivering the push cannot see who sent it.
To deliver a push, any push system must know who receives it, that's how delivery works, and it is true of every push-based messenger. So, the recipient's address is necessarily visible to the push layer. What is not visible is the sender's identity, which stays sealed inside the encrypted payload.
To establish the WebRTC connection, devices need short-lived credentials for the STUN/TURN service (the components that help two devices find a network path to each other). These credentials are generated using a secret key that must be kept off the device.
MindTheClub fetches these credentials from a Cloudflare Worker that holds the secret server-side. No Google service is involved in obtaining connection credentials. If this fetch fails, the connection falls back to public STUN servers, which only help a device discover its own public address and learn nothing about who it is contacting.
Putting it all together: peers verify each other's keys with one QR scan or link, then exchange small amounts of encrypted setup information through a stateless relay and a sealed wake-up push. Once the direct channel is open, message content flows device-to-device only.