General

Before we explain all about our new authentication system - don't panic! This change is part of Matrix 2.0, the next step for Matrix that will be introduced in a blog post later today.

🔗Nothing breaks

Matrix 2.0 is a reference to Matthew’s FOSDEM talk Matrix 2.0, itself a reference to the name he coined in the Matrix Summer Special 2022: evolutions of the spec that are making the Matrix experience so much better it almost feels like a different protocol. One of the major changes in this bundle is the introduction of OpenID Connect-native Matrix and its implementation matrix-authentication-service (MAS).

Don’t panic: your current setup is not at risk, you don’t urgently need to deploy the matrix-authentication-service to keep using Matrix.

Let’s walk together through what OIDC-native Matrix, what changes as compared to the Matrix we know and love, and what’s the impact for your deployment.

🔗From OIDC-ish to OIDC

One of the most popular Matrix server implementations, Synapse, supports authentication via OIDC. This is the only mainstream server implementation to support authentication via an OpenID Connect Provider. OpenID Connect, SAML, and more generally Single Sign On (SSO) are a requirement for most companies past a certain size, as well as a security best practice.

As it is today, Synapse is more OIDC-compatible than OIDC-native. This means that it’s possible to use SSO (typically OpenID Connect) to connect to Synapse, but that’s about where the OpenID Connect adventure stops. Once you’re authenticated, Synapse generates a Matrix Access Token for your client, but that is not an OAuth2/OIDC Access Token. From your client point of view, it is doing the “Matrix SSO dance” defined by the spec, but the fact that Synapse does a login via OIDC, SAML or CAS is irrelevant to the client. Whenever your client asks Synapse for anything that requires being logged in, it sends that Matrix Access Token in the Authorization header of the http requests.

While this approach has served Matrix well, the Matrix Access Token method is reimplementing some concepts of OpenID Connect without all the benefits of thousands of developers battle testing and fixing every edge case they meet.

MSC3861, which proposes the adoption of OIDC in Matrix, is all about embracing the best of OIDC to make Matrix even better. By adopting the standard OIDC flows we allow Matrix to stand on the shoulders of another battle-tested industry standard. Not only does it improve security overall, it also unlocks new use cases for Matrix.

🔗Unlocking use cases

The Matrix Access Tokens Matrix currently relies on are secure, but not very flexible. A unique token is granted to each and every client during user login. This Matrix Access Token is only revoked when the user manages their sessions and logs a device out. A Matrix Access Token gives full access to a Matrix Account. Session management based on Matrix Access Tokens is quite nuclear.

Using OpenID Connect for Matrix comes with three major areas of improvements:

• Standard authentication process on every client, including on devices without a keyboard
• Improved security with token rotation
• Better granularity of permissions (which improves security too!)

🔗Authenticate like you want

When relying on OIDC, the client delegates authentication to the OpenID Provider. This means that the client redirects the user to a web page on the OpenID Provider, where the user needs to authenticate. This authentication can happen through a username and password, WebAuthn (passwordless login), additional steps if you want to add MFA… and much more.

Since the authentication happens on the OpenID Provider, the client doesn’t need to support any authentication method other than “redirect the user to the OpenID Provider, and handle the result”. Once the user has authenticated against the OpenID Provider, it is going to be redirected back to its client, to allow it to retrieve an Access Token on their behalf.

During the whole process, no password was given to the client, and the client doesn’t even know how the user authenticated. All that matters to the client is that it now has an Access Token it can use to perform the regular Matrix API calls.

From the user perspective, the authentication is a very familiar process very well integrated in their password manager regardless of the client they use. They can use any client that supports OIDC, without having to worry about whether it supports every particular step of their authentication process. It’s also worth noting that matrix-authentication-service has a compatibility layer to support the m.login.password flow. This means compatibility with older clients will not break!

From the administrator perspective, it’s possible to force authentication flows (e.g. MFA), making sure the login is secure and matches their organisation’s policies. It also makes it possible to have a central management of all users' devices, including the ability to enforce policies upon them as provided by the OpenID Provider. For example, it becomes possible to the re-authentication of the user if they leave a trusted network.

From the developer perspective, neither clients nor servers have to add support for every new authentication method, existing or to come.

Element has been spearheading the effort to implement MSC3861 and matrix-authentication-service, and Element X is the first client to support them. Here is how the authentication flow and account management look like as seen from Element X iOS.

🔗Token rotation

While current Matrix Access Token can expire thanks to MSC2918, this best practice didn’t make it to most of the clients of the ecosystem. If the access token of a user was leaked for one reason or another, they wouldn’t notice since this wouldn’t create a new session, and the leaked token would be valid forever. Please note that thanks to E2EE, attackers who gain access to a Matrix Access Token would not be able to read the encrypted content in encrypted rooms.

OpenID Connect relies on two tokens:

• an Access Token, that is used to perform the authenticated API calls, and that expires regularly,
• and a Refresh Token that is used in conjunction with the Access Token to rotate both.

This ensures that if the Access Token was leaked during an API call, its validity would be very limited in time. Leaking a Refresh Token will also have limited impact, since the server would notice that two different clients are trying to consume the same Refresh Token and would log the user out from devices using this token.

🔗Principle of least privilege

Matrix is not just about apps and servers. It’s also a vibrant ecosystem of widgets, bots and various CLI to toy with. One of the strengths of Matrix has been its hackability: log into a client, dump the matrix access token, and you can hand it to a CLI or a bot for it to do things on your behalf.

While this approach is particularly convenient for development, it comes with its own lot of issues. Most of the time you don’t want the CLI or bot to be able to do everything on your behalf.

Widgets are another case where OIDC can help. While widgets are not yet part of the spec, in practice they are already commonly used. In essence, a widget is a tiny app that has access to an (unspecified) widgets API that allows it to do a limited amount of things on behalf of the user, such as sending a message in the rooms it’s in. While this has served several clients well, this can be improved. Indeed, it’s up to the client to enforce the restrictions mandated by the widgets API. This means you can’t be assured that all the clients will consistently enforce them.

With OpenID Connect, widgets can eventually become tiny embedded Matrix clients on their own, and they can get their own Access Token with explicit and granular permissions of their own. Those restrictions will be enforced by the server, who will not even be aware it’s a widget calling the API, making the experience consistent across clients. This behaviour still needs to be added to the specification, but a more OIDC-native Matrix paves the way for it.

🔗Upgrading to use matrix-authentication-service

MSC3861 (and friends) define how the OIDC flows and concepts (e.g. token exchange, dynamic client registration) should be used in Matrix, as well as the requirements for things which need to be coordinated with the homeserver (e.g. session lifecycle management).

The goals of matrix-authentication-service (MAS) are two-fold: firstly, it provides an implementation of the MSCs to support the Matrix Specification Change (MSC) process; secondly, it provides capabilities to facilitate the transition of the Matrix ecosystem to OIDC.

Because MSC3861 is changing the technical mechanism by which your client gets access to your account it is not something that can be done by pushing a single, big button.Instead we need a transition period where both OIDC and the existing legacy Matrix authentication methods coexist so that different clients and homeservers can migrate at their own pace.

One way in which MAS facilitates this transition is by allowing deployments without an external Identity Provider (IdP) to use OIDC out-of-the-box. This means that MAS will support some of the current flows that Synapse supports, primarily in the form of password-based login. Please note those flows are not supported yet: MAS requires an external IdP for now.

Another way is that MAS allows for existing sessions and access tokens to be imported (just from Synapse so far) so that there is no need for clients to re-authenticate when a homeserver is migrated.

Because of these migration capabilities we expect MAS to be widely used, however, in keeping with the open philosophy of Matrix, we expect other implementations to exist either standalone or integrated with other OIDC providers like Keycloak or Dex.

MAS is not intended to be a fully fledged IdP solution: we suggest using a dedicated software for this if you want to do more than what is included.

Currently MAS is deployable as a sidecar service alongside the homeserver. While larger setups shouldn’t see this as a problem, it might be seen as cumbersome in smaller self-hosted setups. For the sake of convenience, the Synapse and MAS team are investigating how to bundle MAS along with Synapse natively using PyO3. We anticipate such a bundle to exist by the end of Q2 2024.

You can browse the matrix-authentication-service docs to get all the technical details and installation steps.

We launched the Matrix Public Archive publicly on June 2nd, 2023. We decided to take it down on Sunday, June 25th out of precaution after a member of OFTC staff warned us that the archive made the content of two OFTC IRC channels bridged to Matrix available on the Internet.

After investigating the issue, we determined that the Matrix Public Archive's behaviour was expected for these channels, given an IRC chanop had explicitly configured the Matrix side of the rooms to be world-readable.

Let's talk about how room visibility works in vanilla Matrix, how it works with bridges, and what are the next steps.

Continue reading…

Hello federation,

TLDR: New website is coming tomorrow, your RSS reader might be disoriented during the switch.

That's right, after several months of studying, designing and implementing: we're finally going to deploy the new matrix.org website on June 16! Let's have a look back at the why and how.

I also need to thank Jonas Platte not only for his technical expertise but also for his kind support and patience. Thanks to MTRNord as well for kickstarting the project, and to the various designers involved.

Continue reading…

Hi all,

Back in September 2022 we launched the very first public technology preview of Third Room - our entirely open source, open standards-based platform for creating decentralised multiparty spatial apps and virtual worlds on top of Matrix.

The mission of Third Room is to ensure that a truly open and equitable platform exists for powering shared 3D environments - providing an alternative to the closed walled gardens of the bigger vendors, and generally safeguard against a repeat of the fragmented dystopia that has plagued instant messaging and VoIP systems. In short, just as Matrix aims to be the missing secure communication layer of the open Web, Third Room aims to be the spatial collaboration layer.

Today, we’re incredibly excited to announce Third Room Technology Preview 2: The Creator Update. As more and more 3D hardware enters the market, the race is on to provide tools to developers and creators so they can build on an open, vendor-agnostic platform - and in this update we’ve focused on building out the scripting, editing and authoring capabilities of Third Room to provide a solid platform for building and running collaborative 3D apps of any kind. Check out the new release at https://thirdroom.io.

As a reminder: the Third Room team is a tiny band formed by Robert, Nate and Ajay and operates outside of all the rest of our work on Matrix: the other 97% of our effort goes into making the core of Matrix amazing (particularly the underpinnings for Element X and the next generation of Matrix clients). However, Matrix is about more than just chat and VoIP, and Third Room provides an excellent showcase of Matrix’s abilities as a general purpose communication fabric.

Continue reading…

A few weeks ago we found ourselves in Brussels to participate in the second stakeholder workshop for the Digital Markets Act (DMA).

The DMA is new antitrust/competition regulation from Europe which came into force in November, whose objective is to make digital markets more competitive by forcing gatekeepers (i.e. large tech companies) to reconsider some of their anti-competitive or self-preferencing practices. Gatekeepers are defined as companies which have a clear position of influence in a given market (based on revenue / market cap / number of users thresholds), and “an entrenched and durable position”. The process for designating which companies count as gatekeepers will start in May 2023.

The DMA touches upon different key topics, from self-preferencing behaviour to app store management practices - but most importantly includes interoperability for “number-independent interpersonal communication services” (NIICS), otherwise known as chat and voice/video calling and conferencing services (social media was left out for now).

This particular workshop was focused on the latter: interoperability between messaging services, with the aim of getting the different stakeholders of the industry in the same place to discuss how the legislation could be implemented. The whole idea is to figure out a practical way in which WhatsApp could interoperate with iMessage, Google Messages and others, creating an interoperable communication network where users are no longer locked into communication silos and pick their preferred service provider without compromising on who they can talk to. \

About 900 people participated online, and around 80 people were present in person: the maximum the room could hold. It was particularly fun to see representatives from the whole industry turning up in person, including folks from XMPP, MIMI (the new IETF working group on messaging interoperability), MLS, us from Matrix obviously (alongside Matrix ecosystem representatives from Beeper and NeoChat!) - all together with the Body of European Regulators for Electronic Communications (BEREC), civil society representatives (like the Federation of German Consumer Organisations (VZBV) and European Digital Rights (EDRi)), mobile network operators, local network agencies, and obviously some of those who are likely to be designated as gatekeepers, such as Meta, Apple and Google.

Continue reading…

Note: This was originally posted on https://blog.neko.dev/posts/matrix-year-in-review-2022.html , which also includes some small info boxes about each projects, which got lost in the translation.

As we send off 2022 with a bang, it makes sense to look back on what we did this year and where we want to go next year. In its holiday special post, the Matrix Foundation has been focusing on the core team's work. This post is focusing on the achievements of the community outside of the Matrix Foundation.

I tried to reach out to as many people I have seen do "stuff" on Matrix and have them write something they would see fitting for a year in review. Now, most people have better things to do between christmas and new years, so I hope you can excuse if some projects are missing. Also I probably forgot like half of the interesting people... HOWEVER! I hope you still enjoy what everyone wrote up. And don't forget to check out the official Matrix Holiday Update 2022 and of course read you weekly TWIM to keep up to date with any cool projects you find.

Continue reading…

Hi all,

2022 has been a rollercoaster of a year for Matrix.

On one hand, the network has doubled in size (44.1M to 80.3M visible matrix IDs). The wider world is having a grand awakening to the importance of decentralisation thanks to the situation at Twitter. We’ve seen an amazing number of major new players entering the Matrix ecosystem: Reddit appears to be building out new Chat functionality using Matrix; TeamSpeak announced Matrix-based chat in TS5; Discourse is working on adding Matrix support; Thunderbird launched Matrix support; Governments from Luxembourg to Ukraine have launched their own Matrix-powered chat infrastructure; and hundreds of other organisations ranging from startups to massive private & public sector entities are betting on the protocol. The European Parliament has used Matrix as a proof-point for the viability for communication interoperability between gatekeepers in the Digital Markets Act. FOSDEM 2022 ran smoothly via Matrix with over 23,000 attendees, making it the world's largest open source conference (with 70% of attendees using their own servers!). Sweden has published case studies on the benefits of Matrix for messaging interoperability. Meanwhile existing players like Germany’s BWI have expanded their scope to providing Matrix messaging to the whole German State; Automattic is busy building Matrix plugins for Wordpress; Rocket.Chat launched federation via Matrix, Gematik has been busy progressing their TI Messenger initiative for interoperable messaging within Germany’s healthcare industry, and Tchap in France is continuing to expand.

On the other hand, only a handful of these initiatives have resulted in funding reaching the core Matrix team. This is directly putting core Matrix development at risk. We are witnessing a classic tragedy of the commons. We’ve released all the foundational code of Matrix as permissively-licensed open source and got it to the point that anyone can successfully run it at scale themselves. The network is expanding exponentially. But in return, it transpires that the vast majority of these commercial deployments fail to contribute financially to the Matrix Foundation - whether by donating directly or supporting indirectly by working with Element, who fund the vast majority of core Matrix development today.

In short: folks love the amazing decentralised encrypted comms utopia of Matrix. But organisations also love that they can use it without having to pay anyone to develop or maintain it. This is completely unsustainable, and Element is now literally unable to fund the entirety of the Matrix Foundation on behalf of everyone else - and has had to lay off some of the folks working on the core team as a result.

Continue reading…

TL;DR: you can now officially join the Matrix Foundation as an organisational or individual member in order to sustainably support core Matrix development, help steer the direction of the protocol and how best to fund it! Organisations can join by filling this form and we will get back in touch, or individuals can now donate directly here (as a more efficient alternative to Patreon, which remains online for Patrons used to it).

Hi all,

Only two days late for Giving Tuesday (and 4 years late on the Foundation scale), we are super excited to announce that we are finally expanding the Matrix Foundation into a fully-fledged non-profit fund-raising organisation to help support the core Matrix development and the wider open source Matrix ecosystem!

Has your organisation been using Matrix to communicate via the open source server and clients and you want to ensure that improvements and features still keep coming? Become a member, and feed into the roadmap.

Has your company been building on top of Matrix, making the most of its openness and flexibility, but you’ve never figured out how to contribute back in order to ensure the resilience of the tech which you rely on for the success of your business? Become a member, and ensure the core development is funded and that Matrix is here to thrive.

Are you about to be designated a gatekeeper by the EU, and have to rapidly figure out how to implement DMA-compliant interoperability (complete with end-to-end encryption compatibility) into your services? Become a member, and discover how Matrix can solve all your problems, while providing your input too.

Are you looking to implement DMA interoperability but don't fall into the gatekeeper designation? Become a member, and help ensure Matrix fits your needs too!

Are you a non-profit organisation with a mission to provide secure and sovereign communications to those who need it the most, providing an alternative to the current players? Become a member, and help us take our mission forward.

Are you an individual who strongly supports the mission of Matrix and wants to see it thrive and become the open backbone of the world’s communications? Become a member, and support the future of Matrix.

In short, this finally gives the wider world a way to contribute concretely to the significant costs of funding folks to work fulltime on core Matrix development - which now covers over 243(!) projects in github.com/matrix-org. Core Matrix work ranges from:

• managing the Matrix spec itself
• maintaining the reference client SDKs and encryption and getting them independently audited
• maintaining example server implementations in the form of Synapse and Dendrite
• writing the test suite
• publishing the matrix.org website
• promoting awareness of Matrix
• running the matrix.org homeserver
• and so much more...

In exchange for supporting the Foundation, and beyond providing certainty that our work can continue, organisations and individuals who contribute financially will be able to directly provide input to the trajectory of the core Matrix developments by becoming official members of the Matrix.org Foundation.

Introducing Foundation Memberships and the Governing Board

Practically speaking, this means that we are going to create a "Governing Board" to the Matrix.org Foundation: a new team, made up of members voted by the overall membership, a subset of the Guardians and a subset of the Spec Core Team. The Governing Board will have the responsibility of determining how Foundation funds are distributed and used, how the Spec Core Team roadmap is prioritised, how to best grow Matrix awareness, etc.

In other words, we are literally expanding the day-to-day steering of the direction of the Matrix Foundation to the wider community. In order to run the Governing Board and the overall work of the Foundation, we are also hiring an Executive Director, so please get in touch via [email protected] if you’re a non-profit foundation-running expert! In the interim, while this search proceeds, Matthew and Amandine will fill the role with the support of the other Guardians of Matrix. The Guardians themselves retain their existing function as the Foundation's non-executive board - responsible for safeguarding the overall mission of Matrix, appointing the membership of the Spec Core Team, approving membership applications, and defining the overall changes we’re outlining here.

Membership comes at various levels, each with different rewards:

• Individual memberships (i.e. today’s Patreon supporters):
  • Ability to vote in the appointment of up to 2 ‘community representatives’ to the Foundation's governing board.
  • Name on the Matrix.org website
• Silver member: between £2,000 and £80,000 per year, depending on organisation size
  • Ability to vote on the appointment of up to 2 ‘Silver representative’ to the Foundation's governing board
  • Supporter logo on the front page of the new Matrix.org website
• Gold member: £200,000 / year, adds:
  • Ability to vote on the appointment of up to 3 ‘Gold representatives’ to the Foundation's governing board.
  • Press release announcing the sponsorship
  • 1 original post on the Matrix.org blog per year
  • Participation in the internal Spec Core Team room
  • Larger logo on the front page of Matrix.org
• Platinum member: £500,000 / year, adds:
  • Ability to vote on the appointment of up to 5 ‘platinum representatives’ to the Foundation's governing board.
  • 1 sponsored Matrix Live episode per year
  • Largest logo on the front page of Matrix.org

As the activities of the Foundation increase, we expect to add more benefits to this list, for example discounts on sponsoring a future Matrix Conference, or similar.

Governing Board elections will occur yearly, with the first election planned towards the end of this year once we’ve gathered together the first wave of members and candidates have proposed themselves for election.

For anyone building on Matrix, memberships are a no-brainer as they will ensure the perpetuity and future-proof-ness of the standard. But for anyone supporting the mission of Matrix, this membership can be key to define its future.

Meanwhile, with Matrix looking increasingly integral to implementing interoperable communication for compliance with the EU’s Digital Markets Act (whether that’s as pure Matrix, or as part of the IETF MIMI initiative), this is an incredible opportunity for the organisations impacted by DMA to get a front-row seat within the Foundation to ensure that Matrix thrives and solves the challenges posed by the act. To get involved, please apply via the membership application form.

So, why is this all happening?

Since 2017, core Matrix development has been funded primarily by Element - the company founded by the team who created Matrix. Over the years, Element has put tens of millions of dollars into Matrix - which in turn has come from both selling Matrix hosting (EMS), on-premise Matrix solutions, and VC investment in Element. To put it in perspective, even though there are over 5000 contributors to github.com/matrix-org - over 90% of the actual committed lines of code come from Element employees. Similarly, while we are enormously thankful for the past and existing generous donations from the wider Matrix community, today they only come to $6,000 a month, relative to the $400,000 a month that Element has been funding.

Over the last year, we’ve seen a palpable shift within the Matrix ecosystem. Matrix is growing faster than ever. Synapse has improved immeasurably, using less RAM than ever and even sprouting Rust to optimise its hot paths. Element has improved immeasurably too, with an entirely new design on mobile, and tons of new features including threads, voice messages, location share, video rooms and more. Monthly active users reported via Synapse’s phone-home stats have almost doubled and are growing at their fastest ever rate. The number of servers has increased equivalently. We hear about major new commercial Matrix deployments almost every day. However, while usage is going through the roof - we haven’t seen a matching increase in players looking to support the project.

In fact, we’ve seen the opposite: commercial vendors forking the protocol while trying to break up the core team. Matrix tenders lost to “preferred” vendors who know absolutely nothing about Matrix. Vendors selling Matrix hosting or services without contributing anything back to the project at all. Organisations with huge amounts of money (governments, $$B massive enterprises) have enthusiastically launched proprietary Matrix solutions by building on the liberally-licensed Apache reference Matrix implementations… while contributing back nothing. Now, we are enormously grateful for the commercial Matrix deployments who do actually work with Element to fund core development or contribute code themselves - but this is very clearly the minority. Obviously it’s great to see folks building on Matrix - but it’s rather galling if it ends up with insufficient funding trickling down to the core Matrix team to be able to build the foundational technology that everyone else is relying on.

Element in particular has staffed up in order to both support the core Matrix ecosystem (the spec, Synapse, Dendrite, Client SDKs, Encryption implementations etc) as well as Element-specific work (the Element apps, EMS, the Element Enterprise Installer, etc). As a result, Element employs roughly twice as many developers as you might expect, and while Matrix is here to stay, this turns out not to be sustainable for Element unless the wider ecosystem helps support the foundational work

We believe the world needs secure decentralised communication more than ever, and ensuring the Foundation can distribute funding to those contributing to the core platform (be that Element or individuals or other organisations) is key to that. So: please consider this a call to arms - if you believe the world needs Matrix, and particularly if you depend on it for your business, please join the Foundation and participate!

Fill in the form to apply for membership, or if you are not acting on behalf of an organisation, you can go straight to our donation page.

Matthew, Amandine & the whole Matrix.org Foundation

As of Synapse 1.69, we consider "faster remote room joins" to be ready for testing by server admins.

There are a number of caveats, which I'll come to, but first: this is an important step in a project which we've been working on for 9 months. Most people who use Matrix will be familiar with the pain of joining a large room over federation: typically you are just faced with a spinner, which is eventually replaced by a cryptic error. If you're lucky, the room eventually pops up in your room list of its own accord. The whole experience is one of the longest-standing open issues in Synapse.

Continue reading…

Hi all,

At the end of each year it’s been traditional to do a big review of everything that the Matrix core team got up to that year, and announcing our predictions for the next. You can see the last edition in 2021 here - and if you’re feeling nostalgic you can head down memory lane with the 2020, 2019, 2018 ones etc too.

This year is turning out to be slightly different, however. Our plans for 2022 are particularly ambitious: to force a step change in improving Matrix’s performance and usability so that we firmly transition from our historical “make it work” and “make it work right” phases into “making it fast”. Specifically: to succeed, Matrix has to succeed in powering apps which punch their weight in terms of performance and usability against the proprietary centralised alternatives of WhatsApp, Discord, Slack and friends.

We’ve seen an absolute tonne of work happening on this so far this year… and somehow the end results all seem to be taking concrete shape at roughly the same time, despite summer traditionally being the quietest point of the year. The progress is super exciting and we don’t want to wait until things are ready to enthuse about them, and so we thought it’d be fun to do a spontaneous Summer Special gala blog post so that everyone can follow along and see how things are going!

Continue reading…