DEV Community

anrysys
anrysys

Posted on

Matrix vs Signal Protocol: Why We Chose NOT to Federate

#security #encryption #architecture #rust

........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│
└─────────────┘     └─────────────┘     └─────────────┘
Enter fullscreen mode Exit fullscreen mode

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          │
└─────────────────────────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

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);
Enter fullscreen mode Exit fullscreen mode

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],
)?;
Enter fullscreen mode Exit fullscreen mode

Why OpenMLS > Megolm

Feature Megolm OpenMLS
Scalability Linear key sharing Tree-based (O(log n))
Member removal Requires new session Efficient update
Formal proofs Informal analysis ProVerif, TLA+
Standard Custom IETF RFC 9420
Post-compromise security Per-sender Per-epoch

The Numbers

By not implementing Matrix federation:

Metric Impact
Protocol implementations 3 instead of 5+
Attack surface ~40% smaller
Time to MVP ~6 months saved
Dependencies Significantly fewer

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)
Enter fullscreen mode Exit fullscreen mode

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! 👇

Top comments (0)