“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 too?

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

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 that relays the message sees nothing but random bytes. It can’t read the content. It can’t search it. It can’t moderate it. It can’t do anything with it.

For private DMs between two people, that’s exactly what you want. And that’s exactly what Voidcom does — your DMs are encrypted with XChaCha20-Poly1305 before they leave your device. The server stores ciphertext. We couldn’t read your DMs even if we wanted to.

But server channels aren’t private conversations between two people. They’re shared spaces — sometimes with hundreds or thousands of members. And that changes everything.

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 — automod filters, report systems, audit logs — stops working. Server admins would be flying blind.

This isn’t a hypothetical problem. Platforms that can’t moderate content become unusable fast. The reason Discord, Slack, and every major group chat platform stores server messages in readable form is 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 that requires the server to index message content. With E2EE, you’d be limited to searching only what’s 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, it’s a nightmare — every membership change triggers a re-encryption event that has to be distributed to every remaining member.

Multi-device access breaks. You expect to open Voidcom on a different computer and see your chat history. With E2EE, that requires syncing encryption keys across all your devices — another layer of complexity that adds failure modes and hurts the user experience.

The honest truth about E2EE in group chats

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. Genuine privacy. That’s why we encrypt DMs end-to-end — it actually protects you.

For server channels, the real security question isn’t “can the server read my messages?” It’s “is my data protected from breaches, leaks, and unauthorized access?” And 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. Messages can’t be intercepted or read by anyone between you and the server — not your ISP, not someone on your Wi-Fi, not a man-in-the-middle. This is the same transport encryption that protects your banking and email.

Database encryption at rest. Messages stored in our database are protected by encryption at the storage layer. Even if someone physically accessed the storage hardware, the data would be unreadable without the encryption keys.

Access control and isolation. Our 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 happen on every single API call — not just at login.

Argon2id password hashing. Your password is hashed with Argon2id — the current gold standard for password hashing, recommended by OWASP. Even in a full database breach, your password can’t be reversed.

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

What about voice?

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

This is possible because voice doesn’t need moderation, search, or indexing. It’s ephemeral — once the audio plays, it’s gone. So we can encrypt it end-to-end without losing any functionality.

The Voidcom encryption model

Here’s the full picture:

  • Direct messages — end-to-end encrypted. The server stores only ciphertext. Zero knowledge.
  • Voice calls — encrypted with per-channel keys. The server forwards packets it can’t read.
  • Server channel messages — encrypted in transit (TLS) and at rest (database encryption). Readable by the server for moderation, search, and delivery.
  • File attachments — encrypted with per-file keys.
  • Passwords — hashed with Argon2id. Never stored in plaintext.

This isn’t a compromise — it’s a deliberate design. We encrypt everything we can without breaking the features you need. And where full E2EE isn’t practical, we layer transport encryption, storage encryption, access control, and monitoring to keep your data safe.

The bottom line

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

We’d rather be transparent about what’s encrypted and why, and focus on building real security at every layer — than make promises that sound good but don’t hold up in practice.

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