We created something special — a peer-to-peer, end-to-end encrypted messaging prototype — and we’ve open-sourced it for everyone to try: https://github.com/free2z/zuu/pull/98/files. But before you get too excited, you should know that this prototype is very different from the typical messaging apps you're used to. Here’s the kicker: there is no persistence. That means if you miss a message, it’s gone — forever.
Wait, what? No persistence? How is this useful?
The idea was inspired by the FROST book. In scenarios like Decentralized Key Generation (DKG), where secret material is shared between participants in rounds. It could be done asynchronously with encrypted persistence; but, it’s easier for the participants to be online and present to receive the messages securely. While other protocols might allow message history to be encrypted and stored, we focused on a live, real-time exchange where no messages are persisted.
Yes, FROST (Flexible Round-Optimized Schnorr Threshold signatures) is done in rounds, but I'll explain it in simpler terms.
Imagine FROST as a group decision-making process where multiple people need to agree on a message before signing it together. But instead of everyone signing at once, they need to exchange some information first. Here's how it works:
Group of Participants: You have a group of people (let's say 5), but only a subset (like 3) are required to sign any message. This is known as "threshold signing."
Rounds of Communication: To create a valid group signature, the participants must first share pieces of information with each other. This happens in a few steps or "rounds" of communication. In the first round, each participant creates a small part of the key needed for signing and sends it to the others. In the second round, they combine the pieces they received into a complete signature.
Why Multiple Rounds? The rounds ensure that no single person can create a signature on their own—they need to work together. Each round exchanges enough information so that only the group can complete the process, ensuring security.
In short, FROST is done in rounds to ensure that participants share and combine enough information to securely generate a group signature, without any single person having control over the whole process. It's like assembling a puzzle where each participant holds different pieces. (GPT4o)
So, either people need to be present synchronously or ... they could do the rounds async over time but it seems like the easiest solution is to be present synchronously?
Exactly! The easiest solution for FROST is for participants to be present synchronously. When they're all online at the same time, they can quickly exchange the required information during each round of communication. This ensures the signing process moves smoothly and gets completed in real-time.
However, in theory, the rounds could be done asynchronously over time. This would mean participants would send and receive the necessary information at different times (e.g., through secure messaging or storage), but it introduces some challenges:
- Trust and Coordination: You’d need a reliable way to ensure everyone sends their pieces securely and at the right time.
- Latency: The whole process could take much longer if people aren't available at the same time.
So while it’s possible to do the rounds asynchronously, having everyone present synchronously simplifies things, makes the process faster, and reduces the complexity of managing delays or potential failures in communication. It’s like holding a live meeting versus a back-and-forth email thread—the live meeting (synchronous) is just quicker and easier. (GPT4o)
Our goal was to create a messaging system that could support private, programmable communication in a way that no mainstream messaging platform does. In exploring this, we prototyped F2ZP2PE2E (previously considered under names like "DAOChat" and "Easy FROST Manager") — a peer-to-peer, end-to-end encrypted messaging system with minimal server involvement. Let’s break down how it works and why it’s different.
How It Works: Pure Peer-to-Peer with WebRTC and WebAuthn
Our prototype uses WebRTC, a protocol designed for peer-to-peer connections, to ensure that messages are sent directly between participants, with no central server processing or storing them. The server only handles ICE signaling (helping participants discover and connect) and WebAuthn authentication. Once the connection is established, all communication is peer-to-peer and end-to-end encrypted — the server knows nothing of the individual messages.
WebAuthn, the technology we’re using for authentication, is a passwordless method built into most modern devices. If you have a smartphone, chances are you already have WebAuthn. And the best part? It's super easy to use — just a tap or scan and you’re in. The authentication is not tied to your Free2Z login, or any other identity. The system only knows your registered authenticator (like your phone’s fingerprint scanner or a hardware key), meaning no one can impersonate you without being able to unlock the authenticator on that particular device.
But there’s a tradeoff: once you close your browser tab, the messages are gone forever. Even if someone had your fingerprint, retina scan, or passwords, they could never retrieve those messages.
Why Would You Use This?
This system isn’t for everyone (yet). If you want message history or the ability to catch up on missed messages, this isn’t it. But if you need a messaging system where absolute privacy and ephemerality are paramount, F2ZP2PE2E is designed for you.
Imagine you need to pass a highly sensitive secret, or you’re conducting a cryptographic ceremony like FROST DKG, where security is critical. Once you close your tab, the messages are irretrievable. Even you can’t get them back (unless you persisted them yourself). It’s as if they were written on paper and then shredded after being read. If someone forced you to give them access by unlocking your authenticator, they would still never see those messages — they’re gone.
There’s no persistence, no backups, and no server-side storage. It’s pure, live, encrypted communication.
What’s the Catch?
As with all bleeding-edge technology, there are some trade-offs:
- No message history: If you disconnect, that’s it. You can’t see messages you missed.
- Mobile limitations: Mobile devices drop the WebRTC data channels when you switch apps or background the browser, causing disconnections.
- Desktop/WebAuthn quirks: While WebAuthn works well on most phones, not all desktop computers (especially custom-built ones) will have a built-in authenticator. You might need something like a YubiKey.
Additionally, because there’s no persistence, you must set up the session out-of-band. You’ll need to pass a secret URL to the participants privately before the messaging session begins. Once connected, you’ll reclaim your session identity through WebAuthn, but again, only during that session.
What’s Next?
This prototype is only the beginning. We believe there’s room for improvement and new features, and you can help! While it’s currently a text-based chat, we could extend it to include audio, video, file transfers, and even Zcash threshold signature transactions (think FROST DKG and more). We’ve designed this with a plugin-friendly architecture so that additional features like message signing or cryptographic ceremonies can be added.
For those looking for more conventional end-to-end encrypted messaging, we’re also exploring the idea of adding a Matrix homeserver to Free2Z, with Single Sign-On (SSO) for Free2Z users. This would allow users to choose between persistent, encrypted messaging and ephemeral, high-security chats like those provided by F2ZP2PE2E.
Get Involved
Want to try it? You can check out the prototype on Free2Z and see it in action. Even better, we’ve open-sourced everything, so you can run the server and client yourself and even make contributions. The code is available on GitHub. If you’re passionate about privacy-first, peer-to-peer communication, we’d love to see what you can build on top of this.
Join us in pushing the boundaries of what’s possible in browser-based communication. Let’s make messaging private, secure, and truly ephemeral—together.
Oh, and I forgot that it supports free2z-flavored markdown!
