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 👀
The media repo has been largely unchanged since it was first released in 2015 as r0.0.0 - the only change being the addition of URL previews in r0.3.0 (released in 2017). Thankfully, the folks over at Beeper have been busy changing this situation!
MSC3860 and MSC2246 are both available as of today in the spec, improving how much bandwidth media repos need to offer and fixing a long-standing issue where uploading large files can be a challenge. MSC3860, specified here as allow_redirect
, allows clients to opt-in to HTTP redirects on downloads, avoiding slowdowns from the server having to proxy and move the media twice. It’s particularly useful if your server uses a CDN like S3 to host media - just tell clients to go grab media directly from S3 instead.
Meanwhile, MSC2246 (largely specified here) gives clients an ability to upload their media after sending the associated event. The MSC was originally designed with bridges in mind, where message order and delays are very perceivable problems for users, however clients like Element X are thinking about using the feature to improve local echo on uploads as well. We’re excited to see uploads finally be reliable, and non-blocking for the conversation flow!
History would indicate that we’ve got several years to go before the next major improvement to media, but we’re looking to change that: MSC3916: Authentication for media, MSC4016: Streaming E2EE file transfers, and MSC3870: Upload direct to URL are all fairly promising MSCs we’re planning to take a look at in the next year or so.
Reactions have actually been in use for quite some time already, but the MSC struggled to make it into the spec formally. With Matrix 1.7 though, MSC2677 is merged.
MSC2677 was the last part of the MSC1849 saga, with MSC2674 (relationships) and MSC2675 (server-side aggregation) landing in Matrix 1.3, and MSC2676 (edits) landing in Matrix 1.4 back in September 2022. There’s still some work to be done in this area though, and certainly some quality of life improvements asking to be written up as MSCs - watch this space for progress on those fronts.
One of the best parts about writing an MSC is eventually seeing it released in the spec, and these folks saw their MSCs reach this milestone for the first time. Congratulations everyone, and please keep them coming!
In no particular order:
Anyone can contribute MSCs, improving the whole of Matrix for everyone. If you have an idea (or bugfix), check out the guidelines and let us know if you run into any questions in #matrix-spec:matrix.org on Matrix - we’re always happy to help.
The SCT aims to cut a release in the middle of each calendar quarter, largely to avoid most conflicts with regional holidays, and since Matrix 1.1 the releases have been getting less and less organic. Instead of looking at MSCs whenever they’re raised, the SCT has been aiming to hear about which MSCs will need looking at. This is a very subtle difference, but one that dramatically changes how the quarterly releases are structured.
With each spec release, the SCT has slowly been working towards a place where the majority of MSC work is thought about in advance, and Matrix 1.8 is another milestone along this journey. Over the next couple weeks we’ll be working on a roadmap based on the MSCs that are raised to us in the SCT Office room on Matrix, starting with the ideas we raised ourselves earlier in the year.
As of writing, our current plan for Matrix 1.8 includes:
While this doesn’t represent a commitment to have these MSCs merged, these are the areas that the SCT is likely to be thinking about for the next 3ish months. If you have MSCs that might be possible to merge before roughly August, let us know in the SCT Office room (even if those MSCs aren’t on-theme with the above - we still want to hear about them!).
Critically, our release planning does not just include MSCs that are on track for being merged. We are also aiming to track that a given MSC needs technical review (for example), or that it might be receiving attention external to the SCT (such as implementation). We’d love to hear what you’re working on so we can start bringing those MSCs to the top of the list - let us know in the SCT Office room.
As is the theme for this section, if you have any questions about what the release process looks like (or where a given MSC currently sits in the roadmap), let us know in the SCT Office room.
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. Special thanks to MichaelKohler, zecakeh, and Cadair for contributing clarification & bug fix PRs in this release - we greatly appreciate it!
POST /_matrix/media/v1/create
(#1499)PUT /_matrix/media/v3/upload/{serverName}/{mediaId}
(#1499)POST /_matrix/client/v1/login/get_token
(#1530)m.replace
(edit) events, as per MSC3925. (#1440, #1525)event_property_is
and event_property_contains
, as per MSC3758 and MSC3966. (#1464)m.annotation
relations (reactions), as per MSC2677. (#1475, #1531)m.mentions
property; the .m.rule.is_user_mention
and .m.rule.is_room_mention
push rules; and other notification behaviour, as per MSC3952. (#1508)limit
on a filter if one is not specified. (#1463)state_default
is 0 if there is no m.room.power_levels
event in a room. (#1479)token
parameter on /keys/query
endpoint. (#1485)dont_notify
and coalesce
push rule actions, as per MSC3987. (#1501)m.location
scheme by partially reverting f1f32d3. Contributed by @HarHarLinks. (#1507)knock_restricted
join rule to the m.room.join_rules
schema. (#1535)examples/minimal_pdu.json
. (#1454){key_id}
from /_matrix/key/v2/server/
. (#1473)age_ts
field from the reference hash calculation section. (#1536)/_matrix/identity/v2/store-invite
. (#1486)No significant changes.
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.
It’s here! The time machine we’ve been waiting for!
Primarily part of the Gitter feature parity project (congratulations to the team going all-in on Matrix, by the way) to drive the Matrix Public Archive, the new API gives clients the ability to jump back in time to a nearby event. Being able to find something that was posted on a given day/week, but not being sure of which keywords to look for is a major usability improvement - many thanks to the Gitter team for making Matrix better!
Matrix is going voom
Synapse 1.76 enabled faster joins by default, and while there’s a lot of Python going into making joins as fast as possible, the specification side is a relatively small change at the moment: just don’t send as many events during joins (omit_members
).
There’s potentially more work on the horizon for making faster joins even faster and more robust, and some of that might involve spec work: keep an eye on Synapse releases and TWIM for updates as we make our way to faster joins in Matrix 2.0 :)
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).
/rooms/<roomID>/timestamp_to_event
endpoint, as per MSC3030. (#1366)hkdf-hmac-sha256.v2
MAC method for SAS verification, as per MSC3783. (#1412)/context
always returns event
even if limit
is zero. Contributed by @sumnerevans at @beeper. (#1239)medium
. (#1417)/timestamp_to_event/<roomID>
endpoint, as per MSC3030. (#1366)/_matrix/federation/v2/send_join
to allow omitting membership events, per MSC3706. (#1393, #1398)/_matrix/federation/v2/send_join
should include heroes for nameless rooms, even when allowed to omit membership events, per MSC3943. (#1425)POST _matrix/federation/v1/user/keys/claim
response schema. (#1351)edu_type
in EDU examples. (#1383)No significant changes.
<content>
to content
in the OpenAPI files for content uploads. (#1370)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).
m.reference
relations, as per MSC3267. (#1206)m.key.verification.request
msgtype for in-room verification. (#1271)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)No significant changes.
No significant changes.
resolve-additional-types
template. (#1303)Hey all,
It’s finally here: threads, edits, and private read receipts. v1.4 has been a little later than usual in the quarter because we wanted to make sure we nailed down all the core MSCs for threads before publishing the spec itself, but we’ve done that now and we’re excited about it.
Matrix 1.3 was just over 3 months ago, though with the relatively large features there and the colossal implementation effort of v1.4 we’re not expecting everyone to have implementations on day 1. Instead, as with all spec releases, we encourage implementations to gradually update over the next few months. We’re additionally planning to make v1.5 (Q4 2022) more of a maintenance update to help make the backlog a bit easier on everyone, though we might prioritize a couple cool features in there too :)
Matrix 1.4 sees 14 MSCs get merged, but we can’t possibly go into detail on them all here. We’ve instead focused on the 3 major features we’re excited about - check out the changelog at the end for the full picture.
Threads, a critical feature in terms of parity with other chat systems, have landed thanks to a whopping 6 MSCs: MSC3440, MSC3816, MSC3856, MSC3715, MSC3771, and MSC3773. It’s been a lot of iteration on the reference implementations to get threads this far, and we’re excited to see how the client implementations evolve to provide more structured and less noisy communication for everyone - keep us updated with TWIM posts, please!
Threads have involved changes to event relationships (which were fixed in v1.3), read receipts, and notification counts, resulting in several different models and ways of solving the problem. We think we’ve reached a point that works for conversational threads, though there’s work on the horizon for threads-only rooms, Twitter-style free-form threads, etc to cover more needs of users.
Currently, the demonstration implementation of threads in Synapse and Element is working its way out of the proof-of-concept and beta stages (which were sufficient to validate the MSCs) and are on their way to exiting beta. Keep an eye on the respective blogs for news about production-ready threads!
Similar to reactions, err, aggregations, MSC2676 and its predecessors have been around for a long while. Edits have existed in the Element clients seemingly forever, and other clients have had troubles trying to implement the same feature: with it now in the spec, it should be a lot easier to bring edits into clients.
For edits, we’ve taken the route of making the MSC match reality, for better or worse. MSCs which improve or add functionality to the system are very much welcome - writing an MSC is relatively easy and helps the whole community.
Not everyone wants to broadcast that they’ve read a message, but also with read receipts tied into notifications those same people also probably don’t want stuck notifications. To address the problem, we’ve added a new m.read.private receipt type which behaves exactly like m.read, but is only visible to you.
We still have a rework of the notifications system in our long-term plan, but this should hopefully cover the privacy concerns for the time being :)
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).
.m.rule.room.server_acl
push rule to match m.room.server_acl
events, as per MSC3786. (#1190, #1201)Cross-Origin-Resource-Policy
(CORP) headers to media repository, as per MSC3828. (#1197)type
when upgrading it, as per MSC3818. (#1198)room_types
filter and room_type
response to /publicRooms
, as per MSC3827. (#1199)m.replace
relations (event edits), as per MSC2676. (#1211)m.read.private
receipts, as per MSC2285. (#1216)m.fully_read
optional on /read_markers
, as per MSC2285. (#1216)m.fully_read
markers to be set from /receipts
, as per MSC2285. (#1216)m.thread
relations, as per MSC3440, MSC3816, MSC3856, and MSC3715. (#1254)/rooms/{roomId}/invite
endpoint will return a 200 response if the user is already invited to the room. (#1084)<code>
snippets in tables rendered from OpenAPI definitions. (#1179)POST /_matrix/client/v3/login
. (#1210)<code>
snippets in tables rendered from OpenAPI definitions. (#1179)Authorization
header instead of access_token
when talking to the application service, as per MSC2832. (#1200)auth_events
must be rejected. (#1137)invite->knock
is actually a legal transition. (#1175)No significant changes.
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.
Hey all,
Welcome to the second installment of our quarterly spec releases. If it feels like it hasn’t been long since our last release, you’re not alone! Our last release was just 3 months ago, introducing the new platform and world we build within.
This improvement in speed might seem too fast, but fret not: implementations are not expected to update as soon as the new spec is published. Rather, it is more realistic to expect that the ecosystem gradually update over the course of the following few months/year. Particularly after the massive release that was v1.1.
So, what’s new in v1.2? With 18 MSCs merged there’s a lot to cover - we’ve picked some notable highlights and recommend the full changelog at the bottom for a complete idea of what’s been going on.
Spaces launched into beta last May, redefining how we can use rooms on Matrix to represent different data structures. Described mostly as MSC1772, Spaces are simply rooms with a specific type in their m.room.create event. With state events being used to define which other rooms (meaning Spaces too) are part of that Space, the possibilities for tree-like structured data become endless.
There’s still quite a lot of work to do in the Spaces space (hah), though we’re excited to see it all land. For instance, MSC3216 and MSC2962 target power level syncing, MSC3219 aims for flair, and MSC3089 looks at file structures using Spaces. We might even be able to replace the public room directory with a server-wide space, making writing clients a little bit easier.
Restricted rooms are new in this release from MSC3083. In these rooms (and therefore Spaces too!), the join rules can be configured such that a member of another room can join without needing an invite. In a typical setup, this means that a Space could be set as invite-only, but all the rooms and Spaces underneath that Space could allow joins for members of the parent Space. When someone wishes to explore the universe you’ve laid out in your Space they can simply join the interesting rooms without having to ask for invites constantly.
This feature changes how membership events are authorized, so is only available in room versions 8 and 9 (both introduced in this release). Room version 9 fixes a relatively rare bug from version 8, so we’d recommend using v9 if you’re planning an upgrade for this functionality.
Further work in this area involves figuring out how to keep membership lists perfectly in sync between the rooms, which is currently done by external tooling. For example, evicting someone from the parent Space could (optionally) evict the user from all the subsequent rooms and Spaces too.
We also need to figure out how to support both knocking and restricted rooms at the same time (oops). MSC3613 and MSC3386 both tackle this problem in different ways and timescales.
A massive shoutout goes to kitsune and the whole community for working on MSC2312, giving us a URI we can pass around outside of Matrix to bring us back in. The early work on this dates all the way back to 2014, the very beginning of Matrix’s development, and has since been marked Provisional by the IANA.
The full spec is available here - feel free to discuss it at matrix:r/matrix-spec:matrix.org ;)
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).
prev_content
field is now returned inside the unsigned
property of events, rather than at the top level, as per MSC3442. (#3524)aliases
property from the chunks returned by /publicRooms
, as per MSC2432. (#3624)GET /_matrix/client/v1/rooms/{roomId}/hierarchy
) as per MSC2946. (#3610)/_matrix/client/v1/register/m.login.registration_token/validity
as per MSC3231. (#3616)/_matrix/client/r0/login
to accept a m.login.appservice
, as per MSC2778. (#3324)restricted
rooms as per MSC3083, MSC3289, and MSC3375. (#3387)is_guest
to /account/whoami
as per MSC3069. (#3605)m.set_displayname
, m.set_avatar_url
, and m.3pid_changes
capabilities as per MSC3283. (#3614)AesHmacSha2KeyDescription
consistent with KeyDescription
in marking name
as optional. (#3481)m.location
events (#3492)403 M_FORBIDDEN
error code to /profile/{userId}
as per MSC3550. (#3530)/sync
API, including a fix to an ASCII art diagram. (#3543)base_url
in client well_known
may or may not include trailing slash. (#3562)m.olm.v1.curve25519-aes-sha2
messages. (#3573)GET /_matrix/federation/v1/hierarchy/{roomId}
) as per MSC2946. (#3610, #3660)GET /_matrix/federation/v1/event_auth/{roomId}/{eventId}
does not return the auth chain for the full state of the room. (#3583)GET /_matrix/app/v1/thirdparty/protocol/{protocol}
. (#3675)unsigned
data of a Federation PDU. (#3522)knock
-> leave
in v7, v8, and v9. (#3694)