Glossary
Matrix Protocol
An open protocol for federated chat where every participating server keeps a full copy of the room. Maintained by the Matrix.org Foundation since 2014, used by Element and adopted by several European public-sector messengers.
General definition
Matrix Protocol is an open specification for real-time communication published by the Matrix.org Foundation. Users have accounts on a homeserver; homeservers talk to each other over HTTPS through the server-server API, so a user on one can chat with users on any other, the same federated messaging idea that email uses. Clients talk to their homeserver over a JSON HTTP client-server API. The reference homeserver is Synapse (Python), with Dendrite (Go) and Conduit (Rust) as alternatives; Element is the best-known client.
What distinguishes Matrix from most chat protocols is its data model. A room is not hosted on one server. Every homeserver with a member in the room holds a replica of the room’s history as a directed acyclic graph of events, and a state resolution algorithm lets the replicas converge even after servers have been partitioned. No single server owns a room, and a room survives the loss of the server that created it. The cost is that each participating server stores and processes every event in every room it joins, which is why large public federated rooms are demanding to host.
Other defining features:
- End-to-end encryption is part of the protocol: Olm for device-to-device sessions and Megolm for group rooms, on by default in private rooms since 2020, with cross-signing for device verification
- Bridges (application services) connect Matrix rooms to other networks such as IRC, Slack, Telegram or XMPP
- Sovereign deployments: the protocol has been adopted for public-sector messengers in France and Germany, including the German healthcare sector’s TI-Messenger standard, because a state can run its own homeservers and still interoperate
Compared with XMPP, the other major open messaging protocol, the differences are architectural rather than a matter of one being better. XMPP is an IETF standard (RFC 6120 and 6121, with roots in Jabber from 1999) extended through XEPs; it routes messages between servers and each server stores only its own users’ history, which keeps per-server cost low and scales well for a single operator. Matrix is younger, replicates state across servers for resilience, and ships encryption and bridging as first-class parts of the specification. XMPP offers end-to-end encryption through OMEMO as an optional extension, so an operator can choose an archiving, auditable model instead. Both federate, both have mature open-source servers, and both have large ecosystems: Matrix’s is more concentrated around Element, XMPP’s is broader and older.
In the Ethora ecosystem
Ethora is built on XMPP, running ejabberd behind a Node.js API, and is a different kind of product from a Matrix homeserver. Matrix fits when the goal is a sovereign, federated messenger in its own right: a government, a healthcare system or a large organisation that wants to run homeservers and interoperate with others. An SDK platform fits when the goal is chat inside your own product: users you provision from your backend, web and mobile SDKs with your branding, AI agents in rooms, and server-side retention, audit trails and moderation for regulated use. Ethora’s compliance-archive design is a deliberate choice that a default-E2EE protocol makes harder to achieve.
The two are not mutually exclusive. Because XMPP federates, an Ethora deployment can run fully isolated or connect outward, and bridges exist between XMPP and Matrix where an organisation needs both. Teams evaluating a self-hosted alternative to Slack or Teams can compare both routes on the self-hosted team chat page; the honest summary is that Matrix optimises for federation and end-user privacy, and Ethora optimises for embedding, control and compliance.
