matrix.org homeserver

The Matrix.org homeserver will see changes related to authentication in Q1 2025. The team will turn off guest account access on Matrix.org on January 16th and roll out Matrix Authentication Service (MAS) to embrace Matrix 2.0 after February 10. Client developers need to ensure their clients support the required changes.

🔗What is MAS

Matrix Authentication Service is Matrix's next-generation authentication stack. It allows for more flexible authentication journeys without requiring client developers to support every one of them.

You can find all the technical details in Quentin's Matrix Conf talk, Harder Better Faster Stronger Authentication with OpenID Connect.

🔗What's the impact

Client developers need to ensure that their projects support the requirements listed on areweoidcyet.com and, more precisely, the requirements listed in MSC3824.

Developers can already use beta.matrix.org to see if their clients are compatible with MAS. If you notice anything that doesn't work as intended, make sure to give your feedback on those MSCs. If clients work on beta.matrix.org, they will be able to connect to matrix.org after the rollout.

Homeserver administrators from the public federation don't have to worry about this deployment. MAS only affects the APIs between the clients and the server, so this deployment only impacts clients connecting to matrix.org. Federation APIs, used for servers to talk to each other, remain unchanged.

🔗Disabling guest accounts

Guest accounts are a legacy Matrix feature that allows clients to create temporary, limited technical accounts to participate in specific rooms that allow it.

The Matrix.org Foundation would have liked to find an efficient way to let people create guest accounts when joining a conversation and then turn them into fully fledged accounts later. Nobody in the ecosystem found resources to design and implement such a user journey, and guest accounts ended up being used for technical reasons, like displaying room previews or badges via shields.io.

Those accounts make up a significant load on the matrix.org homeserver. For that reason, the Matrix.org Foundation has decided to disable them at least temporarily to save precious resources and go ahead with the rollout of the new authentication stack.

The Matrix.org Foundation is open to re-enabling guests accounts once it has the financial capacity to support them. If guest accounts on matrix.org are important to you and your business, please join the Matrix.org Foundation as a supporting member to contribute to its financial sustainability.

We encourage developers using guest access for room information, such as topics, aliases, or member counts, to utilize the endpoint proposed by MSC3266. This endpoint is publicly accessible without authentication and can serve as an alternative resource until guest access is reinstated in a more robust form.

We appreciate your understanding as we take these steps to enhance the user experience on Matrix.org.

We will be decommissioning the sliding sync proxy next week (21/11/2024) and Element are removing client support in mid-January (17/01/2025).

Sliding Sync is designed to provide a significantly faster and more scalable sync experience in our clients. The initial implementation was first prototyped in Element Web backed by an entirely experimental server proxy. The implementation had half an eye on low bandwidth use cases, and the prototype led to MSC3575. We then realised that a simpler approach would be beneficial, and reused the same (experimental) proxy concept to facilitate beta testing with Element X, this time making it available on matrix.org. In doing so, we learned valuable lessons, leading to a refined and simplified API design in MSC4186. The proxy itself was only ever considered as a temporary arrangement to aid speed of development, rather than being a long term solution.

Simplified Sliding Sync MSC4186 (also known as native sliding sync), has since been implemented in Synapse, with encouraging results. Now that we don’t expect the API shape to change significantly, we recommend homeserver developers to implement MSC4186 natively.

The Matrix.org Foundation does not have the resources to keep up maintenance of the proxy service or its codebase, and plans to decommission the proxy from Mid-November and archive the sliding-sync repo.

Recognising that the community needs time to adopt sliding sync natively, Element will keep client support for the old API (MSC3575) until the 17th of January, 2025.

Continue reading…

Hello everyone,

The Trust & Safety team has been working hard to get MSC3916 in the hands of users, and we’re nearly there with Matrix 1.11 being released last week. This fixes a long-standing design flaw in Matrix where media (images, avatars, files, etc) can be accessed without authentication if the URL is known. Matrix 1.11 fixes this by requiring authentication on these URLs, removing the ability for users to treat homeservers as CDNs for hosting arbitrary Matrix content for arbitrary users.

Rolling this feature out to the entire public federation is a bit tricky, particularly when considering the user safety and privacy benefits which Matrix 1.11 brings. Developers are encouraged to support authenticated media quickly to give server admins the ability to freeze unauthenticated media access on their servers. Media uploaded or cached before the freeze will remain accessible on the unauthenticated endpoints, but any media uploaded or cached after the freeze will only be available through the authenticated endpoints.

This freeze reduces the amount of breakage users will see. We’re aware of links being shared outside the context of a room already, and breaking those would be pretty disappointing for those users. We also don’t want to encourage that capability going forwards due to the space it takes up and the anonymous nature of the requests. Users who keep their clients updated should see no impact when their servers implement their freeze, but may find themselves unable to copy/paste media URLs to their friends.

Matrix 1.11 recommends that all servers evaluate their local ecosystem to determine when would be best to implement the freeze, and that the freeze should happen before Matrix 1.12 is released in August 2024. For the matrix.org homeserver, we anticipate most of our users to have updated clients in July, putting our freeze date in August.

Developers, and those curious, are encouraged to review the Matrix 1.11 blog post for details on the changes they’ll need to make in July to have near-zero matrix.org user impact, and for information about the recommended freeze approach.

🔗Timeline for matrix.org homeserver

To assist developers and other server admins in testing their implementations, we will be updating the beta.matrix.org homeserver to enact the freeze as soon as code is available for that. We expect this to happen in July 2024. The matrix.org (non-beta) homeserver’s freeze will be started on August 28th, 2024 September 4th, 2024 during normal UK business hours.

Update August 14, 2024: Most of the ecosystem has already updated to support authenticated media with only a few bug fixes pending release. To give a little bit more buffer for these bug fixes to roll out, we've moved our scheduled date to September 4th, 2024.

All media uploaded and cached prior to the freeze will remain accessible on the unauthenticated endpoints and authenticated endpoints. Media uploaded and cached after the freeze will only be available through the authenticated endpoints, not the unauthenticated ones.

🔗Developer support

The team is making themselves available in the #matrix-client-developers:matrix.org and #matrix-homeserver-developers:matrix.org rooms on Matrix to help support developers in implementing this feature. Client, server, and bridge authors are welcome to visit those rooms to get help in figuring out what needs to happen to support authenticated media. Further resources are also available in the Matrix 1.11 blog post.

For questions about the rollout itself, the freeze date, or the (beta.)matrix.org homeserver, please visit #foundation-office:matrix.org on Matrix.

We look forward to seeing the ecosystem working towards a safer, authenticated, experience for users.

Thank you,

Travis Ralston & the whole Matrix.org Foundation team