Matrix v1.3 release
16.06.2022 17:16 — Releases — Travis RalstonLast update: 15.06.2022 22:00
Hey all,
It’s another quarter and therefore another spec release! Matrix 1.2 was released back in February, and while a bit late in the quarter this time around we’ve still got some exciting additions coming to you in this release.
Like last time, the speed of these releases might feel a bit quick for developers: fret not if you’re still working on v1.1 or v1.2 implementations. We’re not expecting that implementations update as soon as a new spec release is published, but rather that the ecosystem gradually update over the course of the next few months. Implementations should be aiming for as close to realtime as they can get though, particularly considering v1.4 is expected to have some large features (more on that later on).
Matrix 1.3 sees 14 MSCs get merged, but we can’t possibly go into detail on them all here. We’ve picked some notable highlights and recommend the full changelog at the bottom for a complete idea of what’s been going on.
Aggregations and the relationships made along the way
It’s no secret that MSC1849-style server-side aggregation of related messages have been in the review backlog for a while. We ended up splitting MSC1849 down into more reviewable chunks like MSC2675, allowing us to finally land the first pieces into Matrix 1.3 today.
In the spec there aren’t currently any defined relationships which make use of aggregations or even the rel_type described by MSC2674, but we do expect that v1.4 of the spec will have support for at least threads (MSC3440) and edits (MSC2676), filling the gap. For now, we’ve decided that holding aggregations back until v1.4 doesn’t make a lot of sense, so we have launched them into the world as-is for custom relations or for clients & servers to prepare for what’s expected to be coming in v1.4 of the spec.
To further prepare for threads, we’ve also removed some restrictions of rich replies through MSC3676, thus allowing replies to be constructed with non-text messages like images. Check out the new rich replies module for more information.
Join if you can, or just knock
When we launched restricted rooms in Matrix 1.2 we noted that we forgot to handle a case where someone might want to support both knocking and restricted rooms at the same time. We’ve fixed that with a stop-gap join rule from MSC3787 in room version 10.
The new knock_restricted join rule allows the room to keep its desire to be restricted whilst also allowing members who do not meet the criteria to knock on the room instead. We’ll likely expand on this sort of mixing of join rules in proposals like MSC3386 down the line, however for now this should cover the gap in support. Next up: figuring out how to make encrypted room history available to these new joiners in a safe way.
A thread for next time
Originally planned for this release, MSC3440-style threads are anticipated to be ready for v1.4 (next quarter) with support for notifications and, of course, a whole new way to communicate in a room.
Threads are one of the more complicated features we’ve tried to land in recent history as it has a large impact on a wide variety of the spec: everything from event relationships (fixed in this release) to read receipts to push notifications needs to be worked out to build a system that not only users can understand, but also the developers trying to build it. With this massive surface area we just weren’t comfortable with adding threads to v1.3 as-is, given problems like notifications aren’t yet fully solved.
Alongside threads, we also anticipate that MSC2676-style message editing will be landing in v1.4, finally specifying how to update an event’s contents without having to redact & re-send. Although message editing has been supported for a long time in some clients, we're excited that it will finally become part of the official specification, meaning it can be implemented more widely. Messaging clients are encouraged to give the proposal an early read and possibly even attempt implementation if not already done to help us ensure the system is in a reasonable state for inclusion in the spec, though we do note that feature requests for edits will likely be deferred to a future MSC.
Keep an eye on This Week In Matrix for updates on what v1.4 is expected to include, and how things are progressing.
The full changelog
MSCs are how the spec changes in the way it does - adding, fixing, and maintaining features for the whole ecosystem to use. The blog post can’t cover them all, but that doesn’t make them any less important! 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).
Client-Server API
Deprecations
- Deprecate the
sender_keyanddevice_idonm.megolm.v1.aes-sha2events, and thesender_keyonm.room_key_requestto-device messages, as per MSC3700. (#1101)
Backwards Compatible Changes
- Make
fromoptional onGET /_matrix/client/v3/messagesto allow requesting events from the start or end of the room history, as per MSC3567. (#1002) - Add refresh tokens, per MSC2918. (#1056, #1113)
- Relax the restrictions on Rich Replies, as per MSC3676. (#1062)
- Describe a structured system for event relationships, as per MSC2674. (#1062)
- Describe how relationships between events can be "aggregated", as per MSC2675 and MSC3666. (#1062)
- Add support for a new
knock_restrictedjoin rule in supported room versions, as per MSC3787. (#1099)
Spec Clarifications
- Clarify that the url field in
m.room.avatarevents is not required. (#987) - Clarify that the
typein user-interactive authentication can be omitted. (#989) - Adjust the OpenAPI specification so that the type
Flow informationis explicitly defined when the client-server API is rendered. (#1003) - Correct the default value for
invitewhere it is not specified in anm.room.power_levelsevent. (#1021) - Update various links which pointed to the old
matrix-docgithub repository. (#1032) - Removed
m.room.message.feedbackper MSC3582. (#1035) - Fix various typos throughout the specification. (#1051, #1054, #1059, #1081, #1097, #1110, #1115, #1126, #1127, #1128, #1129, #3681, #3708)
- Clarify that state keys starting with
@are in fact reserved. Regressed from #3658. (#1100) - Remove unenforced size limit on the
namefield ofm.room.nameevents. (#3669) - Remove erroneous
room_idfield from examples ofm.read,m.typingin/syncandm.fully_readin room account data. (#3679) - Clarify the behaviour of
event_matchin push rule conditions. (#3690) - Fix incorrectly referenced
m.login.appservicelogin identifier, instead usingm.login.application_service. (#3711) - Fix membership state transitions to denote that
invite->knockandexternal->leaveare valid transitions. (#3730)
Server-Server API
Backwards Compatible Changes
Spec Clarifications
- Remove largely unused
originfield from PDUs. (#998) - Update various links which pointed to the old
matrix-docgithub repository. (#1032) - Clarify the format for the Authorization header. (#1038, #1067)
- Clarify what a "valid event" means when performing checks on a received PDU. (#1045)
- Clarify that
valid_until_tsis in milliseconds, like other timestamps used in Matrix. (#1055) - Clarify that checks on PDUs should refer to the state before an event. (#1070)
- Clarify the historical handling of non-integer power levels. (#1099)
- Fix various typos throughout the specification. (#1110)
- Correct misleading text for
/send_joinresponse. (#3703) - Clarify that the
contentforX-Matrixsignature validation is the parsed JSON body. (#3727)
Application Service API
Backwards Compatible Changes
Identity Service API
No significant changes.
Push Gateway API
No significant changes.
Room Versions
Backwards Compatible Changes
- Add room version 10 as per MSC3604. (#1099)
- Enforce integer power levels in room version 10 as per MSC3667. (#1099)
- Add a
knock_restrictedjoin rule supported by room version 10 as per MSC3787. (#1099) - Update the default room version to 9 as per MSC3589. (#3739)
Spec Clarifications
- Improve readability and understanding of the state resolution algorithms. (#1037, #1042, #1043, #1120)
- Improve readability of the authorization rules. (#1050)
- For room versions 8, 9, and 10: clarify which homeserver is required to sign the join event. (#1093)
- Clarify that room versions 1 through 9 accept stringy power levels, as noted by MSC3667. (#1099)
- For all room versions: Add
m.federateto the authorization rules, as originally intended. (#1103) - For room versions 2 through 10: More explicitly define the mainline of a power event and the mainline ordering of other events. (#1107)
- For room versions 7, 8, 9, and 10: fix join membership authorization rules when
join_ruleisknock. (#3737)
Appendices
No significant changes.