A system you can reason about
Most messaging apps ask you to trust them. They say your messages are encrypted, your data is safe, your privacy matters — and then they route everything through their servers, where your content exists in a form you can't verify or control.
MindTheClub takes a different approach. Instead of asking for trust, we built a system that's simple enough to understand — so you can reason about what happens to your data yourself. We believe the most important quality a communication tool can have is predictability: when you send a message, you should know exactly where it goes, what path it takes, and where it ends up. No surprises.
Here's how it works.
MindTheClub is a peer-to-peer messaging app. When you send a message, it travels directly from your phone to the recipient's phone. There is no MindTheClub server in between that stores, reads, processes, or relays your content.
This is made possible by WebRTC, the same open standard that powers video calls in your browser. WebRTC establishes a direct encrypted data channel between two devices. Your message enters this channel on one end and exits on the other. That's the entire journey.
When two devices are behind firewalls or on mobile networks that make direct connections difficult, the connection is relayed through a TURN server hosted on Cloudflare's global network. Even in this case, the relay simply passes encrypted packets — it cannot read the content. Think of it as a postal worker who carries a sealed envelope: they know the destination, but they never see what's inside.
Before two devices can establish a direct connection, they need to agree on how to connect — exchanging network addresses, encryption keys, and connection parameters. This negotiation is called signalling, and it's the only step that touches a server.
MindTheClub uses Firebase Firestore as a lightweight signalling relay. The signalling data is ephemeral: it's used only to set up the connection and has no value afterwards. It contains no message content.
Once signalling completes and the WebRTC channel opens, the server's role is over. Everything that follows happens directly between the two devices.
Mobile phones aggressively conserve battery. When a phone is idle, its network connections are suspended. So how do you send a message to someone whose phone is asleep?
MindTheClub uses Firebase Cloud Messaging (FCM) — the same push notification infrastructure used by virtually every Android app — to send a lightweight wake-up signal. This signal contains no message content; it simply tells the recipient's device: "Someone wants to send you something. Wake up and connect."
The recipient's device wakes, establishes a WebRTC connection back to the sender, and the actual message is transmitted directly — peer to peer, as always.
A photo, a video, a voice note — these can be megabytes in size, and mobile connections can be interrupted at any moment. Sending a large file as a single blob would mean starting over from scratch if anything goes wrong.
MindTheClub breaks large content into small chunks and sends them sequentially over the WebRTC data channel. The receiving device reassembles the chunks and verifies the result. If the connection drops mid-transfer, only the missing chunks need to be retransmitted — not the entire file.
This is the same principle used by every reliable file transfer protocol. It's not novel, but it's essential for a good experience on real-world mobile networks.
What happens if your recipient is on a plane, or their phone is off, or they're in a tunnel? The message can't be delivered right now — but it must be delivered eventually.
MindTheClub uses Android's WorkManager to guarantee delivery. When a message can't be sent immediately, it's persisted locally and scheduled for retry. WorkManager survives app restarts, device reboots, and battery optimisation. It will keep retrying — with appropriate backoff — until the message is delivered.
Combined with FCM wake-up signals, this creates a reliable delivery pipeline: your message is stored safely on your device, a wake-up nudge is sent when the recipient is likely reachable, and the direct transfer completes as soon as both devices are online. At no point does the message content sit on a server waiting to be picked up.
Group messaging in a peer-to-peer system presents a unique challenge. In a traditional app, you send one copy to the server and the server distributes it to every group member. Without a server, the sender would have to connect to each member individually — which doesn't scale well and fails entirely if some members are unreachable.
MindTheClub solves this with a gossip protocol. The sender transmits the message to the group members it can reach. Those members, in turn, can relay the message to other members who weren't reachable by the sender. Like a rumour spreading through a room, the message propagates until everyone has a copy.
If a group member comes online later and discovers they're missing a message, they request it from any member who already has it — not just the original sender. This makes group delivery resilient: no single device is a bottleneck, and the group doesn't depend on any one member being online.
When you use MindTheClub, the behaviour of the system is predictable:
We didn't build MindTheClub this way because peer-to-peer is trendy. We built it this way because it produces a system whose behaviour you can predict and verify. And we believe that's a better foundation for trust than any privacy policy.