Hey all,
Another 9 MSCs have been released today in Matrix 1.13! It’s just over 2 months since Matrix 1.12 went out, and the last scheduled release for 2024 - the next release is planned for around FOSDEM 2025. Today’s release contains more T&S features and a number of clarifications and improvements. The full changelog is at the end of this post, per usual :)
Hey all,
Welcome to the Matrix 1.12! It’s been just over 3 months since Matrix 1.11 introduced authenticated media, and today we’re bringing more Trust & Safety features to the ecosystem, alongside the normal clarifications and general improvements to the protocol. This release is also technically a few days late on the quarter, but it’s for good reason! Folks from across the ecosystem got together in Berlin for the Matrix Conference, and after things wrapped up we were busy following up on ideas started on site. We can’t wait to see all of these ideas materialize as MSCs, but in the meantime, back to the honorary Q3 release of the spec:
Matrix 1.12 marks the recommended date for all servers to enable their media freeze, similar to matrix.org’s back in early September 2024. Servers which haven’t yet enabled their media freeze are strongly encouraged to do so, if it makes sense for their users. Matrix 1.12 also brings some improvements and clarifications to authenticated media, and a total of 9 MSCs covering a wide range of features.
Read on for a few highlights, and the full changelog at the end of this post.
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.
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.
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
Hey all,
We’ve just released the milestone Matrix 1.11 update for the protocol. It’s been almost exactly 3 months since the last release, Matrix 1.10, keeping us on track for our once-a-quarter release schedule.
There are 9 MSCs released in Matrix 1.11 today, but there’s one specific MSC we’d like to draw your attention to: MSC3916 - Authenticated Media. Until today, Matrix had a design flaw which allows a user to access media unauthenticated if they knew the URL. This has been used to share files in social media posts, link images outside of chats, and generally imply that a homeserver is a CDN for the internet. Some of these use cases are legitimate, though many are not. This is fixed with MSC3916.
This post covers MSC3916 and its implementation guidelines in more detail, but the full changelog for Matrix 1.11 is available at the end, as always.
Hey all,
Matrix 1.10 is here! We aim to release the specification once in each calendar quarter, and with Q1 wrapping up in a few days we’re due for this quarter’s release. It has been 5 months since the last release (Matrix 1.9) brought in some protocol maintenance for us though, and the implementation teams have been hard at work building the Matrix 2.0 stack concurrent to the Matrix 1.10 work released today.
A total of 9 MSCs are released in Matrix 1.10, covering a wide range of maintenance, Matrix 2.0 preparation, and features for clients to use. This post focuses a bit on the Matrix 2.0 front and what’s expected in Matrix 1.11’s release cycle, but read on to the changelog at the bottom for full details on the changes which make up Matrix 1.10.
MSC3077 and its related proposal MSC3291 (muting in VoIP calls) lay some foundational groundwork for proper group VoIP to land in Matrix - an objective of Matrix 2.0. Currently this is taking shape at MSC3898 and MSC3401, though Element’s VoIP team is considering a possible third alternative which runs MSC3401 over something like LiveKit’s SFU - stay tuned for updates there. In the meantime, users in native 1:1 calls can enjoy proper screen sharing and mute capabilities ahead of the 1:N call support later this year.
As always, early review is appreciated though please note that MSC3898 and MSC3401 are particularly in flux at the moment.
Over the next 2-3 months, we’ll be focusing on the following MSCs:
Additionally, we’ll be continuing to define the expectations of a Spec Core Team member, particularly as it relates to the upcoming Governing Board for the Foundation. This exercise has been extremely valuable to us so far, and will help identify areas the Foundation and SCT may need support from each other.
Read on for full details of what’s in Matrix 1.10:
Backwards Compatible Changes
/versions to optionally accept authentication, as per MSC4026. (#1728)body field as optional media caption, as per MSC2530. (#1731)Retry-After header may be used to rate-limit a client, as per MSC4041. (#1737)GET /relations endpoints, as per MSC3981. (#1746)Spec Clarifications
data-mx-bg-color and data-mx-color attributes instead. (#1739)PublicRoomsChunk in the GET /hierarchy endpoint. (#1740)sdpMid and sdpMLineIndex are not required in m.call.candidates. (#1742)Content-Type may have distinct behaviour on non-JSON requests/responses. (#1756)m.push_rules account data type cannot be set using the /account_data API, as per MSC4010. (#1763)Spec Clarifications
POST HTTP method, as GET requests don't have request bodies. (#1721)PublicRoomsChunk in the GET /hierarchy endpoint. (#1740)children_state, room_type and allowed_room_ids properties in the items of the children array of the response of the GET /hierarchy endpoint are not required. (#1741)Spec Clarifications
/login and /register endpoints should fail when using the m.login.application_service login type without a valid as_token. (#1744)No significant changes.
No significant changes.
Spec Clarifications
invite->knock is not a legal transition. (#1717)No significant changes.
Spec Clarifications
@matrix-org/spec. (#1713)/relations apis. (#1745)$ref URIs containing fragments in OpenAPI definitions and JSON schemas. (#1751, #1754)Hey all,
We’ve just pushed out Matrix 1.9! Our last release was Matrix 1.8 and brought us a whole new room version. Matrix 1.9 continues a theme of an annual maintenance release, bringing with it mostly clarifications and bug fixes.
Today’s release sees just 1 MSC formally merged to the specification, though this is expected for a maintenance release. For the last 2 months (and beyond), we have largely been focused on changes which haven’t settled enough to be MSCs yet, such as interactions with the More Instant Messaging Interoperability (MIMI) working group at the IETF.
This post covers a lot of what we’ve been up to for the last few months, and what we expect to get done for the Matrix 1.10 release cycle. As always, the full changelog for Matrix 1.9 is at the bottom of the post :)
One of the major features of Matrix is its ability to connect multitudes of messaging providers with a common communications fabric - a feature that is extremely useful in light of the EU’s Digital Markets Act (DMA) which requires gatekeepers to interoperate with other messaging providers.
We’ve been working with the MIMI working group at the IETF to establish a federation protocol for DMA-style messaging alongside our own experiments like MSC3995: Linearized Matrix. The proposed protocol for MIMI is based upon the Linearized Matrix work, but is primarily designed for an MLS-centric environment.
Discussions and experiments will continue over the next several months, and you can read all about our progress so far in TWIM 2023-11-10.
We mentioned in Matrix 1.8’s release that we’d be taking a look at MSC2545, MSC1951, MSC4027, and MSC3892 - a family of MSCs collectively called “custom emoji/stickers”. Our review started relatively late in the Matrix 1.9 release cycle (sorry), and we started thinking about interactions with MSC3916/MSC3911 where media is linked to a specific event.
We haven’t had a chance to really dig into the specific possible concerns on these two features overlapping, but do welcome feedback and suggestions for what might impact custom emoji/stickers over on our dedicated tracking issue. We’ll continue working through the problem space in the Matrix 1.10 release cycle, and hope to get both linked media and custom emoji/stickers up for FCP.
With each release we aim to have a plan for what the next release will look like, giving us a direction or theme to follow. Noting that the next release cycle has a lot of holidays (and FOSDEM) in it, we’ve got an initial list of things to look at, grouped by theme:
This list is not final and will be iterated upon over the next couple of weeks. If you’ve got an MSC to add or remove, let us know in the SCT Office on Matrix. For all of the MSCs above, we aim to get them to a FCP-accepted state at a minimum, and merged to the spec if time permits (and makes sense - looking at you, Extensible Events).
Matrix 1.9 is a relatively light maintenance release, but it still has a changelog! Read on for full details.
Backwards Compatible Changes
Spec Clarifications
m.call.negotiate schema and example. (#1546)via property is required for m.space.parent and m.space.child as per MSC1772. Contributed by @PaarthShah. (#1618)/publicRooms API that the server name is case sensitive. (#1638)m.room.name event with an absent name field is not expected behavior. (#1639)GET /initialSync. (#1647).m.rule.suppress_notices push rule not being valid JSON. (#1671)event_property_is and event_property_contains push conditions to PushConditions object. (#1673)fallback property set to true. (#1676)Spec Clarifications
m.receipt EDU. (#1636)No significant changes.
No significant changes.
No significant changes.
No significant changes.
Spec Clarifications
Backwards Compatible Changes
Spec Clarifications
m.mentions object. (#1635)m.receipt event in Client-Server API. (#1637)fieldname in appservice Protocol definition. (#1646)Hey all,
Matrix 1.8 is out now! The last release, Matrix 1.7, was full of features and laid out a plan for what Matrix 1.8 was expected to become. We spent most of our time focusing on the MSC3995-related MSCs from that original plan, but made an effort to get the other stuff looked at as well.
With this release we see a total of 9 MSCs achieve their formally adopted status. The full changelog at the bottom has all the details, but please read on for what’s new in room version 11, and Matrix 1.9’s roadmap :)
Matrix 1.8 features a new room version! Normally a room version wouldn’t have a particular theme, but for v11 we aimed to clean up the different algorithms and event format details. After 10 prior room versions there were some artifacts of the past sticking around (but not causing problems necessarily) - many of them are cleaned up here.
Specified originally as MSC3820, v11 introduces the following changes:
redacts to the content of m.room.redaction events.creator from m.room.create events (use sender instead).origin from events.Alongside being a cleanup room version, v11 is the initial base we used for our efforts in the IETF world. It provides an easier starting point for new server implementations, particularly when paired with Linearized Matrix (described as both an IETF Internet-Draft and MSC3995).
In future room versions the cleanup effort will continue, alongside additional features for supporting the IETF use cases. Watch this space for updates.
We’re continuing the trend of planning ahead and have the following themes planned for work in Matrix 1.9:
A lot of this stuff might take the shape of opening MSCs or thinking about the problems, but we’re also very optimistic about getting them through FCP before November 2023. Watch this space for updates :)
There’s so many more things than what we covered in this blog post - flip through the changelog below for a full idea of what’s landed.
Backwards Compatible Changes
Spec Clarifications
type property in the JSON schema definition of the m.reaction event. Contributed by @chebureki. (#1552)null in room_types in POST /publicRooms endpoints schemas. (#1564)Deprecations
Backwards Compatible Changes
Spec Clarifications
/state_ids can respond with a 404. (#1521)POST /_matrix/federation/v1/user/keys/claim. (#1559)null in room_types in POST /publicRooms endpoints schemas. (#1564)Spec Clarifications
fields in thirdparty lookup queries. (#1584)Spec Clarifications
No significant changes.
Backwards Compatible Changes
redacts from top level to content on m.room.redaction events in room version 11, as per MSC2174. (#1604)creator from m.room.creator events in room version 11, as per MSC2175. (#1604)origin from events in room version 11, as per MSC3989. (#1604)Backwards Compatible Changes
Spec Clarifications
Backwards Compatible Changes
@matrix-org/spec npm package to ship the SAS Emoji data definitions & translations. (#1620)Spec Clarifications
x-changedInMatrixVersion is a string. (#1562)oneOfs in JSON schemas. (#1585)Hey all,
Matrix 1.7 has just been released! The last spec release was about 3 months ago, keeping us on track for regular quarterly releases. Unlike Matrix 1.6 though, today’s release is packed with plenty of features, some of which we’d like to call out here. Not all implementations will have support for these features yet though, and that’s okay (expected, even).
Adding support for a spec release can be a significant body of work. Instead of implementations having everything ready for spec release day, the idea is that they gain support over the next few months. If you’re able, please help those projects get v1.7’s features.
Today, we see 15 MSCs achieve their formally adopted status. All of them bring forward some much-needed features to Matrix, and a few highlights are below. Read on to the full changelog for a complete overview, and for a sneak peak at what the Spec Core Team (SCT) is planning to look at for v1.8 👀
Hey all,
Matrix 1.6 is out there! Like Matrix 1.5 back in November, this release is largely a maintenance update. Matrix 1.1 through 1.4 have been relatively major upgrades, so a little time between features doesn’t feel like a bad idea :)
As with all spec releases, we encourage implementations to gradually update over the next few months rather than have support for everything on release day - please be kind to the projects you use, and help them gain support if able.
Matrix 1.6 sees just 7 MSCs get merged, though this is to be expected from a maintenance release. Check out Matthew’s Matrix 2.0 talk at FOSDEM for an idea of what’s expected over the next few releases.
We’ve covered a couple of the MSCs below, but read on to the full changelog for the full picture.
Hey all,
We’ve just released Matrix 1.5, a largely maintenance update for the spec. We intentionally haven’t landed any major features in this release as Matrix 1.4, just shy of 2 months ago, had introduced fairly large features for clients and servers to consider. As with all spec releases, we encourage implementations to gradually update over the next few months rather than expect them to have support for everything on release day.
Matrix 1.5 sees just 2 MSCs get merged, though this is to be expected from a maintenance release. We expect that the next release (in Q1 2023) will have a few more exciting features to it :)
We’ve covered both MSCs below, but read on to the full changelog for the full picture.
Already supported implicitly by the spec up until now, reference relations are a way to simply reference another event. Usually these sorts of relations are used for events which need to be related to each other, but a dedicated relationship type doesn’t make a lot of sense.
In-room verification and MSC3381: Polls are examples of how these relations get used.
MSC3905 fixes an issue in the specification where appservices (usually bridges) specifying a users regex without homeserver domain would end up receiving far more event traffic than they would have intended. With the MSC, appservices are now only considered interested in “local” users, regardless of how vague their users namespace is.
Overall this should have no effect on most bridges/appservices, however if an appservice in the wild really does need to listen to all users on all homeservers, it can specify a non-exclusive namespace on all rooms instead.
While writing this MSC into the spec we took some time to clarify the appservice registration requirements more generally: check them out here.
MSCs are how the spec changes in the way it does - adding, fixing, and maintaining features for the whole ecosystem to use. Check out the full changelog below, and the Spec Change Proposals page for more information on how these MSCs got merged (hint: they submitted a proposal, which anyone can do - take a look at the Matrix Live episode where Matthew covers the proposal process).
Backwards Compatible Changes
m.reference relations, as per MSC3267. (#1206)m.key.verification.request msgtype for in-room verification. (#1271)Spec Clarifications
device_one_time_keys_count in /sync. (#1266)/_matrix/client/v3/directory/rooms/{roomAlias}. (#1286)set_sound push rule action by set_tweak. (#1318)PUT /_matrix/client/v3/pushrules/{scope}/{kind}/{ruleId}. (#1319).m.rule.master has a higher priority than any push rule. (#1320)refresh_token at endpoint POST /_matrix/client/v3/refresh. (#1323)GET /_matrix/client/v3/sync response example. (#1341)Spec Clarifications
Spec Clarifications
Spec Clarifications
No significant changes.
Spec Clarifications
No significant changes.
Backwards Compatible Changes
Spec Clarifications
resolve-additional-types template. (#1303)