Lupyd vs Matrix: Comparing Privacy, Federation, and Group Security

When people search for privacy-focused, sovereign alternatives to centralized giants like Slack, Teams, or Discord, Matrix.org is usually the first open standard they discover. Matrix proved that team chat does not need to be locked inside a single corporation's database. At the same time, newer cryptographic standards and zero-knowledge architectures have emerged to solve the performance and security challenges that decentralized systems face. Here is an honest, in-depth look at how Matrix and Lupyd compare, how our underlying encryption models differ, what our future federation roadmap looks like, and how Lupyd's custom extension over MLS brings mathematical permissions to group messaging.

What Is Matrix.org and Its Ecosystem?

Matrix is an open standard for decentralized, real-time communication. Governed by the non-profit Matrix.org Foundation, it defines open HTTP and WebSocket APIs that enable independent servers (called homeservers) to federate with one another, much like how email works across different providers.

In the Matrix architecture:

• Homeservers: Users register on a specific homeserver (such as matrix.org, or a self-hosted instance running Synapse, Dendrite, or Conduit). The homeserver stores their account data, manages room states, and handles communication with other servers.
• Federation: When a user on Server A joins a room hosted by a user on Server B, the two servers federate. Every event (message, reaction, membership change) is synchronized across all participating homeservers as an append-only Directed Acyclic Graph (DAG).
• Bridges: Matrix features an extensive ecosystem of bridges connecting rooms to external networks like IRC, XMPP, Slack, Discord, and Telegram.

The Matrix Client Ecosystem: Element, Cinny, and FluffyChat

Because Matrix is an open protocol rather than a single closed app, users can choose from a vibrant variety of independent clients, all connecting to the same underlying network:

Other specialized clients like Hydrogen (a lightweight web client built for constrained hardware) and weechat-matrix (for command-line terminal power users) demonstrate the breadth and power of an open protocol ecosystem.

Olm/Megolm vs. MLS: How Encryption Compares

Security in any messaging system is defined by its cryptographic foundation. Matrix and Lupyd take fundamentally different approaches to protecting group discussions:

Matrix: Olm and Megolm

Matrix uses two cryptographic protocols developed by the Matrix team:

• Olm: An implementation of the Double Ratchet protocol (similar to Signal) used for direct 1-to-1 conversations and key exchanges between individual devices.
• Megolm: An out-of-band group ratchet protocol. Instead of ratcheting pairwise between every single device in a 1,000-person room, the sender generates a group session key, ratchets it forward with AES-256 for each message, and shares that session key via encrypted Olm channels to every recipient device in the room.

While Megolm was a breakthrough when Matrix launched in 2015, it introduces notable operational and cryptographic challenges:

• "Unable to Decrypt" Errors: If a device is offline, if federation packets arrive out of order, or if historical room key requests fail across federated servers, recipients are frequently left looking at gray placeholder errors saying "Waiting for this message, this may take a while" or "Unable to decrypt".
• Limited Post-Compromise Security: If an attacker compromises a participant's device and extracts the active Megolm session key, they can decrypt all subsequent messages sent within that session until a key rotation event is triggered (e.g., when a user leaves).
• Historical Key Forwarding Risk: To let new devices read older messages, Matrix clients can export or forward room keys. While convenient, this practice weakens strict forward secrecy guarantees.

Lupyd: IETF Messaging Layer Security (MLS)

Lupyd builds directly upon IETF Messaging Layer Security (RFC 9420), the modern open cryptographic standard finalized in 2023 by leading cryptographers from across the security industry.

Rather than relying on out-of-band group session distribution, MLS organizes all member devices into a balanced binary tree (TreeKEM). Every node in the tree represents an intermediate cryptographic key, culminating in a single shared group secret:

• Continuous Epoch Ratcheting: Whenever a member updates their key, leaves, or joins, only logarithmic updates (O(log N)) are broadcast to update the tree. All devices advance their cryptographic state synchronously to the next epoch.
• Strict Post-Compromise Security (PCS): If a device key is compromised, the very next epoch commit generated by that device or any other member mathematically cuts off the attacker from future communications.
• Unified Multi-Device Representation: In Lupyd's Firefly engine, each user device is represented as a distinct leaf in the group tree. Messages are encrypted exactly once to the epoch key and broadcast to all devices simultaneously, eliminating decryption race conditions.

Lupyd's Custom MLS Extension: Flexible Roles & Permissions

One fundamental limitation of standard MLS (RFC 9420) is that it focuses purely on cryptographic group membership and key agreement: it defines how to add, remove, and update members securely, but it deliberately omits application-layer governance. Standard MLS has no native concept of "who is allowed to kick", "who can send messages in an announcement channel", or "who holds the Moderator or Admin role".

In conventional messaging platforms, and even in federated systems where room power levels are tracked in server-replicated state events, permissions are enforced by server software. If a server is compromised, misconfigured, or running rogue software, it can alter user privileges or bypass moderation rules in the database.

To solve this, Lupyd and Firefly developed a custom cryptographic extension directly on top of the MLS protocol:

Federation: Matrix Today, Lupyd's Decentralization Roadmap

A central question users ask when comparing the two platforms is: "Can I self-host my server and connect to anyone else?"

Where Matrix Stands Today

Matrix has a proven, functioning federation system. Anyone can deploy an open-source homeserver (like Synapse or Conduit) on their own VPS, assign a custom domain, and immediately participate in global rooms with millions of users across thousands of other independent servers. If open server-to-server federation today is your absolute, non-negotiable requirement, Matrix provides an established answer.

Where Lupyd Stands Today & Our Future Roadmap

Lupyd currently operates using high-performance zero-knowledge blind relays. Messages are encrypted end-to-end on client devices using Firefly's MLS engine, and the relay server simply forwards opaque ciphertext packets without knowing room identities, user real-names, or message contents.

However, we do not believe private messaging should stay confined to centralized infrastructure. Lupyd cum Firefly has concrete, active plans for full federation and decentralization in our future architecture.

Our roadmap outlines a distinct approach to decentralization:

1. Federated Blind Relays: Enabling organizations to host their own Lupyd relay nodes that exchange ciphertexts across domains without exposing room topology or metadata.
2. Decentralized Cryptographic Identity: Decoupling user identities from phone numbers and centralized domain registrars, enabling sovereign device key verification.
3. Zero-Metadata Consensus: Ensuring that cross-node federation does not replicate massive, unencrypted DAG graphs across untrusted intermediary servers.

Server Architecture & Metadata: Heavy DAGs vs. Blind Relays

Decentralization comes with technical tradeoffs, particularly regarding resource consumption and metadata privacy:

Architectural Comparison: Lupyd vs. Matrix

Here is a side-by-side summary of how both systems approach security, infrastructure, and user control:

Where We Stand: Finding the Right Balance

Matrix paved the way for open, decentralized communications. If your organization requires an established, federated network today with bridges into IRC, Discord, and Slack, Matrix and its client ecosystem (Element, Cinny, FluffyChat) offer an extraordinary and mature toolkit.

However, if your priority is mathematical data privacy, instantaneous multi-device reliability without decryption errors, and cryptographically enforced role governance that even a server administrator cannot manipulate, Lupyd and Firefly represent the next step in private messaging.

We invite you to follow our engineering progress, inspect our open repositories on GitHub, and track our journey toward decentralized, zero-knowledge federation on our public roadmap.