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.org 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.org 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.org 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.

The Foundation needs you

The Matrix.org Foundation is a non-profit and only relies on donations to operate. Its core mission is to maintain the Matrix Specification, but it does much more than that.

It maintains the matrix.org homeserver and hosts several bridges for free. It fights for our collective rights to digital privacy and dignity.

Support us