Bringing the Signal Protocol to community chat

End-to-end encryption is one of the most misunderstood features in consumer software. Companies use the term loosely. "Encrypted in transit" is not E2E encryption. "Encrypted at rest" is not E2E encryption. True E2E encryption means the server never has the keys — only the communicating parties do.

Most chat platforms, including Discord, encrypt messages in transit (between your device and their servers) and at rest (on their servers). But Discord holds the decryption keys. That means Discord can read your messages. It means a compromised Discord employee can read your messages. It means a law enforcement request with proper process can read your messages.

Skycord uses a different model.

The Signal Protocol, briefly

The Signal Protocol is the gold standard for E2E encrypted messaging. It's the same protocol used by Signal (obviously), WhatsApp, and iMessage. It was designed by Open Whisper Systems and is open source.

At its core, the Signal Protocol uses a combination of the X3DH (Extended Triple Diffie-Hellman) key agreement protocol for initial key establishment and the Double Ratchet Algorithm for ongoing message encryption. The result is a system where every message is encrypted with a unique key derived from a key exchange that the server participates in setting up but never has access to the final output of.

This provides two critical properties: forward secrecy (compromising today's keys doesn't expose past messages) and break-in recovery (compromising past keys doesn't expose future messages).

The challenge: group channels

Signal Protocol was designed for 1-to-1 and small-group messaging. Applying it to channels with potentially thousands of members is a non-trivial engineering problem.

The naive approach — encrypt once per recipient — doesn't scale. A message sent to a 10,000-member channel would require 10,000 individual encrypted copies. That's a 10,000x amplification factor on both the sender's device and our infrastructure.

We use the Sender Keys mechanism from the Signal Protocol's group messaging specification. Each member of a channel generates a Sender Key — a key that can encrypt messages for the entire group with a single encryption operation. Members share their Sender Keys with each other via encrypted pairwise channels. When you send a message, you encrypt it once with your Sender Key. Every member who has your Sender Key can decrypt it.

Key distribution at scale

Key distribution is where most group E2E implementations fall apart. When a new member joins a 10,000-person channel, they need to receive Sender Keys from all existing members. When a member leaves, all remaining members should rotate their Sender Keys (the "post-compromise security" problem).

We handle joins with a combination of server-assisted key packages (pre-published one-time-use public keys) and lazy key distribution (new members receive keys from active members on their next message send, with a short grace period for decryption failures).

For leaves and bans, we use deferred rotation. We batch key rotation rather than triggering it immediately on every leave event. This means a recently-departed member has a short window where they could decrypt new messages — a deliberate trade-off between security and usability that we disclose clearly.

What this means in practice

Skycord's servers see encrypted blobs. We can store them, route them, and delete them. We cannot read them. A compromise of our infrastructure exposes metadata (who sent a message to which channel, when) but not message content.

There are features this makes impossible. Message search across devices requires storing a local index. If you lose your device and your key backup, you lose your message history. We think that's the right trade-off. Your data's privacy is more important than our ability to offer cross-device search.

We publish our encryption implementation as open source. The code is auditable. We commission annual third-party security audits and publish the reports. We run a bug bounty program. If there's a flaw in our implementation, we want it found.