Hey all,
Once again it's been a little while since we've done a spec release (sorry; we're aiming for quarterly releases from here on out), but this time we have some pretty big news: we've got an all-new spec platform and a new versioning scheme. The new spec platform has been needed for a long time to make better sense of what Matrix is, and as part of getting that out the door we reduced the number of "Matrix versions" to just one.
Huge thanks to Will Bamberg for building it out for us, anoa for working out the deployment details, and everyone for testing it all. They talk at length about what this specification even is and about the platform itself on Matrix Live S6E19. It's the single greatest improvement to the spec we've seen to date.
The new versioning scheme presents the whole specification as a single document, making it easier to check compatibility between implementations and the spec itself. Previously, a grid would have to be drawn to show whether Server-Server r0.1.4 is compatible with Client-Server r0.6.1 - while obvious at release time, the historical context gets lost quite easily. Now, with a single version number, the entire specification is compatible across a single version number: servers implementing Matrix 1.1 will be compatible with clients implementing v1.1, and vice versa. For the specification itself, this means we no longer have to carefully point and update links between the APIs, as they'll instead be versioned together.
Changing the versioning of the specification does have an impact on the Client-Server API in particular, however. You may have noticed that Client-Server APIs are currently versioned at "r0". By removing rX.Y.Z versioning, all of the endpoints suddenly don't have a version to reference. All endpoints across the specification are now versioned individually to allow for breaking changes at the endpoint level. They no longer require the whole specification to be listed as a breaking change: a v1 endpoint can get additions/changes which are backwards compatible, but if we need to change format (for example) then it'll get bumped up to v2, leaving v1 in its last known state.
For the Client-Server API, a slight complication is that v1 and v2 (alpha) are already versions familiar to those that have been around for a while - to avoid confusing those people, existing Client-Server API endpoints will start at v3. New endpoints introduced after v1.1 will start at v1 instead.
It's been well over a year since the last release, which means there's a whole lot of features and changes to cover. Here we'll try to cover the things most clients/servers will have to worry about, but we do still recommend reading through the changelog included below. Overall, 28 MSCs have been merged through this release, but some have had to be excluded in the interest of getting the spec release out there. Many of them are expected to be in the next anticipated release (which should hopefully be next quarter).
In Matrix 1.1, client developers get all sorts of new features to play with. Clients which support end-to-end encryption should explore key backups, cross-signing, SSSS, and breaking changes to verification. Quite a lot of this stuff has existed for a while, but has made it into the specification formally now. As an added bonus, the emoji for SAS verification have been translated (contribute here).
Knocking has also landed in the spec (thanks Sorunome for leading the charge on this!), opening up the ability for rooms to optionally allow people to request invites to join. This can be helpful for semi-private rooms where it can be easier to approve/deny requests compared to finding someone's MXID and manually inviting them. This does require a v7 room to work, however.
Thanks again to Sorunome, Message Spoilers have been officially included in Matrix. People can now safely discuss the ending to the latest movie without being banned for spoilers. Though, as a new feature, there's a chance that the spoiler text still gets included in the message: clients should update as soon as possible to avoid their users accidentally getting banned for spoiling the conclusion to the Spaces saga ;)
There's a few other smaller improvements/additions, and of course the regular "various clarifications and bug fixes" to take a look at. For a sample checklist, check out element-web's issue on the subject.
Room version 7 has landed, bringing forth the ability for users to knock on rooms (requesting an invite to join). The changes are largely scoped to using the reserved keywords for join rules and membership, and are described through the auth rules. Thankfully, the changes over v6 are minimally invasive so should be quick to implement.
Additionally, the cross-signing bits have been included in the API responses and EDU definitions. Matthew's blog post from last year (it really has been that long...) describes cross-signing and the history of its implementation.
As per usual, there's also various specification errors corrected to aid understanding. Synapse has an exhaustive issue to detail what servers might need to do.
PS: Room versions 8 and 9 are also out there, but will be included in a future spec release.
We haven't mentioned identity servers, bridges, etc in this post but they have changes too! Below is the whole changelog, the entire year and a bit of it. Thank you to everyone who has submitted MSCs, and congratulations on getting them released. If we forgot yours, please mention it in #matrix-spec:matrix.org so we can apologize and correct.
PS: The MSC process is how changes to Matrix are made, and you (yes, you) can propose those changes too. Check out the Matrix Live episode where Matthew talks about how this process works, and how we avoid blocking clients from implementing their proposals behind the relatively slow spec release cycles.
curve25519-hkdf-sha256
key agreement method for SAS verification, and deprecate old method as per MSC2630. (#2687)m.key.verification.ready
and m.key.verification.done
to key verification framework as per MSC2366. (#3139)m.key.verification.request
as per MSC3122. (#3199)/room_keys/*
) endpoints as per MSC1219. (#2387, #2639)POST /keys/device_signing/upload
and POST /keys/signatures/upload
as per MSC1756. (#2536)/knock
endpoint as per MSC2403. (#3154)/login/sso/redirect/{idpId}
as per MSC2858. (#3163)m.login.oauth2
and m.login.token
user-interactive authentication mechanisms as per MSC2610 and MSC2611. (#2609)POST /keys/query
as per MSC1756. (#2536)device_id
parameter to login fallback as per MSC2604. (#2709)reason
on all membership events and related endpoints as per MSC2367. (#2795)M_NOT_FOUND
error to push rule endpoints as per MSC2663. (#2796)reason
and score
parameters optional in the content reporting API as per MSC2414. (#2807)color
attribute as per MSC2422. (#3098)<details>
and <summary>
to the suggested HTML subset as per MSC2184. (#3100)m.login.sso
as per MSC2858. (#3163)device_id
to /account/whoami
response as per MSC2033. (#3166)FAIL_PROMPT
as per MSC2284. (#3169)v3
as a starting point instead of r0
as per MSC2844. (#3421)age
and unsigned
being shown in the wrong places. (#2591)room_id
from /sync
examples. (#2629)title
s. (#2647)m.key.verification.accept
and secret storage. (#2653)highlight
tweak for consistency. (#2670)state
for /sync
with lazy-loading. (#2754)m.room.redaction
event. (#2814)messages
as a required JSON body field in PUT /_matrix/client/r0/sendToDevice/{eventType}/{txnId}
calls. (#2928)client_secret
request body parameters so that they do not include invalid characters. (#2985)m.presence
. (#3091)Access-Control-Allow-Headers
recommendation to fit CORS specification. (#3225)replacement_room
is a room ID in m.room.tombstone
events. (#3233)/sync
, /rooms/{room_id}/messages
, /initialSync
, /rooms/{room_id}/initialSync
, and /notifications
. (#3353)redacted_because
is meant to work. (#3411)mimetype
from EncryptedFile
examples, as per MSC2582. (#3412)/versions
endpoint. (#3420)threepid_creds
. (#3471)GET /user/keys
and GET /user/devices/{userId}
, m.device_list_update
EDU, and a new m.signing_key_update
EDU as per MSC1756. (#2536)GET /_matrix/federation/v1/make_join/{roomId}/{userId}
can return a 404 if the room is unknown. (#2688)/_matrix/federation/v1/user/devices/{userId}
response which actually returns "self_signing_key"
instead of "self_signing_keys"
. (#3312)<hostname>
TLS certificate is needed rather than <delegated_hostname>
for SRV delegation. (#3322)prev_events
. (#3340)/versions
endpoint. (#3459)Hey all,
It's been a little while since we've done a spec release, so here we are with Room Version 6, Client-Server r0.6.1, and Federation r0.1.4.
Room Version 6 (and the associated Federation r0.1.4 release) is largely something for implementations to worry about. It contains new event authorisation rules, changes to the redaction algorithm, and stricter compliance for JSON.
Client-Server r0.6.1 contains a number of clarifications as well as SSO support for authorisation, "soft logout" to avoid needlessly destroying e2e history, and new ways to publish aliases within rooms.
If you're wondering where all the E2E-by-default related MSCs are - we're doing final iterations based on the real-world feedback from the E2E-by-default launch a few weeks ago, and they are then expected to land in the upcoming Client-Server r0.7.
Here's all the MSCs that got merged since the last release:
query_auth
federation endpoint/rooms/{roomId}/aliases
for retrieving local aliases for a room. (#2562).m.rule.contains_user_name
default push rule to set the highlight tweak. (#2519)event_id
is returned when sending events. (#2525)/createRoom
. (#2571)POST /publicRooms
endpoint for filtering the room directory. (#2305)/send_join
and /send_leave
endpoints per MSC1802. (#2547)prev_events
and auth_events
for PDUs. (#2538)/send
endpoint. (#2560)/send_join
. (#2575)Hey all,
For the last several months the team has been working on tightening up privacy in Matrix, and with the 1.4 release of Synapse and Riot quite a lot has been done in the area. One of the remaining pieces was to release all the specification changes to help other client/server implementations achieve the same goals, and now we've done that.
The Client-Server r0.6.0 and Identity Service r0.3.0 spec releases both cover the privacy improvements added through a number of MSCs in the last few months. Of particular note is that identity servers are now expected to support terms of service endpoints, which requires authentication that clients might need to worry about - check the spec changelogs for details.
The full changelog for the Client-Server r0.6.0 release is:
Breaking Changes
New Endpoints
POST /account/3pid/unbind
for removing a 3PID from an identity
server.
(#2282)Backwards Compatible Changes
M_USER_DEACTIVATED
error code.
(#2234)bind_msisdn
and bind_email
from /register
now that the
identity server's bind endpoint requires authentication.
(#2279)m.identity_server
account data for tracking the user's
preferred identity server.
(#2281)id_server
and make it optional in several places.
(#2310)Spec Clarifications
m.room.message$m.notice
schema.
(#2125)url
field of certain
m.room.message
msgtypes.
(#2129)m.key.verification.start
and its
m.sas.v1
variant.
(#2132).m.rule.room_one_to_one
push rule.
(#2152)/rooms/:roomId/event/:eventId
returns a Matrix error.
(#2204)state_key
check on .m.rule.tombstone
.
(#2223)m.room_key_request
action
value, setting it from
cancel_request
to request_cancellation
.
(#2247)submit_url
field is without authentication.
(#2341)/context
.
(#2344)/sync
.
(#2345)The full changelog for the Identity Service r0.3.0 release is:
New Endpoints
Backwards Compatible Changes