“If you care about privacy, why aren’t server chats end-to-end encrypted?”

It’s a fair question. We encrypt DMs end-to-end. We encrypt voice. So why not server channels?

The short answer: E2E encrypting server chats would break the features that make servers useful, and it wouldn’t make your data meaningfully safer. The long answer follows.

What end-to-end encryption actually means

When a message is end-to-end encrypted, only the sender and recipient can read it. The server relaying the message sees random bytes. It can’t read the content, search it, moderate it, or do anything else with it.

For private DMs between two people, that’s exactly what you want, and it’s what Voidcom does. Your DMs are encrypted with XChaCha20-Poly1305 using hybrid post-quantum key exchange (X25519 + ML-KEM-768) before they leave your device. The server stores ciphertext. We couldn’t read your DMs if we wanted to, not today and not when quantum computers arrive.

Server channels aren’t private conversations between two people. They’re shared spaces, sometimes with hundreds or thousands of members, and that changes the picture.

Why E2EE breaks servers

Moderation becomes impossible. If the server can’t read messages, it can’t detect spam, harassment, slurs, illegal content, or scam links. Every moderation tool stops working: automod filters, report systems, audit logs. Server admins would be flying blind.

This isn’t hypothetical. Platforms that can’t moderate content become unusable fast. Discord, Slack, and every major group chat platform store server messages in readable form because the alternative is a platform that can’t protect its users.

Search stops working. Full-text search is one of those features you don’t think about until it’s gone. Finding that message from last week, searching for a link someone shared, looking up a pinned announcement: all of it requires the server to index message content. With E2EE you’d be limited to whatever is cached on your local device.

Key management doesn’t scale. In E2EE, every participant needs the encryption key. When someone joins a server channel, they need the key. When someone leaves, the key should be rotated so they can’t decrypt future messages. In a DM between two people that’s trivial. In a server with 500 members where people join and leave constantly, every membership change triggers a re-encryption event that has to reach every remaining member.

Multi-device access breaks. You expect to open Voidcom on a different computer and see your chat history. With E2EE that means syncing encryption keys across all your devices, another layer of complexity with its own failure modes.

What E2EE in group chats actually buys you

Here’s what no one in the industry likes to say out loud: end-to-end encryption for large group chats is mostly theater.

When a channel has 200 members, the “end” in “end-to-end” is 200 endpoints. Every one of those people can screenshot the chat, copy-paste messages, or be compromised individually. The encryption protects against the server operator reading messages, but if even one member of the channel is untrustworthy, the content is exposed anyway.

For DMs the math is different. Two people, one shared secret, real privacy. That’s why we encrypt DMs end-to-end: it protects you.

For server channels, the security question that matters is “is my data protected from breaches, leaks, and unauthorized access?” rather than “can the server read my messages?” The answer to that is yes.

How Voidcom protects server chat data

Every connection is encrypted in transit. All communication between your client and our server runs over TLS. Nobody between you and the server can intercept or read messages: not your ISP, not someone on your Wi-Fi, not a man-in-the-middle. It’s the same transport encryption that protects your banking and email.

Database encryption at rest. Messages stored in our database are encrypted at the storage layer. Someone with physical access to the storage hardware would find the data unreadable without the encryption keys.

Access control and isolation. The server enforces strict permission checks on every request. You can only read messages in channels you have access to. Role-based permissions, server membership verification, and authentication checks run on every API call, not only at login.

Zero-knowledge password login. Login uses SRP6a (Secure Remote Password). When you sign in, your password is verified without being sent to our servers. We store only a non-reversible verifier, never your password in plaintext. The same password also derives, on your device, the memory-hard Argon2id key that unlocks your end-to-end encryption keys.

Rate limiting and abuse prevention. Brute force attacks, credential stuffing, and spam are throttled at the API layer. Ban evasion detection stops bad actors from rejoining after being removed.

What about voice?

Voice is different. Our voice server is a Selective Forwarding Unit: it routes encrypted audio packets between participants without ever decoding them. The server cannot listen to your conversations. It forwards opaque, encrypted packets.

This works because voice doesn’t need moderation, search, or indexing. Once the audio plays, it’s gone. So we can encrypt it end-to-end without losing anything.

The Voidcom encryption model

The full picture:

  • Direct messages are end-to-end encrypted. The server stores only ciphertext and has zero knowledge of the content.
  • Voice calls are end-to-end encrypted under MLS 1.0 (RFC 9420), the same protocol family Discord DAVE uses, on a post-quantum hybrid ciphersuite. The server forwards packets it can’t read.
  • Stage rooms (voice rooms above 99 participants) are server-mediated for moderation, not E2E. Discord takes the same approach for Stage channels.
  • Server channel messages are encrypted in transit (TLS) and at rest (database encryption). The server can read them for moderation, search, and delivery.
  • File attachments are encrypted with per-file keys, wrapped per recipient via the same audited HPKE primitive used for DM keying.
  • Passwords are verified at login via SRP6a without being sent to the server, which holds only a non-reversible verifier, never your password in plaintext.

This is a deliberate design. We encrypt everything we can without breaking the features you need. Where full E2EE isn’t practical, we layer transport encryption, storage encryption, access control, and monitoring instead.

The bottom line

E2E encryption is a powerful tool, and we use it where it protects you. But putting E2EE on server chats and calling it “secure” while breaking moderation, search, and usability isn’t honest engineering. It’s marketing.

We’d rather say clearly what’s encrypted and why, and build real security at every layer, than make promises that sound good and don’t hold up.

Your DMs are private. Your voice is encrypted. Your server data is protected. And we’ll keep pushing what we can encrypt without breaking the experience.