We’ve seen a serious uptick in misinformation about Element and Matrix over the last week, so thought it would be useful to set the record straight from Element’s side.
Open and Closed Federation
One of the criticisms flying around has been from Wire which seems to think that Matrix open federation is somehow intrinsically bad. It claims “moderated federation” as a superior alternative, where servers can only speak to other servers if explicitly configured. More importantly, in Wire’s case, much like typical proprietary solutions, this uses a vendor-specific protocol which vendor-locks all the deployments to Wire.
Meanwhile Matrix has always supported open federation, where servers (compatible with the Matrix open standard, no matter which vendor develops them) can talk together without having to explicitly trust each other and without explicit manual configuration. Without open federation, we wouldn’t have the Web, or email, or even the Internet itself, and Matrix aims to reach a similar level of ubiquity.
Building a healthy open federation is hard, but Matrix was built from the outset to operate in a byzantine fault tolerant manner: the fact that the network is resilient to malicious server instances is intrinsic to the protocol - just like a single malicious email server can’t take out the whole email network. Like any public space, there’s always risk of abuse - but Matrix has been making steady progress in countering abuse on the public network: https://matrix.org/blog/2025/02/building-a-safer-matrix, and much as spam is a solved problem on email these days, Matrix is improving too.
Meanwhile, Matrix obviously also supports closed (or “moderated”) federation. Many, and often the biggest, of the Matrix deployments are closed federations today (e.g. Tchap, TI-Messenger and BwMessenger). However, Tchap’s stated intent is to eventually open with the public federation - and meanwhile other major deployments like ZenDiS’s openDesk already federate on the public network. Matrix gives the best of both worlds: open federation, closed federation, or hybrids where multiple closed federations can interconnect without having to trust each other. The benefits of an open standard for federated chat are undoubtedly clear.
Wire points out that Element sells a proprietary Secure Border Gateway (SBG) product to help connect closed federations (thanks!). To be clear this is not selling “privacy as a paid feature”; it’s simply providing defence in depth for those who need it. An SBG does not provide privacy; it’s a policy engine to allow for more control over what federation traffic happens where. Element has never and will never put security or privacy behind a paywall. And because Matrix is an open standard, there are already loads of alternatives emerging for alternative border gateway implementations - e.g. every TI-Messenger deployment needs to have one, called a TI-Proxy. Most of these are not from Element.
Metadata
We also have Wire claiming that Olm/Megolm are not fit to protect sensitive information in Europe. The rationale appears to be that today’s E2EE in Matrix exposes metadata of who’s talking to who to the server admin (they also claim that Matrix’s metadata is not encrypted in transport, which is plainly false). Now, claims of exposing metadata to the server admin is incredibly hypocritical, given Wire also exposes this metadata to the server - they even spell it out in their security whitepaper:
In fact, securely managing sensitive information very often involves tracking metadata for compliance purposes, not to mention enforcing access control. Meanwhile systems like Signal which obfuscate metadata without recourse become a compliance disaster for sensitive information.
That said, it’s always good to have the option to hide metadata when needed, and there are several improvements to Matrix which protect metadata in various ways, e.g. MSC4014, MSC3414 and MSC4256, all of which are currently in active development.
Encryption
Separately, Wire claims that Olm/Megolm provides no forward secrecy or post-compromise security. Again, this is just plain false, although we won’t get into the details of why here (we expect the Matrix.org Foundation to address this in a blog post).
Now, IETF’s MLS encryption standard also provides perfect forward secrecy and post-compromise security, and performs better than Olm/Megolm when creating new message keys in large group chats. This is why Matrix, as well as Element, has been tracking and participating in MLS development since attending the inaugural MLS session at IETF101 all the way back in 2018 - highlighting its tradeoffs while experimenting with how best to implement it. More recently there’s been a new wave of “MLS mode Matrix” development driven by BWI (MSC4256), and it’s clear that Matrix is gearing to support MLS in the not-too-distant future. But happily, today’s Matrix encryption is also fit for purpose, and it’s sad to see Wire seeding fear, uncertainty and doubt against it.
Element, EU Data Privacy and other regulations
Wire also claims that because Element and The Matrix.org Foundation C.I.C are incorporated in the UK, Matrix must be somehow incompatible with EU Data Privacy law. This is false - it’s like saying that the Web must be incompatible with EU Data Privacy law because W3C and Mozilla happen to be based in the US. (Wire’s case is not helped by claiming Element is built by ‘Element Technologies Ltd’, which is a completely unrelated company.)
The whole premise and point of Matrix is that it democratises communication, providing true digital sovereignty: anyone can run Matrix servers from any vendor in whatever jurisdiction they like, respecting the local data privacy rules however is needed. The Matrix.org Foundation has zero insight or control over instance data, and likewise Element has no access or visibility over other’s instances and deployments. Obviously all of Element’s government and large public sector customers self-host so there’s no relevance talking about Element’s hosted service for SMEs.
Accusations that use of Matrix is a GDPR risk due to the Foundation being UK headquartered are ridiculous: the GDPR came into effect when the UK was still part of the EU. As such, it was fully implemented into UK law as the Data Protection Act 2018. This is still UK law and even if it wasn’t, our EU based legal entities mean both Element and Matrix are bound to comply with the GDPR anyway.
Meanwhile, vendor-locked systems like Wire are way more likely to suffer from data breaches, given all the data is managed by a single implementation provided by a single vendor, with zero recourse should that vendor suffer supply-chain attack or otherwise get compromised. It’s also ironic that Wire is incorporated in Switzerland, whose privacy laws have recently taken a very dark turn - not to mention the spectacular and unfortunate precedent of supply chain attacks on Swiss encryption companies.
Finally, anyone paying attention knows that the UK government’s Investigatory Powers Act (IPA) impacts all vendors globally which service individuals in the UK. Something that’s obvious given the high profile TCN that the UK served Apple: the fact that Element and the Matrix.org Foundation are UK-based is irrelevant.
Matrix Open Governance
Finally, there’s the claim that Matrix isn’t actually an independent open standard because it’s too dependent on Element. This is particularly frustrating, because while Element has funded the vast majority of Matrix development (being founded by the team who created Matrix precisely to fund our development on Matrix), in practice the Matrix Foundation is a genuinely independent non-profit entity and has been for years - with its own Board of Directors (Guardians) and its own independent Governing Board elected from the community. And if the Foundation is still dependent on Element’s financial support, it is only because others in the ecosystem (in particular the bigger actors building on, and using Matrix for free) are yet to step up. The Matrix Foundation is proactively finding new ways to get revenue and looking for additional financial support from the rest of the ecosystem to help reduce its financial dependence on Element.
Beyond the financial support, it is blatantly obvious from The Matrix Conference and This Week In Matrix and similar that Matrix has a large and vibrant ecosystem of independent projects and organisations building on the protocol, entirely irrespective of Element. Meanwhile Element has always been exceptionally transparent with the Matrix Foundation, especially on licensing changes designed to make Element sustainable… so that it could in turn continue to help fund Matrix - alongside all the other members who financially support the Foundation.
Why is this happening?
So, where is all of this misinformation coming from? Our best guess (based on media and customer feedback) is that it’s because the German public sector appears to be converging on Matrix as an open standard for secure communications, precisely to avoid vendor-lock in from proprietary folks like Wire (who isn’t even listed as an option).
One would hope this could be seen as an opportunity. There’s already enormous traction in Germany across different Matrix players including Element, Adesso, Akquinet, Arvato, Awesome Technologies, BearingPoint, BWI, Compugroup Medical, Connect2X, Deutsche Telekom, fairkom, Famedly, IBM, ManageNow, Secunet, Stashcat and ZenDiS - alongside communication vendors like Rocket.Chat and Mattermost that speak Matrix already.
Rather than trying to spread misinformation about Element and Matrix and build its own island, perhaps Wire would be better off building on an open standard and join the competitive market which is providing an alternative to self-interested, non-sovereign solutions rather than playing vendor-lock monopoly.
