# How quicprochat Compares to WhatsApp, Telegram, and Signal

Choosing a messenger is a trust decision. This page lays out what each popular
messenger actually does with your messages, metadata, and keys — and where
quicprochat offers stronger guarantees.

---

## At a Glance

| Feature | WhatsApp | Telegram | Signal | quicprochat |
|---|---|---|---|---|
| **E2E encryption (1:1)** | Yes (Signal Protocol) | Opt-in only ("Secret Chats") | Yes (Signal Protocol) | Yes (MLS, RFC 9420) |
| **E2E encryption (groups)** | Yes (Sender Keys) | No | Yes (Sender Keys) | Yes (MLS ratchet tree) |
| **Post-compromise security (groups)** | No | No | No | Yes |
| **Forward secrecy (groups)** | Partial | No | Partial | Full (per-epoch key deletion) |
| **Post-quantum protection** | No | No | PQXDH (1:1 only) | Hybrid KEM (X25519 + ML-KEM-768) |
| **Server reads messages** | No (but see backups) | Yes (cloud chats) | No | No |
| **Server stores metadata** | Extensive | Extensive | Minimal | Minimal |
| **Open-source server** | No | No | No (since 2023) | Yes (MIT) |
| **Open-source client** | No | Client only | Yes | Yes |
| **Password auth** | Phone number (SMS) | Phone number (SMS) | Phone number (SMS) | OPAQUE PAKE (password never sent) |
| **Phone number required** | Yes | Yes | Yes | No |
| **Self-hostable** | No | No | Difficult | Yes (single binary) |
| **Protocol standard** | Proprietary adaptation | MTProto (proprietary) | Custom (well-audited) | IETF RFC 9420 |
| **Wire format** | Protobuf (proprietary) | TL (proprietary) | Protobuf | Protobuf + QUIC framing |
| **Transport** | TCP/TLS (Noise) | TCP/TLS (custom) | TCP/TLS (Noise) | QUIC + TLS 1.3 |
| **Decentralized / federable** | No | No | No | Planned (federation scaffolded) |

---

## The Five Questions That Matter

### 1. Can the server read my messages?

| Messenger | Answer | Details |
|---|---|---|
| **WhatsApp** | Mostly no | E2E encrypted by default, but cloud backups (Google Drive / iCloud) were unencrypted until late 2021. Even with E2E backup enabled, Meta retains metadata. |
| **Telegram** | **Yes** (by default) | Only "Secret Chats" are E2E encrypted — and those are 1:1 only, mobile only, opt-in. All group chats and default conversations are stored as plaintext on Telegram's servers. |
| **Signal** | No | E2E encrypted. Server stores almost nothing. |
| **quicprochat** | No | Server handles only opaque MLS ciphertext. It cannot decrypt, modify, or selectively censor messages — by design, not by policy. |

### 2. What metadata does the server collect?

Metadata — who talks to whom, when, how often, group membership — can be as
revealing as message content.

| Messenger | Metadata exposure |
|---|---|
| **WhatsApp** | Collects contacts, usage frequency, group membership, IP addresses, device info, location data. Shares data with Meta for ad targeting (outside EU). |
| **Telegram** | Collects phone number, contacts, IP addresses, device info. Stores all cloud-chat message content. |
| **Signal** | Stores only phone number and last-connection timestamp. Uses sealed sender to hide sender identity from the server. |
| **quicprochat** | Stores Ed25519 public keys and encrypted delivery queues. Supports sealed sender. No phone number, no contacts upload, no usage analytics. Server sees connection timing and message sizes (mitigated by traffic shaping). |

### 3. What happens if the server is hacked?

| Messenger | Impact |
|---|---|
| **WhatsApp** | Message content is safe (E2E), but attacker gets the full social graph: who talks to whom, group membership, phone numbers, profile photos, last-seen timestamps. |
| **Telegram** | Attacker reads **all cloud chat messages** in plaintext, plus contacts, phone numbers, and media. Only secret-chat content is safe. |
| **Signal** | Attacker gets very little — phone numbers and last-connection dates. Message content and metadata are not stored. |
| **quicprochat** | Attacker gets opaque ciphertext (cannot decrypt), Ed25519 public keys, and connection timing. Cannot impersonate users (lacks private keys), cannot forge messages (lacks MLS group keys), cannot read history (forward secrecy — past epoch keys deleted). |

### 4. Are my group chats truly private?

Group encryption is where the big differences emerge.

| Property | WhatsApp | Telegram | Signal | quicprochat |
|---|---|---|---|---|
| **Group E2E** | Yes (Sender Keys) | No | Yes (Sender Keys) | Yes (MLS) |
| **Group forward secrecy** | Partial (symmetric ratchet) | None | Partial (symmetric ratchet) | Full (MLS epoch ratchet, old keys deleted) |
| **Post-compromise security** | No — if a Sender Key leaks, all future messages from that sender are exposed until manual re-key | N/A | No — same Sender Key limitation | Yes — any member issues an MLS Update, new epoch derived, attacker locked out |
| **Member add/remove cost** | O(n) | N/A | O(n) | O(log n) via ratchet tree |
| **Max practical group size** | ~1024 (pairwise overhead) | 200,000 (no E2E) | ~1000 | Thousands (log-scaling tree) |
| **Group state consistency** | No formal guarantee | N/A | No formal guarantee | MLS transcript hash — all members see identical state |

**What is post-compromise security and why does it matter?**

Imagine an attacker steals one group member's keys. With WhatsApp or Signal,
the attacker can read every future group message from that sender until keys are
manually rotated. With quicprochat, *any* group member can issue an MLS Update
that re-derives the group secret — the attacker is automatically locked out,
without anyone needing to know a compromise occurred.

### 5. Am I protected against future quantum computers?

Quantum computers threaten today's encryption through "harvest now, decrypt
later" — an adversary records encrypted traffic today and decrypts it years from
now with a quantum computer.

| Messenger | Post-quantum status |
|---|---|
| **WhatsApp** | No post-quantum protection. |
| **Telegram** | No post-quantum protection. |
| **Signal** | PQXDH for 1:1 chats (X25519 + ML-KEM-768). No PQ protection for groups (Sender Keys are classical-only). |
| **quicprochat** | Hybrid KEM (X25519 + ML-KEM-768) protects message content. Both classical and PQ KEMs must be broken to compromise the shared secret. Applies to groups, not just 1:1. |

---

## What quicprochat Does Differently

### No phone number required

WhatsApp, Telegram, and Signal all require a phone number. This ties your
messaging identity to a real-world identifier that can be subpoenaed, SIM-swapped,
or used for cross-service tracking. quicprochat uses Ed25519 cryptographic
identity keys — no phone number, no email, no personal information.

### Password never leaves your device

All three major messengers use SMS-based verification. quicprochat uses OPAQUE,
an asymmetric password-authenticated key exchange where the server never sees
your password — not during registration, not during login. The server stores only
an opaque cryptographic record that cannot be used for offline attacks.

### Self-hostable, single binary

You don't have to trust anyone's infrastructure. Run your own server with
`./qpc-server`. Your data stays on hardware you control. No cloud dependency,
no terms of service, no policy changes that retroactively weaken your privacy.

### Open protocol, open server, open client

WhatsApp's server is proprietary. Telegram's server is proprietary. Signal shut
down its server source code in 2023. quicprochat is MIT-licensed — server,
client, SDKs, protocol specification. You can audit every line.

### IETF-standardized cryptography

WhatsApp and Signal use a custom (well-audited) protocol. Telegram uses MTProto,
a custom protocol with a history of cryptographic weaknesses. quicprochat uses
MLS (RFC 9420), an IETF standard designed by the academic cryptography community,
with multiple independent implementations and formal security proofs.

---

## Honest Trade-offs

No comparison is complete without acknowledging where quicprochat is behind:

| Dimension | WhatsApp / Signal / Telegram | quicprochat |
|---|---|---|
| **Maturity** | Billions (WhatsApp), hundreds of millions (Telegram), tens of millions (Signal) of battle-tested users | Early-stage project |
| **Mobile apps** | Polished native apps on iOS and Android | CLI and TUI (mobile SDK foundations exist) |
| **Network effect** | Your contacts are already there | You'll need to invite people |
| **Calling / video** | Built-in voice and video calls | Not yet implemented |
| **Stickers / stories / payments** | Rich consumer features | Focused on core messaging security |
| **Ease of setup** | Download app, enter phone number | Build from source or use Docker |

quicprochat is not trying to replace your casual chat app today. It's for
people and organizations who need **verifiable, self-hosted, post-quantum-ready
group encryption** — and who aren't willing to take a vendor's word for it.

---

## Summary: Why Choose quicprochat?

- **Your server, your rules.** Self-host on your own hardware. No third-party trust required.
- **Groups done right.** MLS gives you forward secrecy *and* post-compromise security for groups — something no mainstream messenger offers.
- **No phone number.** Cryptographic identity only. No SIM swap risk, no phone-number harvesting.
- **Post-quantum today.** Hybrid X25519 + ML-KEM-768 protects group messages against future quantum computers — not just 1:1 chats.
- **Fully open.** Server, client, SDKs, and protocol — all MIT-licensed and auditable.
- **IETF standard.** Built on RFC 9420 (MLS), not proprietary cryptography.

---

## Further Reading

- [Comparison with Classical Protocols (IRC, XMPP, MTProto)](protocol-comparison.md) — deep technical dive
- [Why This Design, Not Signal/Matrix](why-not-signal.md) — protocol-level comparison
- [Post-Quantum Readiness](../cryptography/post-quantum-readiness.md) — hybrid KEM details
- [Threat Model](../cryptography/threat-model.md) — what quicprochat does and does not protect against
