Français
When choosing a messaging service, the issue of privacy comes up constantly. It deserves more than a marketing‑flavored answer. Matrix, an open‑source decentralized communication protocol, promises private, secure instant conversations, following the line of secure‑communication solutions. But are Matrix chat conversations really private? The answer is nuanced: yes, under certain conditions, and no if you ignore some critical parameters. Encryption exists, it is strong, but it does not cover everything. Metadata, bridges to other platforms, the choice of server : every link in the chain can strengthen or weaken your privacy. After using Matrix for several years, configuring servers and testing its limits, here’s what you need to know concretely. No vague promises: technical facts, identified risks and practical solutions for those who truly want to protect their exchanges in an open‑source environment.
How Matrix Works and Its Encryption Protocol
Matrix is built on an open protocol, publicly documented and auditable by anyone, just like the technologies championed by the free‑software community. Unlike proprietary services such as WhatsApp or iMessage, the source code is accessible. This means security researchers can verify privacy claims, and they do so regularly, thanks to the active involvement of the open‑source community that continuously improves the protocol. The protocol defines how messages travel between servers (called “homeservers”) and how encryption is applied to chat rooms.
The most widely used client for accessing the Matrix network is Element, available on all platforms. But Matrix is not Element: it is a protocol, and other clients exist (FluffyChat, Nheko, SchildiChat). Encryption is handled at the protocol level, which means that regardless of the client you use, the cryptographic guarantees remain the same, provided the client follows the specification.
End‑to‑End Encryption with Olm and Megolm
End‑to‑End Encryption (E2EE) on Matrix relies on two cryptographic libraries: Olm for one‑to‑one exchanges and Megolm for group conversations. Olm implements the Double Ratchet protocol, the same principle used by Signal. Each message is encrypted with an ephemeral key, guaranteeing forward secrecy: even if a key is compromised, past messages stay unreadable.
Megolm adapts this mechanism to group rooms, where encrypting a message individually for every participant would be too costly. A shared session key is used and rotated regularly. This system has been audited by independent firms, notably NCC Group in 2016 and in later audits. Vulnerabilities were found and patched, which is a sign of good health for an open‑source project.
A crucial point: E2EE has been enabled by default for private chats since 2020. For public rooms it remains disabled by default, which makes sense because those rooms are meant to be accessible to anyone.
Device Verification to Prevent Man‑in‑the‑Middle Attacks
Encryption is useless if you cannot verify you are talking to the right person. Matrix includes a cross‑device verification mechanism based on emoji exchanges or QR‑code scanning. Concretely, when you verify a contact you confirm that their cryptographic keys match their physical device.
Without this verification, a "man‑in‑the‑middle" attack remains theoretically possible: a compromised server could inject forged keys. Cross‑verification blocks this scenario. In practice, few users take the time to verify their contacts, which is the main human weakness of the system. If you take privacy seriously, this step is non‑negotiable.
Data Sovereignty and Decentralised Architecture
Matrix’s architecture fundamentally differs from Signal or Telegram. There is no single central server: the network consists of thousands of independent servers that federate with each other. This federation means no single entity controls the whole network. It is a considerable advantage for resilience and digital sovereignty, but it also introduces important nuances.
Self‑Hosting: Regaining Full Control of Your Servers
The most protective option is to host your own Matrix server. With Synapse (the reference implementation) or Dendrite (lighter), you can install a homeserver on your own infrastructure. This means your encrypted messages, metadata, shared files, everything, stays on your machine or on a hosting provider you have chosen, in a sovereign‑cloud mindset.
For a French company worried about GDPR compliance, this is a strong argument. You know exactly where your data are stored, who can access them, and you can enforce your own retention policies. The French government understood this: the Tchap project, the messaging service for public‑service agents, runs on Matrix with servers hosted in France.
Self‑hosting requires technical skills and ongoing maintenance, but turnkey solutions exist, notably through open‑source services offered by specialised providers such as LINAGORA.
Server Federation and Message Replication
Federation comes at a privacy cost. When a user on server A sends a message in a room hosted on server B, a copy of that message (encrypted, of course) is stored on both servers. If the room includes participants on ten different servers, ten copies exist, each potentially residing on an open‑source server.
The content stays encrypted and unreadable to server administrators. However, the fact that a message exists, its timestamp, the sender’s identifier, these pieces of information are replicated. For highly sensitive conversations, the solution is to restrict federation. A server can be configured in “closed” mode, communicating only with trusted servers, or even operating in complete isolation, especially in sovereign‑hosting environments.
Metadata Management on the Network
Encryption protects content, not context. This distinction is fundamental and often underestimated. Metadata, who talks to whom, when, how often, in which rooms, can reveal as much information as the message content itself. Studies have shown that metadata analysis can reconstruct social graphs, habits and even intentions.
What Information Remains Visible to Server Administrators?
A Matrix homeserver administrator can see several categories of metadata:
- User IDs (e.g., @user:server.fr)
- Names of rooms a user has joined
- Message timestamps
- Connection IP addresses
- Device information
- Encrypted E2EE message bodies remain opaque, but everything else is accessible.
On the public matrix.org server, run by the Matrix Foundation, these data are covered by a published privacy policy. However, if you use a third‑party server run by an unknown operator, you entrust them with that metadata without any guarantee. Hence, the choice of server is as important as encryption itself. Hosting your own server or picking a trusted one drastically reduces this risk, especially through collaboratively‑controlled solutions.
Privacy When Using Bridges
Bridges are one of Matrix’s most attractive features: they let you communicate with WhatsApp, Signal, Telegram, Slack or Discord users directly from your Matrix client. On paper, this is the dream of interoperability. In practice, it is the point where privacy degrades the most.
Risks of Interoperability with WhatsApp, Signal or Telegram
When a bridge relays a message between Matrix and WhatsApp, the message must be decrypted on the bridge before being re‑encrypted for the other platform. Consequently, the bridge sees the clear‑text content. This is an unavoidable compromise: two incompatible encryption systems cannot talk without an intermediary that translates.
Serious implications:
- The server hosting the bridge has access to the clear‑text content of the messages in transit.
- Metadata from both platforms are merged at a single point.
- If the bridge is hosted by a third party, you are trusting them with your decrypted messages.
- The remote platform’s privacy policy also applies (e.g., WhatsApp shares data with Meta).
To mitigate damage, host your own bridges. Solutions such as mautrix‑whatsapp or mautrix‑telegram can run on your infrastructure. The risk is not eliminated, but it is controlled.
Comparison: Matrix vs. Centralised Solutions
Signal is often cited as the privacy benchmark. Its encryption is superb, and its metadata footprint is minimal. Yet Signal relies on a single central server, requires a phone number and does not allow self‑hosting. If Signal were to shut down tomorrow, the service would disappear.
Telegram, despite its popularity, does not enable end‑to‑end encryption by default. Classic chats are readable by Telegram. WhatsApp encrypts messages but harvests massive amounts of metadata for Meta.
Matrix positions itself differently. Its encryption is comparable to Signal’s, decentralisation eliminates a single point of failure, and self‑hosting offers total sovereignty. The trade‑off lies in configuration complexity and metadata handling, which demand active attention. For a user who simply installs Element and joins matrix.org without any tweaks, privacy is decent but not maximal. For an organisation that hosts its own server, verifies devices and avoids bridges, Matrix provides one of the highest protection levels available, especially in open‑source collaborative messaging environments.
Verdict : How to Maximise Privacy on Matrix
Matrix instant‑messaging privacy is not binary. It depends directly on the choices you make. The protocol supplies solid tools, but your configuration determines the final outcome.
To get the most out of Matrix for privacy, follow these concrete actions:
- Host your own server or choose one run by a trusted entity.
- Verify contacts’ devices systematically via cross‑verification.
- Enable E2EE on every room, including group rooms.
- Avoid bridges for sensitive conversations, or host them yourself.
- Use a VPN or Tor to hide your IP address from the server.
- Configure retention policies to automatically delete old messages.
Matrix is not a magic solution. No messenger is. But it is one of the few systems that actually gives you the technical means to control your privacy ,provided you actively seize those tools, preferably with the help of specialised open‑source actors and open‑source services.
