Your conversations, your keys.
Direct messages and voice are end-to-end encrypted — the server stores zero plaintext and can't listen to your calls. Server channels are protected by transport encryption.
Hybrid Encryption Model
Voidcom uses a hybrid encryption model. Direct messages and voice are end-to-end encrypted with post-quantum cryptography — the server never sees your DM content and can't listen to your calls. Server channels use transport encryption so that server operators can moderate their communities.
- DMs encrypted end-to-end with XChaCha20-Poly1305 — the server stores zero plaintext
- Hybrid X25519 + ML-KEM-768 key exchange — quantum-safe, BSI TR-02102-1 compliant
- Voice keyed by MLS 1.0 (RFC 9420) — the same protocol family as Discord DAVE, Wire, and Element
- Server channels protected by transport encryption
Voice on MLS 1.0
Voice channels are keyed with MLS — the IETF's standardized group messaging protocol (RFC 9420). It's the same protocol family Discord DAVE, Wire, and Element use. We learned from Discord's DAVE protocol papers, then chose a post-quantum hybrid ciphersuite where DAVE is still classical.
- Per-sender signature keys — even people in the same call can't forge frames as you
- Forward secrecy on leave — when someone drops out, their key dies with them within ~2 seconds
- Post-quantum hybrid HPKE (ML-KEM-768 + X25519, the XWing combiner) via AWS LC
- Per-frame XChaCha20-Poly1305 keyed off MLS export-secret per epoch
- Up to 99 participants per E2E voice channel
Built on Open Standards
Voidcom's cryptography is built on open IETF standards: MLS 1.0 (RFC 9420) for voice group keying, AWS LC's audited HPKE primitive for DM key wrapping, BSI-recommended hybrid post-quantum key agreement throughout. Open standards mean cryptography that's been peer-reviewed by the entire field — not by a single team. Every byte that protects your conversations sits on top of code already audited by the broader cryptography community.
- MLS 1.0 (RFC 9420) for voice — IETF-standardized group messaging
- AWS LC's HPKE primitive (FIPS 140-3 validated) for DM channel-key wrap and per-recipient file-key wrap
- One audited cryptographic core shared by voice and DM
- BSI TR-02102-1 compliant post-quantum key agreement
Stage Rooms — Honestly Disclosed
Voice rooms above 99 participants are a separate channel type called Stage. Stage rooms are server-mediated, not end-to-end encrypted — the same posture Discord takes for its Stage channels. Per-frame MLS in rooms of hundreds is a different engineering problem, and we'd rather draw the honest line than overclaim. Regular voice channels (≤99 participants) and DM voice are unaffected — they remain fully end-to-end encrypted with MLS.
- Stage rooms are clearly distinguished from regular voice channels
- Server-mediated encryption — the server can read Stage audio, like any broadcast platform
- All other voice (≤99 participants, all DMs) stays end-to-end encrypted
- Same posture as Discord Stage channels — DAVE doesn't cover Stage either
Key Management
DM encryption keys are generated locally and never leave your device. The hybrid post-quantum key exchange (X25519 + ML-KEM-768) protects against harvest-now-decrypt-later attacks. Voice keys are derived from MLS export-secret per epoch and rotate automatically on every join and leave — no manual rotation needed.
- DM encryption keys stored on your device only
- Voice keys rotate every MLS epoch — automatic, no manual triggers
- Post-quantum key exchange protects against future quantum threats
Built-In Protection
Secure password storage
Industry-leading password protection — the gold standard
E2E encrypted voice
Every voice packet is E2E encrypted under MLS-derived keys — the server can't listen
Rate limiting
Built-in protection against spam and abuse
TLS support
TLS 1.3 with post-quantum key exchange for all connections
Strong password requirements
Enforced complexity to keep accounts safe
Ban evasion prevention
Banned users can't sneak back in through invite links