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.
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.
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.
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.
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).
sender_key
and device_id
on m.megolm.v1.aes-sha2
events, and the sender_key
on m.room_key_request
to-device messages, as per MSC3700. (#1101)from
optional on GET /_matrix/client/v3/messages
to allow requesting events from the start or end of the room history, as per MSC3567. (#1002)knock_restricted
join rule in supported room versions, as per MSC3787. (#1099)m.room.avatar
events is not required. (#987)type
in user-interactive authentication can be omitted. (#989)Flow information
is explicitly defined when the client-server API is rendered. (#1003)invite
where it is not specified in an m.room.power_levels
event. (#1021)matrix-doc
github repository. (#1032)m.room.message.feedback
per MSC3582. (#1035)@
are in fact reserved. Regressed from #3658. (#1100)name
field of m.room.name
events. (#3669)room_id
field from examples of m.read
, m.typing
in /sync
and m.fully_read
in room account data. (#3679)event_match
in push rule conditions. (#3690)m.login.appservice
login identifier, instead using m.login.application_service
. (#3711)invite->knock
and external->leave
are valid transitions. (#3730)origin
field from PDUs. (#998)matrix-doc
github repository. (#1032)valid_until_ts
is in milliseconds, like other timestamps used in Matrix. (#1055)/send_join
response. (#3703)content
for X-Matrix
signature validation is the parsed JSON body. (#3727)No significant changes.
No significant changes.
knock_restricted
join rule supported by room version 10 as per MSC3787. (#1099)m.federate
to the authorization rules, as originally intended. (#1103)join_rule
is knock
. (#3737)No significant changes.