General

We’ve seen several articles published in the last week that are, at best, misinformed, and at worst, attempts to protect a single communication company’s bottom line by attacking Matrix.

We thought we should take the time to set the record straight, lest anyone be taken by this naked attempt to sow fear, uncertainty, and doubt (FUD).

But before we do, let’s be clear: this is not the first time a single vendor open source project – which may be under an open source license but is unilaterally controlled by a single for-profit company – has resorted to desperate measures to attack their community-driven competitors, and it won’t be the last time.

Matrix is not just an open standard for secure communication, it’s an openly governed and collaboratively developed ecosystem of projects powered by a growing community of volunteers and vendors. In this way, Matrix exemplifies the open source ethos, encourages greater innovation, and defies those who would try to build businesses based on extractive behavior and vendor lock-in.

🔗Governance & legal allegations

🔗Neutral and independent stewardship

The claim has been made that Matrix is effectively controlled by one company. It’s a bold claim, especially when it comes from a for-profit that exerts unilateral control over their eponymous open source project – and it’s patently false.

Open source is one of those terms that has become overloaded with meaning. Something can be accurately described as “open source” when it’s placed under a license that’s been approved by the Open Source Initiative. However, colloquial use of “open source” tends to imply that something is open source licensed, has an open collaboration model, is guided through open governance, and housed within a neutral nonprofit entity.

Matrix is open source in the fullest sense of the word.

The Matrix protocol is open source, and it evolves through the Matrix Spec Change process. Anyone can submit a proposal, and anyone can help vet those proposals. The Spec Core Team, a volunteer body made up of people with a range of expertise and several different employers, facilitates this process, merges in successful proposals, and manages new releases of the specification.

And the Spec Core Team is just one of the multi-member volunteer bodies that govern Matrix under the auspices of an explicitly not-for-profit legal entity. The other body is the Governing Board, the most recent evolution in our open governance.

The Governing Board is an elected body of representatives from multiple constituencies: those who build projects with Matrix, those who use Matrix, and those who fund Matrix.

The Governing Board provides input to the Spec Core Team, has a role in approving budgets, major expenses, and any new revenue sources the Matrix.org Foundation may seek to pursue. It also has leeway to venture into all manner of subject matter, and it does so through its committees and working groups, which span Trust & Safety, Governance, Events, Finance, and more.

Speaking of the Matrix.org Foundation, it’s a not-for-profit corporate entity that is legally bound to the community benefit described in its mission statement. It holds community assets, such as software projects that are foundational to the ecosystem and the Matrix trademark, so that participants and downstream users can be confident those will not be withdrawn or leveraged against them for the benefit of a single company. It is also required to submit annual reports with an overview of its financial accounts and activities.

Further, the Foundation has a dedicated staff that I, Robin Riley, currently lead as an independent Managing Director, and I have a track record of fighting moneyed interests to protect the open source commons – and, critically, I have no financial stake in any Matrix vendor.

I have not only done the work of operationalizing open governance, I have also been hard at work behind the scenes separating out the Foundation’s infrastructure – which was previously completely subsidized by Element – and fundraising so that it is increasingly independent and self-sustaining.

Some may point to Element’s relicensing of Synapse as proof positive that the Foundation is not independent, but there’s nothing stopping anyone from doing the same with permissively licensed software from other open source foundations – something that happens frequently – and no one is claiming those foundations are not independent.

Some may point to the Foundation’s move to monetize the matrix.org homeserver, which is indeed operated under contract by Element, as evidence that the Foundation is in trouble. But seen in the cool light of the day and in context of the facts, this is simply a move to help close a budget gap that has been openly discussed for several years. It may also contribute to de-centering the homeserver and give rise to more community operated alternatives. We’d rather try to defray the cost of operating the homeserver than let it impact our ability to continue facilitating ever more open governance and collaboration.

It is true to say that Matrix has further to go in its open governance journey and on the path to full independence and sustainability.

However, if one surveys the landscape of open source foundations, it becomes clear that these are journeys that are measured not just in years, but in decades. And whereas some projects get further enclosed and less democratic over time, there’s a fact pattern here that shows Matrix is getting ever more open, independent, and collaborative.

🔗Legal allegations

It has been suggested that because the Matrix.org Foundation is incorporated in the UK, Matrix is incompatible with EU Data Protection laws, like the GDPR, and subject to the Investigatory Powers Act (IPA) in the UK.

Well, the GDPR is a regulation governing the use of personal data which predates Brexit and is fully incorpoorated and implemented in UK law as part of the Data Protection Act 2018. Whilst it recommends things like Privacy by Design and other requirements which influence software development, it does not directly govern it. Any code written in the UK and hosted (or used by people) in the EU will have to be compliant with EU legislation – this is the beauty of an open standard which supports digital sovereignty.

Second, jurisdictional exposure related to cases like Schrems II is associated with data transfers to third-countries. The UK is not a third-country, it currently has an adequacy decision which has just been extended. Yes, there is a risk that this adequacy decision might be revoked and we even agree with some of the concerns raised in the linked article about some of the recent decisions in the UK – again, we have been incredibly vocal about most of the concerns raised and continue to work on these topics, including the risk of TCNs.

And finally, the Investigatory Powers Act (IPA) is a piece of legislation in the UK focused on governing investigatory powers and law enforcement which has been in place since 1998. The UK government can apply IPA globally to individuals based in the UK, as per the Technical Capability Notice (TCN) it has served Apple, so whether you are using Matrix (governed by a UK-based Foundation) or not is irrelevant.

In the end, of all the technologies, Matrix is one of those that are the best positioned to give the users their digital sovereignty and data protection, thanks to its open source and decentralised nature.

🔗Technical allegations

🔗On the relevance of Matrix’s open federation for private deployments

With the open Matrix network including 180 million addressable users and hosting a wide variety of players, not all with good intentions, we are facing a clear challenge of ensuring this open network is kept safe for our users, and it is a primary focus for the Foundation.

On the other hand, Matrix is also widely used by governments and public sector organisations, which have all deployed their own private federations, potentially connecting them to one another via appropriate Secure Border Gateways (SBG) and enforcing strict access control, in order to maintain the security of their deployments and to prevent access from unauthorised users. Several organisations develop SBGs, some being commercial and proprietary (like Element’s) and other freely available open-source (like DINUM’s). Gematik also specifies a TI-proxy (SBG) for TI-Messenger, although it doesn't develop an implementation. SBGs are policy controllers rather than privacy enforcers.

All these deployments are integrated to appropriate single-sign one setups and the public Matrix.org homeserver also mandates either email or a social log-in to validate the account.

It is also worth noting that the fact the federation is open or closed is orthogonal to whether the deployment is scalable or not. The scalability is determined by the server implementation which is used, and there is no limit to how many servers can federate with one another. Meanwhile the French government’s Tchap Matrix installation is a private federation of around 350K active users. Bundeswehr’s Matrix-based BwMessenger private federation supports 100K+ users. Gematik’s (Matrix-based) TI-Messenger private federation will support literally millions of German citizens.

Being a decentralised network, Matrix was designed to be Byzantine Fault Tolerant, resilient to malicious instances by design. In an open federation, malicious actors can spin up rogue homeservers and interact with legitimate ones but they can’t harm the legitimate ones, beyond spam attacks, which (again) is a failure mode with a lot of focus from the Foundation’s Trust and Safety team today. Meanwhile there are also plenty of options around content scanning and anti-virus to protect private federations, whether that’s from various Matrix vendors, FOSS or in-house development.

🔗On end-to-end encryption

Matrix is encryption agnostic and today uses Olm, its own implementation of the Signal protocol, with Megolm for group scalability. Whilst Olm is now mature and well-understood end-to-end encryption (developed and used by Signal, and used by WhatsApp, Facebook Messenger and others) it does have some scalability limitations for very big group chats (tens of thousands of users). Meanwhile, IETF’s MLS standard (RFC9420) provides better scalability in exchange for some tradeoffs around centralisation - work continues apace on how to best integrate MLS with Matrix (e.g. MSC4256 and MSC4244, and all our existing work at https://arewemlsyet.com).

We’ve seen claims that Matrix lacks forward secrecy today, which is plain false: Olm provides perfect forward secrecy by nature of being an implementation of the Signal Protocol - if an attacker captures the current keys they can’t decrypt previous messages.

Similarly, if an attacker captures the current keys they also can’t decrypt future messages - this provides post-compromise security. Olm is used to share the “Megolm” keys used to encrypt messages, and similarly, if you capture a Megolm key you cannot decrypt any previous messages. By default a given Megolm key is used to generate keys for up to 100 consecutive messages, but this is configurable, and is reset whenever the group membership changes or after a week. Nothing stops an admin from rotating on every message if they like: https://spec.matrix.org/v1.14/client-server-api/#mroomencryption

Practically speaking almost all Matrix clients keep all the Megolm keys (to read back history), because users of a chat application (especially in a collaboration context) expect history to be accessible. Though there is nothing inherent in Matrix that would prevent throwing the keys away on ratchet.

🔗On metadata availability

Matrix currently exposes the metadata of who’s talking in which rooms to the admins of the servers whose users are in a given conversation. It is transport encrypted and random (non-participating) network observers most certainly cannot access it nor “easily” track users across conversations.

We are in the process of minimising metadata by default (e.g. MSC4014 exists and was implemented in Dendrite) but it’s worth noting that sometimes metadata is a requirement: in practice a lot of professional Matrix users (i.e. large government installations) often actually want to know who’s talking to who on their servers for compliance and access control reasons. Meanwhile other approaches are in flight right now, e.g. BWI’s MSC4256.

It is worth noting that other collaboration apps who claim to be more secure than Matrix are hitting the same problem of having to be compliant when selling to the public sector. For example, Wire's privacy whitepaper directly states their servers have access to the group participant lists and leaks the conversation’s name to the server. Besides the MLS RFC (RFC9420, section 16.4, used by Wire) clearly states MLS itself does not intrinsically provide confidentiality to a large subset of messages and that a party observing these (i.e. the delivery service = Wire's backend servers) can infer group membership.

🔗Why?

All in all, it sounds like the German public sector appearing to be converging on Matrix as an open standard for secure communications has triggered some defensive reaction with other European players in the market. It is a shame that small European players feel the need to fight one another rather than collaborate via open source software against the bigger non-European and proprietary players.

🔗TL;DR

As we need to take more concrete steps to improve the financial situation of the Foundation, we will be rolling out a freemium offer for the matrix.org homeserver users. The alternative is to turn off the server, which we want to avoid doing. The goal is for the most active users to support the cost of the service. Free users will have limits on how they can use the service (mostly around media). The change can be supported by any client with limited to no development. Premium plans will be rolled out over the summer, and we will be iterating on the exact scope in the first few weeks. The Homeserver Terms and Privacy Policy will be updated accordingly and deployed in the coming weeks.

Continue reading…

Last week, we shared details about ongoing attacks on Matrix. Over the past week or so, we’ve tested some new tooling to help combat abuse on matrix.org.

If you run your own Synapse server and your users are present in the Foundation’s community rooms, you can benefit from this tooling by installing an experimental Synapse module. You can find the code and installation instructions here. We’re deliberately taking the bold step of announcing a tool and also announcing its deprecation in the same post. This is experimental work, and we are iterating quickly. We expect to have an implementation in Synapse shortly, so the module will be discontinued around May 21.

🔗What are policy servers?

Policy servers are an overlapping layer of protection with existing community moderation tools such as Draupnir, Mjolnir and Meowlnir. Rooms can opt-in to this new layer of protection, recommending that servers participating in the room check events with a given policy server before they are sent to their clients. The policy server will pass an opinion on each event, recommending servers in the room to accept the event, or to reject it. For people in the room, this should be effectively invisible. Events which pass the check will be shown as normal, while ones which don’t will never make it through to their clients.

The Foundation intends to offer a policy server to room admins, but we hope that in time other providers will offer alternative policy servers. The Foundation is already running an experimental implementation for some of its public rooms, which we will release once we have confidence in the approach. We also expect that for many rooms, a policy server isn’t necessary, or spends most of the time in a low-power or disabled state. Element and the Foundation are exploring these ideas over the coming weeks.

🔗Get involved

MSC4284 is now open to support this work. Please get involved in the MSC, and help us to improve this addition to safety tooling for the network. We’d especially like to see implementations for non-Synapse servers.

Folks who run communities on Matrix who would like to test our policy server, reach out to us at [email protected], using the subject policy-server-alpha.

After a successful 2024 with a lot to be proud of, and a Matrix Conference that brought our community together to celebrate 10 years of Matrix, we step into 2025 with a light budget and a mighty team poised to make the most of it!

Our priorities remain to make Matrix a safer network, keep growing the ecosystem, make the most of our Governing Board, and drive a fruitful and friendly collaboration across all actors.

However, whether we will manage to get there is not fully a given.

Continue reading…

As of yesterday, Matrix.org is using a curated room directory. We’re paring down the rooms that are visible to a collection of moderated spaces and rooms. This is an intervention against abuse on the network, and a continuation of work that we started in May 2024.

In early 2024 we noticed an uptick in users creating rooms to share harmful content. After a few iterations to identify these rooms and shut them down, we realised we needed to change tack. We landed on first reducing the discoverability and reach of these rooms - after all, no other encrypted messaging platform provides a room directory service, and unfortunately it can clearly serve as a mechanism to amplify abuse. So, in May 2024 we froze the room directory. Matrix.org users were no longer permitted to publish their rooms to the room directory. We also did some manual intervention to reduce the size of the directory as a whole, and remove harmful rooms ahead of blocking them.

This intervention aimed at three targets:

• Lowering the risk of users discovering harmful rooms
• Stopping the amplification of abuse via an under-moderated room directory
• Reducing the risk for Matrix client developers for app store reviews

In truth, the way room discovery works needs some care and attention. Room directories pre-date Spaces, and some of the assumptions don't hold up to real world use. From the freeze, and the months since, we've learned a few things. First, the criteria for appearing in a server's room directory in the first place is way too broad. Also, abuse doesn't happen in a vacuum. Some rooms that were fine at the time of the freeze, are not now. There are a few different causes for that, including room moderators losing interest. We looked for criteria to give us the confidence in removing the freeze, and we hit all the edge cases that make safety work so challenging.

Those lessons led to a realization. One of the values of the Foundation is pragmatism, rather than perfection. We weren't living up to that value, so we decided to change. The plan became simpler: move to a curated list of rooms, with a rough first pass of criteria for inclusion. In parallel, we asked the Governing Board to come up with a process for adding rooms in the future, and to refine the criteria. We've completed the first part of the plan today.

🔗What comes next

There's plenty of scope for refinement here, and we've identified a few places where we can get started:

• The Governing Board will publish criteria for inclusion in the Matrix.org room directory. They'll also tell you how you can suggest rooms and spaces for the directory.
• We're going to recommend safer defaults. Servers should not let users publish rooms unless there are appropriate filtering and moderation tools in place, and people to wield them. For instance, Element have made this change to Synapse in PR18175
• We're exploring discovery as a topic, including removing the room directory API. One promising idea is to use Spaces: servers could publish a default space, with rooms curated by the server admin. Our recent post includes some other projects we have in this area: https://matrix.org/blog/2025/02/building-a-safer-matrix/

🔗FAQs

What criteria did you use for this first pass?
We used a rough rubric: Is the room already in the room directory, and does the Foundation already protect the room with the Matrix.org Mjolnir? From there, we extended to well-moderated rooms and spaces that fit one of the following:

• Matrix client and server implementations (e.g. FluffyChat, Dendrite)
• Matrix community projects (e.g. t2bot.io)
• Matrix homeserver spaces with a solid safety record (e.g. tchncs.de, envs.net)

Why isn't the Office of the Foundation in the directory?
It didn't exist before May 2024, so the Office has never been in the directory. We're going to add it in the next few days, with a couple of other examples that fit our rough rubric.

How do I add my room/space to the list?
At the moment, you can't. The Governing Board will publish the criteria and the flow for getting on the list.

What do I do if I find a harmful room in the current directory?
You shouldn't, but if a room does have harmful content, check out How you can help

N.B. this post is also available in German below.

🔗Introduction

Right now, the world needs secure communication more than ever. Waves of security breaches such as the “Salt Typhoon” compromise of the telephone network’s wiretap system have led the FBI to advise US citizens to switch to end-to-end-encrypted communication. Geopolitical shifts painfully highlight the importance of privacy-preserving communication for vulnerable minorities, in fear of being profiled or targeted. Meanwhile the International Rules-Based Order is at risk like never before.

We built Matrix to provide secure communication for everyone - to be the missing communication layer of the Open Web. This is not hyperbole: Matrix is literally layered on top of the Web - letting organisations run their own servers while communicating in a wider network. As a result, Matrix is “decentralised”: the people who built Matrix do not control those servers; they are controlled by the admins who run them - and just as the Web will outlive Tim Berners-Lee, Matrix will outlive us.

Matrix itself is a protocol (like email), defined as an open standard maintained by The Matrix.org Foundation C.I.C - a UK non-profit incorporated in 2018 to act as the steward of the protocol; to coordinate the protocol’s evolution and to work on keeping the public Matrix network safe. The Foundation is funded by donations from its members (both individuals and organisations), and also organises the Matrix.org homeserver instance used by many as their initial home on the network.

Much like the Web, Matrix is a powerful technology available to the general public, which can be used both for good and evil.

The vast majority of Matrix’s use is constructive: enabling collaboration for open source software communities such as Mozilla, KDE, GNOME, Fedora, Ubuntu, Debian, and thousands of smaller projects; providing a secure space for vulnerable user groups; secure collaboration throughout academia (particularly in DACH); protecting healthcare communication in Germany; protecting national communication in France, Germany, Sweden and Switzerland; and providing secure communication for NATO, the US DoD and Ukraine. You can see the scope and caliber of the Matrix ecosystem from the talks at The Matrix Conference in September.

However, precisely the same capabilities which benefit privacy-sensitive organisations mean that a small proportion of members of the public will try to abuse the system.

We have been painfully aware of the risk of abuse since the outset of the project, and rather than abdicating responsibility in the way that many encrypted messengers do, we’ve worked steadily at addressing it. In the early days, even before we saw significant abuse, this meant speculating on approaches to combat it (e.g. our FOSDEM 2017 talk and subsequent 2020 blog post proposing decentralised reputation; now recognisable in Bluesky’s successful Ozone anti-abuse system and composable moderation). However, these posts were future-facing at the time - and these days we have different, concrete anti-abuse efforts in place.

In this post, we’d like to explain where things are at, and how they will continue to improve in future.

🔗What we do today

The largest use of our funding as a Foundation is spent on our full-time Safety team, and we expanded that commitment at the end of 2024. On a daily basis, the team triage, investigate, identify and remove harmful content from the Matrix.org server, and remove users who share that material. They also build tooling to prevent, detect and remove harmful content, and to protect the people who work on user reports and investigations.

The humans who make up the Foundation Trust & Safety team are dedicated professionals who put their own mental health and happiness in jeopardy every day, reviewing harmful content added by people abusing the service we provide. Their work exposes them to harms including child sexual exploitation and abuse (CSEA), terrorist content, non-consensual intimate imagery (NCII), harassment, hate, deepfakes, fraud, misinformation, illegal pornography, drugs, firearms, spam, suicide, human trafficking and more. It’s a laundry list of the worst that humanity has to offer. The grim reality is that all online services have to deal with these problems, and to balance the work to detect and remove that content with the rights of their users. We’re committed to that work, and to supporting the Trust & Safety team to the best of our ability — we are very grateful for their sacrifice.

Continue reading…

Hi all,

Once again we celebrate the end of another year with the traditional Matrix Holiday Special! (see also 2023, 2022, 2021, 2020, 2019, 2018, 2017, 2016 and 2015 just in case you missed them).

This year, it is an incredible relief to be able to sit down and write an update which is overwhelmingly positive - in stark contrast to the rather mixed bags of 2022 and 2023. This is not to say that things are perfect: most notably, The Matrix.org Foundation has not yet hit its funding goals, and urgently needs more organisations who depend on Matrix to join as members in order to be financially sustainable. However, in terms of progress of Matrix towards outperforming the centralised alternatives; growth of the ecosystem; the success of the first ever Matrix Conference; we couldn’t be happier - and hopefully the more Matrix matures, the more folks will want to join the Foundation to help fund it.

So, precisely why are we feeling so happy right now?

Continue reading…

The Matrix.org Foundation has been made aware that an international investigative operation took down a service called MATRIX which was used by a cybercriminal network, which has no relationship with the Matrix.org Foundation or the Matrix protocol itself.

The takedown site has a Matrix-the-movie branding, which is a probable source of confusion. The app showcased doesn’t look like any of the Matrix clients we’re aware of.

In a statement to the Matrix.org Foundation, Europol confirmed that the MATRIX cybercriminal network and the Matrix protocol are entirely unrelated. Europol states:

The Matrix protocol (matrix.org) is by no means connected to the Matrix secured communication service that was targeted in OTF Continental.

A statement from the Dutch police confirms that this is unrelated: "Matrix is ​​also the name of a company and communications protocol of the same name, which has nothing to do with the crypto communications service Matrix."

Hi all,

Since the outset of Matrix, our aim has always been to provide a protocol that lets you build open, decentralised, secure communication apps which outperform the mainstream centralised alternatives. It’s been a twisty journey - first focusing on making Matrix work at all (back in 2014), and then getting it out of beta with Matrix 1.0 in 2019, and now focusing on making Matrix fast, usable and mainstream-ready with Matrix 2.0.

Meanwhile, the pendulum of decentralisation continues to accelerate in our direction. Our friends at Bluesky have shown that it’s possible to build decentralised social apps which are mainstream friendly enough for Presidents to recommend them; Elon continues to destroy Twitter and showcase the importance of decentralisation to everyone, and even Meta is dabbling in decentralised social media (and decentralised communication!)

So, where does Matrix sit in all this? Well, in order to make the transition to mainstream, we’ve been beavering away to implement four main pillars in Matrix 2.0:

1. Instant login, instant launch, and instant sync (aka Simplified Sliding Sync, MSC4186)
2. Next Generation Auth (aka Native OIDC, MSC3861)
3. Native Matrix Encrypted Multiparty VoIP/Video (aka MatrixRTC, MSC4143)
4. Invisible Encryption (MSC4153 & friends).

Continue reading…

Hi all,

2023 has been a pivotal year for Matrix, with huge changes landing both organisationally and technically to prepare the protocol for future generations. The ecosystem has once again gone from strength to strength, with active users (based on Synapse opt-in phone-home reporting) doubling across the public network, and more projects building on Matrix than we can count (look out for the “This Year in Matrix” community wrap-up blog post) - and more organisations than we can track joining Matrix for all their secure decentralised communication needs.

On the governance side, we are in an incredibly exciting new era with Josh joining the Matrix.org Foundation as its first ever Managing Director (and employee!), with a mandate to cement sustainable funding for Matrix as an independent foundation, governed by the forthcoming elected open Governance Board. Now, Matrix needs funding more than ever - but rather than turning the entirety of this post into a plea for donations, I’m going to let Josh fly the flag in the coming weeks. Meanwhile, if you want Matrix to keep existing (especially if you’re an organisation who builds on Matrix) please join the Foundation and donate.

On the technical side: the theme of the year has been one of focus: extreme, overdue, focus.

Continue reading…