Matrix vs Signal Protocol: Why We Chose NOT to Federate

........010101010101010101...... A technical deep-dive into our architecture decision for Guardyn — and why sometimes the best choice is what you don't add.

The Question Everyone Asks

"Why didn't you just use Matrix?"

When building Guardyn, our privacy-focused communication platform, this question came up constantly. Matrix is open, well-documented, battle-tested, and powers major platforms like Element.

So why did we say no?

Understanding the Trade-offs

What Matrix Gives You

Matrix is a federated protocol. Think of it like email:

┌─────────────┐     ┌─────────────┐     ┌─────────────┐

│ Your Server │ ←→  │ Matrix.org  │ ←→  │ Other Server│

└─────────────┘     └─────────────┘     └─────────────┘

Users on different servers can communicate seamlessly. It's decentralized, censorship-resistant, and community-driven.

Matrix Encryption Stack:

• 
  Olm: Double Ratchet implementation for 1:1 chats


• 
  Megolm: Group encryption (sender key based)


• 
  Vodozemac: Rust implementation of the above

What We Actually Needed

Guardyn targets:

• 🏢 Enterprise teams with compliance requirements


• 🔒 Privacy-conscious users wanting controlled environments


• 📋 Organizations needing audit trails and key management

Federation wasn't a feature request. It was complexity we didn't need.

Our Encryption Architecture

Instead of Matrix, we implemented:

┌─────────────────────────────────────────────────────────┐

│                 Guardyn Encryption Stack                │

├─────────────────────────────────────────────────────────┤

│  Layer 3: Application (Messages, Media, Calls)         │

├─────────────────────────────────────────────────────────┤

│  Layer 2: E2EE Protocols                                │

│  ┌─────────────┐ ┌─────────────┐ ┌─────────────┐       │

│  │Double Ratchet│ │   OpenMLS   │ │   SFrame    │       │

│  │   (1:1)     │ │   (Groups)  │ │   (Media)   │       │

│  └─────────────┘ └─────────────┘ └─────────────┘       │

├─────────────────────────────────────────────────────────┤

│  Layer 1: Key Exchange                                  │

│  ┌─────────────┐ ┌─────────────┐                       │

│  │    X3DH     │ │  MLS Keys   │                       │

│  └─────────────┘ └─────────────┘                       │

├─────────────────────────────────────────────────────────┤

│  Layer 0: Cryptographic Primitives                      │

│  Ed25519 | X25519 | AES-256-GCM | HKDF-SHA256          │

└─────────────────────────────────────────────────────────┘

X3DH + Double Ratchet (1:1 Chats)

Same protocol Signal uses. Provides:

• 
  Forward secrecy: Past messages stay secure even if keys leak


• 
  Post-compromise security: Future messages are secure after key compromise


• 
  Asynchronous key exchange: Works even if recipient is offline
  

// Simplified X3DH key agreement

let shared_secret = x3dh_key_agreement(

    &alice_identity_key,

    &alice_ephemeral_key,

    &bob_prekey_bundle,

)?;



let double_ratchet = DoubleRatchet::initialize(shared_secret);

OpenMLS (Group Encryption)

This is where we diverged from Matrix significantly.

Megolm (Matrix):

• Sender-key based


• One key per sender, shared with all members


• Simpler but less secure on member changes

OpenMLS (Guardyn):

• Tree-based key agreement (TreeKEM)


• O(log n) complexity for member changes


• IETF RFC 9420 standard


• Formal verification with ProVerif/Verifpal
  

// OpenMLS group creation

let mls_group = MlsGroup::new(

    &crypto_provider,

    &group_config,

    credential,

)?;



// Adding a member is O(log n)

let commit = mls_group.add_members(

    &crypto_provider,

    &[key_package],

)?;

Why OpenMLS > Megolm

The Numbers

By not implementing Matrix federation:

When Matrix IS the Right Choice

Matrix makes sense when you need:

✅ Federation: Users on your server talking to users elsewhere

✅ Decentralization: No single point of control

✅ Ecosystem: Bridges to IRC, Slack, Discord, etc.

✅ Community hosting: Let users run their own servers

When to Skip Matrix

Consider alternatives when:

❌ Controlled environment: Enterprise with compliance needs

❌ Simplicity: You want to ship faster

❌ Custom crypto: Specific protocol requirements (like OpenMLS)

❌ No federation use case: Your users don't need to talk outside your platform

Our Tech Stack

For those curious, here's what we're building with:

Backend:

  Language: Rust

  Database: TiKV (distributed KV) + ScyllaDB

  Messaging: NATS JetStream

  Orchestration: Kubernetes (k3d for local dev)



Client:

  Framework: Flutter (cross-platform)

  Crypto: Native Rust bindings



Security:

  Encryption: X3DH, Double Ratchet, OpenMLS

  Secrets: SOPS + Age

  Signing: cosign for artifacts

  Builds: Nix flakes (reproducible)

Conclusion

The best architecture decisions often aren't about what you add — they're about what you deliberately leave out.

Matrix is an excellent protocol. For OUR use case, it was the wrong tool. Understanding that distinction saved us months of development and produced a more focused, secure product.

The lesson: Evaluate technologies based on YOUR requirements, not industry hype.

Guardyn is open source. Check out our GitHub to see our encryption architecture in action.

What architectural decisions have you made by choosing NOT to use a popular technology? I'd love to hear your stories in the comments! 👇