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.
- Every voice frame is encrypted and authenticated under an MLS-derived key — the server only forwards opaque frames it can't read or alter
- Per-sender frame keys, so co-participants can't impersonate one another, are implemented and rolling out after live validation
- Forward secrecy on leave — keys rotate on every join and leave (a new MLS epoch), so a departed participant can't decrypt anything sent afterward
- 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 — How They Differ
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, so Stage is kept a clearly separate channel type. 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
Verify it yourself
End-to-end encryption only matters if you can confirm there's no one in the middle. Voidcom lets you check, the same way Signal does. Each direct message shows a short proof code derived from both people's keys — read it out on a call or compare it in person, and if it matches, your conversation is private. Key fingerprints are there too, for both your identity key and the channel key.
- A per-conversation proof code (SAS) you can compare out-of-band
- Identity-key and channel-key fingerprints for manual verification
- Server channels show that operators can read them — no misleading lock icon
Built-In Protection
Zero-knowledge login
SRP6a — at sign-in your password never leaves your device; the server stores only a non-reversible verifier
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