Federation, done without breaking encryption.
We're designing Voidcom so independently-operated instances can talk to each other — no single company holding the kill switch — while your end-to-end encryption stays intact. This page describes the plan, and what isn't built yet.
The design
Portable identity
Accounts will carry a uuid@origin identity tied to their home instance, so you're addressable across the network without a central directory.
Authenticated transport
Instances will talk over a dedicated gRPC service secured with mutual TLS 1.3, each instance publishing a signing key at a well-known address and signing every request.
Encryption preserved
The federation layer carries opaque encrypted payloads. Foreign clients will join MLS groups as real members — so end-to-end encryption is the design goal, not an afterthought.
Explicit peering
Federation will be opt-in per link, with admins inviting and accepting peers and controlling direction — not an open firehose.
How we'll get there
- 1
Text & events
Messages, reactions, typing, and presence flow between instances in real time. End-to-end encrypted messages cross the link as opaque ciphertext — no instance can read them.
- 2
Moderation & trust
Per-peer trust levels, allow/deny lists, and rate quotas. Federated bans and kicks are enforced on the authoritative side, so moderation holds across instances.
- 3
Voice relay
Voice cascades between instances over QUIC, with each person connecting to the nearest node. This stage relays media but is not yet end-to-end encrypted across instances.
- 4
Federated E2EE voice
The flagship: foreign participants join an MLS voice group as full members, so end-to-end encryption holds even across instances. This is the hardest part — and the goal.
This is a deliberate plan, not ActivityPub or Matrix compatibility, and none of it is live yet. Our MLS voice keying is already post-quantum, which is what makes federated end-to-end voice realistic. Follow progress on the roadmap.