General

Hi all,

2025 has been another bumper year for Matrix, and I’m happy to say that we’re ending it on a distinctly positive note.

Frankly, it feels like the gamble to secure the future of Matrix may be paying off. We’re seeing more and more uptake of Matrix in the wild, especially in massive public sector deployments like ZenDiS’s openDesk in Germany and the European Commission; we’re now tracking over 25(!) countries who are actively deploying Matrix in order to maintain true digital sovereignty over their communication - and we’re at the point where dedicated Matrix vendors like Element are starting to get sustainable, allowing them in turn to contribute more to the Foundation and the development of the protocol and ecosystem.

On the other hand, the Foundation itself is still not independently sustainable yet: while memberships have doubled over the last year, work on independently safeguarding the core of the protocol (especially Trust & Safety, Security, Spec and Advocacy work) is painfully underfunded. If your organisation (particularly public sector orgs, vendors and integrators) depends on Matrix, please join the Foundation as a paying member to ensure it can thrive. All it takes is a few more gold members and the Foundation will be able to actually accelerate rather than operating on a shoestring, and Matrix will improve for everyone as a result. Huge thanks in particular go to DINUM and Rocket.Chat the largest Silver members who have joined the Foundation this year, Automattic/Beeper and Gematik for renewing their, respectively, Gold and large Silver memberships - and thanks indeed to all our 20 funding organisational members. Meanwhile, we’ve also started experimenting with providing paid accounts on the matrix.itmanbu.com homeserver to try to cover the costs of running the homeserver.

Overall, 2025 has been a year of maturity. Putting together the keynote for the 2025 Matrix Conference in Strasbourg was a real eyeopener - realising that on the clientside alone, Matrix now has mature independent implementations across pretty much every platform. On the serverside, things have moved on too - Synapse is more and more mature; Element launched ESS Community as a long-awaited official AGPL’d distribution of Synapse (complete with Element Admin as an official admin web interface - check out the speed run!), and Synapse Pro continues to add scalability and paid support for large deployments (alongside ESS Pro, following the philosophy that features which empower end-users end up in FOSS but features which empower enterprises end up in Pro). At the same time, the Conduit family of native-rust homeservers has continued to expand and accelerate - from Conduit to Continuwuity to Grapevine and Tuwunel.

2025 is also the year that the Governing Board really started to flourish as one of the main vehicles of open governance in Matrix, with 4 working groups stepping up to take on critical tasks such as running The Matrix Conference, maintaining the matrix.itmanbu.com website itself, and coordinating Trust & Safety work across the ecosystem, and more to come like the Matrix for Public Sector Working Group (to be published soon) and new ideas brewing like the Fundraising Working Group to support the fundraising effort of the Foundation. Don’t hesitate to pop up in the Office of the Foundation room to express interest for a given WG or propose new ones! We bade farewell to Robin as the inaugural Managing Director of the Foundation back in November, but their work operationalising the Foundation’s open governance is a fantastic legacy and unlocks a huge amount of momentum for Matrix.

Talking of which, The Matrix Conference itself was a great success this year, with incredible talks from across the whole ecosystem - especially highlighting all the Public Sector uptake Matrix is seeing in support of nations pursuing digital sovereignty. The event itself was a real triumph of opening up the governance of Matrix via the Governing Board, with the Events Working Group organising the whole event and even turning a profit - not least due to the huge amounts of volunteering that the community stepped up to provide. If you missed the talks, go check them out on YouTube or media.ccc.de.

Then on Matrix itself, we have had some major wins: the great migration to next generation auth via OpenID Connect happened successfully (and indeed ended up shipping in Matrix 1.15, ahead of 2.0); we landed the first and most important phase of Project Hydra in Room Version 12 to improve state resolution and reduce state resets (see Kegan’s conference talk for more); MatrixRTC has seen major improvements in the form of Sticky Events for simpler reliable signalling and Slots for improved permissions, which put it tantalisingly close to formally landing in the spec; and loads of MSCs from the wider community - including extensible profiles landing from Tom Foster in Matrix 1.16 via MSC4133. We’re still polishing the remaining MSCs slated for Matrix 2.0, but as soon as they’re ready we’ll finally pull the lever and bump the version number. Finally, there has been major steps forward in improving the footprint of metadata that Matrix stores on servers - with an encrypted state event implementation landing in labs on Element Web via MSC4362, and all the new MatrixRTC work being built to minimise serverside metadata.

It’s not been a perfect year though; Trust & Safety has been a big focus - although with the public release of policyserv a few days ago, the ongoing collaboration with ROOST, the improvements earlier in the year, and lots more work on cross-ecosystem collaboration with Draupnir and the Community Moderation Effort, we’ve certainly made some progress. There is still much to be done though. The painful truth of Trust & Safety is that it is the one thing which will determine the success or failure of Matrix in the long term. One of the most dizzying realisations we ever had was back in 2016, when Matrix first started to get momentum and we realised that the actual long-term problem we had to solve was not decentralised communication, but instead empowering users and communities to protect themselves from abuse, spam, disinformation and propaganda… and effectively find a way to map real-life societal antiabuse mechanisms onto online communities.

We naively assumed that this would rapidly get solved given the attention it started to receive, but here we are 10 years later and if anything the Web has become more and more weaponized for information warfare since, especially in a world where LLMs can spew abuse at superhuman rates. The good news is that folks like ROOST have recently appeared to work on this precise problem, and the Bluesky team are taking it seriously too with their composable moderation and user-selectable algorithmic feeds. But the race is on to get to the point in Matrix where a full set of privacy-preserving decentralised reputation tools that users and communities can use to defend themselves are available in the protocol - letting users say “by default, please filter out invites and content from randoms (be they human or bot) who nobody vouches for in my community”.

We’ve also had our fair share of operational fun & games with the matrix.itmanbu.com homeserver, and seen a lot of frustration at the speed of the transition to Matrix 2.0 - be that because the MSCs are still being finalised, or because some Element users are still stuck on the Classic app, unaware that Element X exists.

However, the reality is that the lived experience of Matrix today (at least for us!) is genuinely unrecognisably improved from even a few years ago. Unable to decrypt messages are massively reduced (assuming users don’t lose their recovery key or delete all their devices). When using Element X, you get an app not just for tech-savvy people but for everyone, with super-glossy liquid glass UI on iOS26 and a newly super-performant app on Android; built on the super-stable Rust SDK with a beautiful event cache for offline support and message echoing/queuing; complete now with threads and spaces (in labs), which is overall a genuine joy to use. Other clients building on rust-sdk like Fractal and iamb (and in the near future, Element Web) directly benefit from the same underlying engine - and meanwhile clients on other stacks like FluffyChat or Trixnity have been busy trailblazing too. There may have been a lot of criticism over the last year, but we can’t help but feel that there have also been some huge steps forwards (perhaps making the remaining gaps all the more obvious). If you’re using Matrix today and enjoying it, please don’t take it for granted! Write a blog post, tell TWIM, tell the world, tell us what we can improve, and don’t let the bad experiences drown out the positive ones.

Talking of remaining gaps: alas, they do exist. Obvious ones include Synapse resource usage: while the Element team spiked out a demonstration of how Synapse could reduce its database usage by 100x or so, they’ve been too busy with stuff like Hydra and other robustness work to go and make this a reality yet. Another sore point is that Sliding Sync performance has in matrix-rust-sdk and Synapse regressed relative to the first implementations a few years ago, thanks to simplifications on the clientside to improve maintainability as well as changes on the server. The sync performance is good, but it’s not the ~100ms “instant sync” that we had back in the first beta at FOSDEM 2023, and it would be amazing to get back to that point. Relatedly, the only other missing piece of the Sliding Sync puzzle in matrix-rust-sdk is ensuring that push notifications update the client’s event cache and application badge, so you don’t have to wait for the client to sync to read messages you were just pushed about. This work should now be unblocked by the latest event matrix-rust-sdk event cache improvements.

On the encryption side, we still have our work cut out for us. While unable-to-decrypt messages have significantly improved (at least on synapse + matrix-rust-sdk and matrix-js-sdk clients), we still see a lot of users complaining that they can’t decrypt history due to losing their recovery key. There’s a lot of work that could be done here: we’ve been experimenting with storing the recovery key in a WebAuthn Passkey and/or hardware token, or simply deriving it clientside in the OIDC identity provider (if you trust the JavaScript the IdP serves you). We also need to finish shipping the ability to share history when inviting users to a room via MSC4268, and excluding untrusted devices by default via MSC4153 (planned for April 2026). Other big stuff that needs to be addressed includes finally imposing client-controlled group membership; progressing MLS as an alternative to Olm/Megolm; progressing Post Quantum encryption (with or without MLS), and actually getting some kind of transitive trust in place rather than requiring all users having to explicitly verify each other out of band (heck, even PGP has transitive trust!).

Then, on the core protocol side, we have phase 2 and phase 3 of Hydra to progress: improving robustness further, and then introducing finality to avoid problems caused by backdating events. This should also (at last!) switch user IDs to be public keys as per MSC4243, removing the final wrinkle from Matrix’s GDPR by eliminating directly identifiable personal information from matrix IDs, as well as paving the way towards long-awaited account portability. Somewhat related to this, Element is still hopeful to do some very pragmatic P2P Matrix work in 2026, after an initial spike back in November - watch this space for details.

Finally on the clientside, we’re finally at the point where some of the auxiliary APIs are becoming the bottleneck. Having a standard way to query cross-server user directories or shared address books would be amazing, especially now we have extensible profiles in MSC4133. Likewise privacy-preserving contact lookup could be transformative for mainstream Matrix uptake. There’s also a whole ocean of work to be done to improve how we integrate external apps into Matrix - be that via Widgets, or looking at recent developments in WebXDC and other initiatives.

Who knows which of these will actually happen in 2026! A lot of it depends on whether more organisations step up and put money behind by the bar by joining the Foundation or help fund development. Needless to say, we will keep plugging away trying to fill the gaps whatever - but the question is one of speed: the more funding available, the faster it will happen. For instance, I’m painfully aware that we’ve been aiming for decentralised accounts since, uh, 2015… but this just goes to show: if the Foundation is operating on a shoestring, then the juicier stuff gets starved out, to everyone’s detriment.

Anyway, things overall feel more positive than they have for years. We’d like to massively thank the Foundation’s members, both individual and organisational, for helping get the Foundation spread its wings as far as it has - hopefully 2026 will be the year where we can truly fly! Thanks also to the Governing Board and everyone contributing to the Working Groups for increasingly effectively sharing the load of pushing Matrix forwards: it’s great to see the fruits of open governance working out. And finally: thanks to all the developers and users who continue to use and support Matrix. The world needs secure, decentralised communication more than ever right now, and thank you for keeping the faith to make it happen via Matrix.

Happy holidays!

- Matthew & Amandine, on behalf of everyone working on Matrix.

Hi all,

On July 16th 2025 we issued a pre-disclosure for vulnerabilities in the federation protocol, and announced new releases of Matrix homeservers on Mon August 11. Today we are ending the embargo and disclosing the remaining MSCs. This post will go into more detail about the changes and what led up to them.

This project has the codename “Hydra” and is an ongoing exercise in improving the security of the federation protocol. Given the security-sensitive nature of this work, it was done under embargo by the backend team at Element, the matrix.itmanbu.com Security Team, the Spec Core Team, alongside Timo Kösters (who privately reported a related vulnerability, helping jumpstart the project) and Florian Jacob (at Karlsruher Institut für Technologie). The work was subsequently shared, reviewed and MSC’d under embargo with maintainers of all known Matrix homeserver implementations which implement State Resolution 2.0 on June 13th, so they could prepare for the coordinated release on August 11. We have then given server admins 3 more days to upgrade before lifting the embargo and disclosing the vulnerability details here.

This entire process has been highly unusual for the ecosystem, and it’s unfortunate that we were unable to make these changes out in the open. Where possible, we moved to release redacted versions of the MSCs as soon as we were comfortable from a security perspective (e.g. releasing MSC4289 and MSC4291 ahead of time, with redacted sections). Furthermore, we’d like to apologise for the disruption in landing a new stable room version and specification release with immediate effect rather than allowing for a period of public review. Going forwards, normal MSC work will continue in public as it ever has, along with normal on-cycle specification releases.

Continue reading…

Greetings from Element's backend/SRE team, who run the matrix.itmanbu.com homeserver on behalf of the matrix.itmanbu.com Foundation.

Recently users of the matrix.itmanbu.com homeserver began seeing problems where rooms would simply stop working. Operations such as sending a new message, or joining the room as a new member, would fail for mysterious reasons. Where an error message was shown at all, it tended to be something cryptic like "No create event in auth events".

After a couple of weeks of hard work by a team of Element staff including backend developers and systems engineers, we were able to repair almost all of the affected rooms. Although we're still investigating exactly what went wrong and checking that everything is now working as it should, we'd like to share some details about what we know and the work we've done to date.

We'll be diving into some quite technical details. Hopefully you'll find it interesting learning a bit about how Synapse works, how Postgres works, and the work we sometimes find ourselves doing to keep the matrix.itmanbu.com homeserver running.

🔗TL;DR

Let's start with a high-level summary.

The matrix.itmanbu.com homeserver is backed by a large PostgreSQL database instance. Parts of an index on one of tables in this database had become corrupted. We are unsure exactly what caused this corruption, but believe it happened at least a year ago, and likely significantly longer.

The nature of this corruption was such that it had little or no effect at first. However, a background maintenance task which removes old, unreferenced data from this table recently started working on the corrupted region. Due to the corrupt index, the maintenance task incorrectly removed active data from the table, in effect corrupting rooms.

Having identified the problem, we rebuilt the corrupted index, and then restored the data that had been incorrectly removed, from database backups.

Continue reading…

Hi all,

Over the last 6 months a major project has been underway by the Element server team and the matrix.itmanbu.com Foundation security team to investigate “state resets”: scenarios where Matrix’s state resolution algorithm can give unexpected results. As part of this work we’ve identified two high severity protocol vulnerabilities (CVE-2025-49090; the other not yet allocated a CVE).

Given the security implications of a federation protocol vulnerability, we’ve shared details under embargo over the last 4 weeks with all known active server implementations, and are now aiming for a coordinated security release across all Matrix server implementations on Tuesday Jul 22nd Monday Aug 11th 2025 at 17:00 UTC. If you run a Matrix server in an untrusted federation (e.g. the public federation), please be prepared to upgrade as soon as the patched versions are available.

These vulnerabilities have been addressed via MSCs which have been shared, reviewed and are in the final comment period (disposition merge) with the Spec Core Team and server implementor community, under embargo. This will result in an off-cycle Matrix spec release (1.16) introducing a new room version (12) to address the vulnerabilities in question, requiring a room upgrade of existing rooms. Having given server and room admins time to upgrade, we are then planning to un-embargo the MSCs and complement tests on Friday Jul 25th Thursday Aug 14th 2025 at 17:00 UTC.

UPDATE: Jul 18th 16:45 UTC: We've heard a lot of feedback that 6 days isn't enough for clients/bots/bridge/tooling developers to test the changes introduced by room v12, and that it also doesn't give enough time for community admins to prepare for the necessary room upgrades. Underestimating the time needed here for client/community testing is entirely our fault, due to being overfocused on coordinating the significant serverside work needed. As a result, we've pushed back the coordinated server release date to Aug 11th, to give everyone more time to test and prepare. We've also opened up registration on the beta.matrix.itmanbu.com homeserver, which is already running v12 rooms by default, to make it easier for client developers to test their clients. We've also made one clarification below for client developers, explaining the new permissions needed to send m.room.tombstone events.

CLARIFICATION: Jul 16 17:30 UTC: Room admins should plan to upgrade rooms at their convenience, similar to previous security-related room version upgrades (e.g. v1 to v2). Much like installing an operating system patch, sooner is better, but as these are not Critical Severity vulnerabilities, there is no requirement for room admins to upgrade rooms immediately on Jul 22nd. For instance, the matrix.itmanbu.com Foundation will likely upgrade its public rooms at some point after Jul 25th (having given server admins a chance to upgrade, and having given any server implementations running late a chance to release). N.B. Only rooms which include users on potentially malicious servers (e.g. publicly joinable rooms on untrusted federations) are vulnerable.

Important information for client developers:

• Client developers should review MSC4291: “Room IDs as hashes of the create event” to ensure their clients can accept the new proposed format of room IDs, and no longer expects content.predecessor.event_id in m.room.create events.

• One of the other changes coming in v12 is that room creators will be privileged over other users in the room. Therefore clients which restrict user behaviour based on power level will need to be updated to be aware that room creators effectively have infinite power level. Creators are not listed in the users block of the m.room.power_levels event, and are instead defined as the sender field of the m.room.create event, or entries in a new optional additional_creators array field in the content of the create event. Full details will be released in the MSCs when embargo lifts.

• Finally, clients which use power_level_content_override when creating rooms MUST NOT assign a power level to the room creator, otherwise the /createRoom request will fail.

• UPDATE: Jul 18th: We should have mentioned that the default power level in room v12 for sending m.room.tombstone events to upgrade rooms is 150. This stops normal admins from upgrading the room (and so assuming creator privileges) - instead, a creator has to explicitly boost an admin's power level to 150 in order to let them upgrade the room and effectively assume creator rights going forwards.

This has been an exceptionally complicated project to coordinate and its security implications required us to deviate from our usual MSC process and develop the changes under embargo. This and the expedited release of a new stable room version are exceptional choices that are far from ideal, which we’re having to take to keep the ecosystem secure. To be clear, normal MSC development and process will continue in the open, just as it always has. We’d like to sincerely thank the Matrix server implementor community for their impressive support in preparing the coordinated security releases - both in terms of vital MSC review, and then working together to implement the necessary changes. Matrix’s server heterogeneity has never looked healthier. We’d also like to thank Timo Kösters for helping precipitate the project in the first place.

We’ll follow up with more details on Aug 11th (assuming the disclosure timeline doesn’t slip further).

Thanks all for your time, patience and understanding while we ship this protocol upgrade (the first coordinated upgrade since Matrix 1.0 back in 2019!)

Matthew

We’ve noticed a fair bit of confusion (aka misinformation) around Secure Border Gateways (SBGs) recently, which this blog post aims to clarify.

First off, Secure Border Gateways are not defined in the Matrix specification. The term is actually a product name from Element, rather than anything intrinsic to Matrix.

However the concept of a border gateway is well established. In a Matrix world, it means any kind of application-layer firewall which intercepts APIs between Matrix components in order to provide defence-in-depth or apply additional policy rules, to bring an extra - but optional - layer of control within a federation. It is, in short, an optional way to provide more control over federated traffic.

So conceptually it’s the Matrix equivalent to application layer gateways for email. Without them, email works absolutely fine, and always has. However, it’s still a desirable optional extra for some enterprise deployments. For instance, it can help protect both server misconfigurations or buggy servers: literally providing defence-in-depth in traditional ‘castle and keep’ style.

That there is an ecosystem of 3rd party software vendors building additional components such as Secure Border Gateways reflects the strength and maturity of Matrix as an open standard. It’s clear evidence that a genuine open source initiative, based on an open standard, not only ensures digital sovereignty but also drives competitive innovation. Meanwhile it’s excellent to see other chat vendors like Mattermost working on first-party Matrix support again (and so in turn will benefit from capabilities like Secure Border Gateways or Cross Domain Gateways).

🔗Examples of Border Gateways

Let’s take a look at ‘SBGs’ in the wild. Probably the most widespread example right now is in TI-Messenger, Germany’s healthcare messaging system based on Matrix (targeting 150,000 organisations and almost all German citizens, due to go live in mid-July). Here, gematik chose to require SBGs (called “TI-Messenger Proxies” in its parlance) for each deployment in order to integrate Matrix with TI-Messenger’s FHIR-standard and address book system.

As a result, a whole ecosystem of SBG implementations has emerged: starting with the entirely open source TI-Messenger Proxy reference implementation from gematik - but also additional implementations from certified TI-Messenger vendors including Akquinet, Awesome Technologies, CompuGroup Medical, Element, Famedly, Gedisa, samedi and Xtension.

As an example, Element’s TI-Messenger Proxy implementation is built on Element’s generic SBG implementation, which provides a configurable pipeline for functionality like:

• Proxying (terminating and re-originating) Matrix traffic
• Apply rules based on HTTP headers
• Apply rules based on room membership
• Enforcing classification labels
• Enforce closed federation based on a domain allow list.
• Enforce usage of specific clients.
• Enforce certain parameters when creating a room.

🔗TL;DR

Whether you call them Secure Border Gateways, TI-Messenger Proxies or something else: it is possible to add an application layer firewall that brings an additional layer of control to a Matrix federation. But let’s not forget:

• Matrix servers already let you lock down your federation - e.g. all of Synapse’s federation configuration.
• SBGs are not part of the Matrix specification, because Matrix works perfectly well without them
• SBGs are an optional extra for organisations and federations that might require them, based on their use-case, external integration points (e.g. FHIR) and overall security posture
• SBGs are not required for a private federation
• SBGs are not required for public federation either
• SBGs do not make Matrix closed
• It’s a hugely positive sign of Matrix’s maturity that there’s an ecosystem of 3rd party software vendors building additional optional components like SBGs

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.itmanbu.com 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.itmanbu.com 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.itmanbu.com 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.itmanbu.com 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.itmanbu.com 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.itmanbu.com/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.itmanbu.com 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.itmanbu.com.

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.itmanbu.com 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.itmanbu.com 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.itmanbu.com 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.itmanbu.com/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.itmanbu.com 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