Matrix v1.2 release
02.02.2022 18:57 — Releases — Travis RalstonHey 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.
Rearchitecting with Spaces
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.
Public, but not too public, join rules
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.
Matrix: A URI
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 ;)
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
Breaking Changes
- The
prev_content
field is now returned inside theunsigned
property of events, rather than at the top level, as per MSC3442. (#3524) - The
aliases
property from the chunks returned by/publicRooms
, as per MSC2432. (#3624)
New Endpoints
- Add the Space Hierarchy API (
GET /_matrix/client/v1/rooms/{roomId}/hierarchy
) as per MSC2946. (#3610) - Add
/_matrix/client/v1/register/m.login.registration_token/validity
as per MSC3231. (#3616)
Backwards Compatible Changes
- Extend
/_matrix/client/r0/login
to accept am.login.appservice
, as per MSC2778. (#3324) - Add support for
restricted
rooms as per MSC3083, MSC3289, and MSC3375. (#3387) - Add
is_guest
to/account/whoami
as per MSC3069. (#3605) - Expand guest access to sending any room event and state event as per MSC3419. (#3605)
- Add Spaces and room types as per MSC1772 and MSC2946. (#3610)
- Add new
m.set_displayname
,m.set_avatar_url
, andm.3pid_changes
capabilities as per MSC3283. (#3614) - Add support for fallback keys (optional keys used once one-time keys run out), as per MSC2732. (#3615)
- Add token-authenticated registration support as per MSC3231. (#3616)
Spec Clarifications
- Make
AesHmacSha2KeyDescription
consistent withKeyDescription
in markingname
as optional. (#3481) - Fix various typos throughout the specification. (#3482, #3495, #3509, #3535, #3591, #3601, #3611, #3671, #3680)
- Explicitly mention RFC5870 in the definition of
m.location
events (#3492) - Add
403 M_FORBIDDEN
error code to/profile/{userId}
as per MSC3550. (#3530) - Clarify the description of the
/sync
API, including a fix to an ASCII art diagram. (#3543) - Clarify that
base_url
in clientwell_known
may or may not include trailing slash. (#3562) - Clarify which signature to check when decrypting
m.olm.v1.curve25519-aes-sha2
messages. (#3573) - Clarify what "Stripped State" is and what purpose it serves, as per MSC3173. (#3606)
- Clarify how to interpret missing one-time key counts. (#3636)
- Correct the schema for the responses for various API endpoints. (#3650)
- Clarify that group mentions are no longer in the specification. (#3652)
- Distinguish between "federation" event format as exchanged by the Federation API, and the "client" event formats as used in the client-server and AS APIs. (#3658)
- Fix the rendering of the responses for various API endpoints. (#3674)
Server-Server API
New Endpoints
- Add the Space Hierarchy API (
GET /_matrix/federation/v1/hierarchy/{roomId}
) as per MSC2946. (#3610, #3660)
Backwards Compatible Changes
Spec Clarifications
- Fix various typos throughout the specification. (#3527)
- Clarify that
GET /_matrix/federation/v1/event_auth/{roomId}/{eventId}
does not return the auth chain for the full state of the room. (#3583) - Fix the rendering of the responses for various API endpoints. (#3674)
Application Service API
Spec Clarifications
- Distinguish between "federation" event format as exchanged by the Federation API, and the "client" event formats as used in the client-server and AS APIs. (#3658)
- Fix the rendering of the responses for various API endpoints. (#3674)
- Correct the documentation for the response value for
GET /_matrix/app/v1/thirdparty/protocol/{protocol}
. (#3675)
Identity Service API
Backwards Compatible Changes
Spec Clarifications
- Fix the rendering of the responses for various API endpoints. (#3674)
Push Gateway API
Spec Clarifications
- Fix the rendering of the responses for various API endpoints. (#3674)
Room Versions
Backwards Compatible Changes
Spec Clarifications
- Fully specify room versions to indicate what exactly is carried over from parent versions. (#3432, #3661)
- Clarifications to sections on event IDs and event formats. (#3501)
- Remove a number of fields which were incorrectly shown to form part of the
unsigned
data of a Federation PDU. (#3522) - Fix heading order of room version specifications to be consistent. (#3683)
- Add missing "Signing key validity period" section to room version 6. (#3683)
- Fix auth rules to allow membership of
knock
->leave
in v7, v8, and v9. (#3694)
Appendices
Backwards Compatible Changes