Most of today's encryption — RSA, elliptic curves — breaks the day a large enough quantum computer exists. Labs publish progress every quarter. It is not science fiction.

"Harvest now, decrypt later" attacks already happen: an adversary stores your encrypted traffic today and waits.

Post‑quantum algorithms — ML‑KEM and ML‑DSA, standardised by NIST as FIPS 203 and FIPS 204 — are built on math quantum computers do not shortcut. WhisperX uses them for every byte that leaves your device, today.

E2EE (end‑to‑end encryption) — only the people in the conversation can read what's sent. Not the server, not us, not anyone in between.

PQ / post‑quantum — encryption built to survive a future quantum computer.

ML‑KEM (FIPS 203) — the post‑quantum key exchange algorithm. Replaces RSA / Diffie‑Hellman. We use the largest variant, ML‑KEM‑1024.

ML‑DSA (FIPS 204) — the post‑quantum signature algorithm. Replaces ECDSA / Ed25519. We use ML‑DSA‑87.

NIST Level 5 — the strongest of the five security tiers NIST defines. Equivalent to AES‑256.

AES‑256‑GCM / XChaCha20‑Poly1305 — symmetric ciphers that encrypt the actual message and media bytes once a key is established.

DTLS‑SRTP — the standard transport‑layer encryption WebRTC uses for calls. Classical, not post‑quantum — which is why we wrap it in an extra PQ layer.

SAS (short authentication string) — the eight verification words shown during a call. Read them aloud to detect a man‑in‑the‑middle.

MITM (man‑in‑the‑middle) — an attacker who intercepts and possibly modifies your traffic. SAS detects this.

Sealed sender — a delivery technique where the server doesn't learn who sent a message, only who receives it.

TURN / NAT — TURN is a relay used when two devices can't connect directly because of their networks (NAT — your router's address translation, often hostile to direct connections).

Q‑Ratchet — our post‑quantum equivalent of Signal's Double Ratchet. Each message you send uses a fresh per‑message key derived from the previous one; if a single key is ever compromised, only that one message leaks (forward secrecy). The asymmetric step that makes the ratchet quantum‑safe uses ML‑KEM‑1024; symmetric encryption is XChaCha20‑Poly1305.

QRTC — our name for the post‑quantum call protocol. See "What protects my voice and video calls?" below.

Because attackers don't need them yet. They need them eventually. Anything you send today over classical encryption can be archived now and broken when the hardware is ready.

Most messengers will migrate when it's already too late for the conversations they handled this decade. We migrated first.

Signal added post‑quantum to messages (PQXDH, 2023). Calls — still classical.

iMessage PQ3 (2024) — messages only. FaceTime stays classical.

WhatsApp — fully classical.

WhisperX is post‑quantum on everything: messages, voice, video, identity signatures.

Zoom uses ML‑KEM‑768 (NIST Level 3) combined with classical X25519 — a "hybrid" mode. We use ML‑KEM‑1024 (Level 5, the highest tier NIST defines) with no classical hybrid. Pure post‑quantum.

Hybrid is a hedge: if PQ is ever broken, the classical half saves you. We made the opposite call. ML‑KEM survived a six‑year, global cryptanalysis competition. We don't carry classical luggage that quantum will obsolete anyway.

The call protocol is called QRTC. Each call mints a fresh 32‑byte media key. The caller wraps it with the recipient's ML‑KEM‑1024 public key and ships it inside the call offer.

Every outgoing audio and video frame is then AES‑256‑GCM encrypted with that key before it reaches WebRTC's transport layer. So media is double‑sealed: an inner post‑quantum layer plus the standard DTLS‑SRTP layer on top.

A future quantum computer that breaks the DTLS recording still hits a second wall keyed by ML‑KEM‑1024. It does not get the audio.

When the call connects, both sides see eight short verification words. They are derived from both the post‑quantum media key and the network‑layer fingerprint of the call.

Read them aloud. If they match on both ends — no MITM. If they don't, hang up.

If the post‑quantum key never applied, the words are hidden. We never display a comforting badge from data that doesn't actually verify anything.

No. Content is encrypted on your device with keys the server never sees.

And in practice, most messages don't go through our server at all — once two devices know each other, traffic flows over a direct peer‑to‑peer WebRTC channel. The server is the matchmaker that helps your phones find each other; the relay path is a fallback for cases where firewalls block the direct one.

When a message does route through the server (the recipient is offline, the network blocks P2P), it's stored as opaque ciphertext only and deleted as soon as the recipient picks it up. We don't keep it after delivery.

If we're subpoenaed, what we can hand over is whatever ciphertext is still pending in the queue at that moment — we cannot decrypt any of it, and there is very little metadata around it. That is the point.

We use sealed sender. The server delivers your message without learning who sent it. It sees that someone sent something to recipient X — not who.

No public address book, no social graph stored server‑side, no read receipts logged on the server. Less to leak.

Local message database is encrypted with SQLCipher (AES‑256). AES‑256 stays quantum‑safe at the symmetric level — Grover's algorithm only halves the effective work factor, leaving 128 bits of security, still well past brute force. So your stored data is post‑quantum at rest, not just in transit.

The database key lives in the Android Keystore — protected by hardware where the device offers it.

The app is gated by a PIN. Self‑destruct timers wipe content on a schedule you set per chat. A separate panic PIN wipes everything instantly when entered.

Notifications can be set to never reveal sender or content on the lock screen.

Account: a long random ID and your public keys. No phone number or email is required to use the service.

Delivery: queue entries are deleted as soon as the recipient picks them up. We don't keep server‑side message logs, "last seen" timestamps, or read receipts.

What we cannot delete is what we never collected.

Direct device‑to‑device by default. If your network blocks direct connections (strict NATs, hostile firewalls), the call falls through a TURN relay we operate.

The relay handles encrypted packets only. It never holds keys, never decrypts media, never sees who is speaking — just bytes in, bytes out.

By their public Q‑ID (a long random identifier) or by scanning their QR code in person. There is no global directory of users — that's deliberate, the absence of a searchable list is part of the privacy model.

You can also share a deep link (qwing:<hash>) over any other channel — SMS, email, paper. Tapping it on a phone with WhisperX installed prefills the add‑contact flow. The hash you share is keyed; the server cannot reverse it into a Q‑ID.

Android right now. Other platforms aren't shipping yet — the cryptography stack and call protocol have to be re‑implemented natively per platform to keep the trust boundary tight, and we'd rather get one platform right than ship a half‑baked version everywhere.

Not currently. One account = one device. Logging in on a second device is intentionally not a feature today — multi‑device flows are the most common source of subtle leaks in encrypted messengers (race conditions, session forks, leaked transcripts), and we'd rather not bolt that on while the core is still being hardened.

Free during the pre‑beta. The threat model is incompatible with ads or selling user data — those funding paths are off the table by design.

The long‑term plan is a small subscription for power features, with the core messaging + call flow staying free. Numbers and scope aren't finalised yet; what is finalised is that the privacy guarantees do not change based on whether you pay.

Your local message database stays exactly where it is, encrypted with your key in the Android Keystore. No cloud lock‑in — your messages were never uploaded in the first place.

What you'd lose is delivery of new messages (the relay would go dark). Existing conversations remain readable on your device for as long as you keep the app installed.

Larger vendors optimise for compatibility with billions of existing devices and decades of legacy code. Hybrid is the politically safe choice for them.

We are small, new, and have no legacy. So we accepted the trade‑off — bigger keys, larger signatures, a few extra kilobytes per call setup — because that is what survival past 2030 looks like.