Where our claims come from.
Every meaningful, contestable claim on this site has a source. Performance numbers come from documented measurements; crypto names point to the public RFCs and standards we implement; competitor cells link to the docs or community threads we read to write them. The Voidcom server and client are not open-source today — where a claim is about our own implementation, we say so and link to our engineering blog instead.
Last reviewed:
Why we publish this
The discrepancy between what a marketing page says and what the product actually does is usually invisible to visitors. We'd rather make it impossible for ourselves to slip — every entry below names where the claim appears on the site, and what we'd cite if someone disputed it. If a claim turns out to be wrong, we change it here and on the page where it lives, in the same change.
Performance claims
All RAM and startup numbers shown on the site come from real measurements on the same Windows 11 machine, not synthetic benchmarks.
-
~170 MB idle RAM (Voidcom) vs ~560 MB (Discord)
On the site: PerformanceFeature on /, /technology, /use-cases/gaming
-
~3× less memory than Discord
On the site: PerformanceFeature ratio callout
Headline uses the conservative idle row (3.2×). Voice-connected ratio is 2.8×; voice + webcam is 2.4×; both are documented in the methodology table.
-
5 ms audio frames (Low Latency preset)
On the site: VoiceFeature, FeatureCards, /features/voice
The 5 ms figure is the Low Latency preset only. Default preset is 20 ms. The site qualifies the claim wherever the number appears.
Cryptography
Every algorithm and standard we name on the site is implemented in voidcom_crypto and used by the server. The links below point to the canonical specification.
-
Hybrid X25519 + ML-KEM-768 key exchange (XWing combiner)
On the site: TechnologyCards, /features/security, /safety, /privacy
DM and voice both use AWS LC's HPKE primitive with the ML_KEM_768_X25519 ciphersuite (the XWing combiner). One audited cryptographic core is shared between DM channel-key wrap, per-recipient file-key wrap, and MLS voice keying — replacing earlier custom combiner code.
-
MLS 1.0 (RFC 9420) for voice group keying
On the site: ComparisonTable, /features/security, /faq, /privacy, /compare, /use-cases/privacy, /blog/voice-mls-pq
- RFC 9420 (Messaging Layer Security)
- mls-rs (AWS Labs implementation)
- Discord DAVE protocol whitepaper (reference design)
Voice channels with up to 99 participants and DM voice are keyed by MLS — the same protocol family Discord DAVE, Wire, and Element use. The voice gateway acts as MLS Delivery Service and sole authorized External Sender, mirroring the DAVE architecture. We chose the ML_KEM_768_X25519 ciphersuite (XWing) where DAVE uses classical P-256.
-
AWS LC HPKE primitive (FIPS 140-3 validated) for DM and voice
On the site: TechnologyCards, /features/security, StackTable
- AWS LC — FIPS 140-3 validated cryptographic library
- mls-rs-crypto-awslc (post-quantum HPKE provider)
AWS LC provides the audited cryptographic core for both DM channel-key wrap and MLS voice keying. The post-quantum hybrid HPKE (ML-KEM-768 + X25519) is the same primitive across all PQ-resistant key exchanges in Voidcom.
-
XChaCha20-Poly1305 AEAD for message and voice frame payloads
On the site: /features/security, TechnologyCards, StackTable
Voice frames are AEAD-encrypted with a per-epoch key exported from the MLS group state. DM messages are AEAD-encrypted with the per-channel key delivered via AWS LC HPKE. The AEAD primitive is the same in both paths.
-
Stage rooms (voice >99 participants) are server-mediated, not E2E
On the site: ComparisonTable footnote, /features/security, /privacy, /faq
Same posture Discord takes for Stage channels: DAVE applies to non-Stage voice only. Voidcom's Stage tier is clearly distinguished in the UI from regular voice channels (which remain E2E).
-
Out-of-band verification — proof code (SAS) and key fingerprints
On the site: /features/security "Verify it yourself", /safety
- Signal — Safety Numbers (the same out-of-band verification model)
- RFC 9420 §5.2 (MLS authentication / signature keys)
Each DM shows a short proof code derived from both participants’ public keys and the channel key; identity-key and channel-key fingerprints are also exposed for manual comparison. Comparing them out-of-band detects a machine-in-the-middle. Server channels are shown as operator-readable rather than displaying an E2E lock.
-
Zero-knowledge login with SRP6a — the password never reaches the server
On the site: /features/security, /privacy, /faq, /safety
Login uses SRP6a (2048-bit group, SHA-256): the server stores only a verifier v = g^x mod N and verifies the client without ever receiving the password or anything reversible to it.
-
Argon2id key derivation for the single-password E2EE key-wrap
On the site: /features/security, /privacy
The account password derives, on-device, a memory-hard Argon2id key-encryption-key that wraps your end-to-end-encryption secret key; the same KDF backs the recovery-phrase and optional extra-password locks. OWASP-recommended parameters: 64 MB memory, 3 iterations, 4 lanes.
-
BSI TR-02102-1 compliance for the post-quantum key exchange
On the site: TechnologyCards "BSI TR-02102-1" tag
TR-02102-1 lists hybrid X25519 + ML-KEM-768 as the recommended PQ-secure key agreement.
Architecture
Claims about how Voidcom is built — Rust core, QUIC SFU, EU-hosted persistent data. The Voidcom server and client are not open-source today, so the citations below point to public specifications and our own engineering blog rather than to the implementation. We're aware that means asking you to take our word for it on the parts that aren't externally verifiable; if and when we publish a third-party audit, it will land here first.
-
gRPC signaling on tonic, QUIC voice/video on quinn
On the site: TechnologyCards, /features/voice, /technology
Our backend is a Rust server built on these two crates. The implementation itself is closed-source today.
-
Voice/video uses an SFU (selective forwarding unit), not P2P
On the site: ComparisonTable "Video / screen share" row, /features/video
Single SFU process per region forwards packets between participants. Each sender uploads one stream — bandwidth scales linearly with senders, not with viewers, which is the architectural difference vs. TeamSpeak 6 today.
-
Native desktop client — Flutter UI on a Rust core
On the site: FeatureCards "Featherweight Client", TechnologyCards "Rust Core"
The desktop client uses Flutter for the UI layer and calls into Rust libraries (audio, video, crypto) over FFI. The /blog/perf-methodology measurements verify the resource-usage outcome of that choice.
-
Account data, messages, and files hosted in the EU
On the site: BuiltForSection, PrivacyFeature, beta CTA badge
Backend is designed to run across multiple EU providers in Germany (Hetzner, OVH, IONOS, Leaseweb) with cross-provider failover.
-
Voice SFU regions shown on the world map
On the site: /technology — SfuMap
Status is tracked per region in our website data file: "online" today is EU only; "planned" markers (US, Canada, Japan, Singapore, Australia) are infrastructure we have committed to but have not deployed yet.
-
Adaptive redundancy engages automatically under packet loss
On the site: /features/voice "Built to ride out bad networks"
The audio pipeline carries a redundant copy of recent audio when measured loss rises above a threshold (with hysteresis) and drops it again when the link recovers, so the extra bandwidth is only spent when it improves resilience. Retransmission covers burst losses. Implementation is closed-source today.
-
Discord-compatible bot API (in development) — REST, gateway, slash commands, webhooks
On the site: /features/bots, /roadmap
Built server-side but not yet available: there is no developer portal, so no bot token can be issued today. As designed, REST routes are mounted under /api/v10 and the gateway uses Discord-style opcodes, so discord.js will connect by overriding the API host and gateway URL. discord.py will need a host-rewrite proxy or a fork that accepts a custom API URL. Voice is not exposed to bots. The bot API implementation is closed-source today.
-
Forum channels with tags, sorting, and live updates
On the site: /features/servers#forums, /roadmap
Forum posts, tags, sorting (recent activity / newest), and live post/reply streaming are implemented end-to-end across the cluster; post titles are indexed for full-text search. Implementation is closed-source today.
-
Federation is planned, not yet available
On the site: /federation, /parity, /docs
Federation between instances is a design, not a shipped feature: there is no instance peering today and the federation page says so explicitly. The intended architecture (uuid@origin identity, gRPC over mTLS, MLS-preserving E2E) is described as a plan. The MLS voice ciphersuite is already post-quantum, which is what makes federated E2E voice realistic.
Legal & compliance
Voidcom is operated from Germany and these terms are written for German and EU law. The references below point to the frameworks our Terms and Contact pages rely on.
-
Terms governed by German law; 16+ minimum age; consumer rights preserved
On the site: /terms
Voidcom is operated by a German sole operator (see Imprint). The Terms set a minimum age of 16 (Germany's GDPR Art. 8 digital-consent age), choose German law, and state that mandatory consumer protections are unaffected. This is a self-authored draft, not legal advice.
-
EU Digital Services Act point of contact & online dispute resolution
On the site: /terms, /contact
Our DSA point of contact is team@voidcom.app. We link the EU ODR platform but are not obliged to use a consumer-arbitration board.
-
Discord-compatible bot API surface (REST + gateway) — in development
On the site: /docs/bots
In development and not yet available — there is no developer portal yet, so no bot token can be issued today. As designed, the bot API mounts REST routes under /api/v10 and uses Discord-style gateway opcodes and rate-limit headers, with a Voidcom snowflake epoch of 2025-01-01. discord.js will connect by changing the host; discord.py will need a proxy or fork; voice is not exposed to bots.
Competitor claims
Every cell in the comparison table on /compare reflects what each competitor publicly advertises or documents on their own site or community forum, last reviewed on the date above.
-
Discord uses DAVE for E2E voice and video; mandatory since 2 March 2026
On the site: ComparisonTable, /use-cases/privacy, /blog/welcome
- Discord — Bringing DAVE to All Discord Platforms
- Discord support — End-to-End Encryption for Audio and Video
- DAVE protocol whitepaper
Discord text DMs are still not E2E encrypted.
-
Discord free voice channels are capped at 96 kbps
On the site: ComparisonTable "Voice quality presets"
-
Discord free file upload limit: 10 MB
On the site: ComparisonTable "File sharing"
-
TeamSpeak 6 has opt-in per-chat E2E encryption (DMs only, not voice)
On the site: ComparisonTable, /use-cases/privacy, /blog/welcome
- TeamSpeak Community — "What does the encrypt chat do?"
- TeamSpeak Community — End-to-End encrypted chats
TeamSpeak 6's voice is still transport-only AES — the encrypt-chat feature only protects the selected DM/group conversation.
-
TeamSpeak 6 video / screen share is P2P only — no server-side SFU yet
On the site: ComparisonTable "Video / screen share"
-
TeamSpeak ships file sharing
On the site: ComparisonTable "File sharing"
-
Mumble uses TLS for control + AES-OCB / AES-GCM over UDP for audio (not E2E)
On the site: ComparisonTable, /use-cases/privacy
The server can decrypt audio. There is no E2E mode for voice; file sharing and video are also not built in.
Found a wrong claim?
If something on the site reads off, doesn't match the source, or doesn't match the code — please tell us. Send a note to max@voidcom.app with the page and the issue. We'll fix it and credit you in the next change to this page.