Hey all,
Matrix 1.10 is here! We aim to release the specification once in each calendar quarter, and with Q1 wrapping up in a few days we’re due for this quarter’s release. It has been 5 months since the last release (Matrix 1.9) brought in some protocol maintenance for us though, and the implementation teams have been hard at work building the Matrix 2.0 stack concurrent to the Matrix 1.10 work released today.
A total of 9 MSCs are released in Matrix 1.10, covering a wide range of maintenance, Matrix 2.0 preparation, and features for clients to use. This post focuses a bit on the Matrix 2.0 front and what’s expected in Matrix 1.11’s release cycle, but read on to the changelog at the bottom for full details on the changes which make up Matrix 1.10.
MSC3077: Multi-stream VoIP
MSC3077 and its related proposal MSC3291 (muting in VoIP calls) lay some foundational groundwork for proper group VoIP to land in Matrix - an objective of Matrix 2.0. Currently this is taking shape at MSC3898 and MSC3401, though Element’s VoIP team is considering a possible third alternative which runs MSC3401 over something like LiveKit’s SFU - stay tuned for updates there. In the meantime, users in native 1:1 calls can enjoy proper screen sharing and mute capabilities ahead of the 1:N call support later this year.
As always, early review is appreciated though please note that MSC3898 and MSC3401 are particularly in flux at the moment.
Up next in Matrix 1.11 and beyond
Over the next 2-3 months, we’ll be focusing on the following MSCs:
- Trust & Safety improvements (at the protocol level).
- MSC3823 - Account suspension
- MSC3939 - Account locking
- MSC3916 - Authentication for media (time permitting)
- MSC4117 - Reversible redactions (pre-implementation review)
- MSCs around a “reporting v2” flow in light of various legislation and compliance requirements. These MSCs are currently being written and should be up for pre-implementation review within the Matrix 1.11 cycle.
- Early review of Matrix 2.0 features as they become ready.
- Sliding sync (MSC3575) + applicable extensions.
- Group VoIP - Exact MSCs to be determined, as they may change following implementation.
- OIDC Authentication - Exact MSCs to be determined.
- Pre-implementation review of Extensible Events core content blocks MSCs.
Additionally, we’ll be continuing to define the expectations of a Spec Core Team member, particularly as it relates to the upcoming Governing Board for the Foundation. This exercise has been extremely valuable to us so far, and will help identify areas the Foundation and SCT may need support from each other.
The full changelog
Read on for full details of what’s in Matrix 1.10:
Client-Server API
Backwards Compatible Changes
- Allow
/versions
to optionally accept authentication, as per MSC4026. (#1728) - Add local erasure requests, as per MSC4025. (#1730)
- Use the
body
field as optional media caption, as per MSC2530. (#1731) - Add server support discovery endpoint, as per MSC1929. (#1733)
- Add support for multi-stream VoIP, as per MSC3077. (#1735)
- Specify that the
Retry-After
header may be used to rate-limit a client, as per MSC4041. (#1737) - Add support for recursion on the
GET /relations
endpoints, as per MSC3981. (#1746)
Spec Clarifications
- The strike element is deprecated in the HTML spec. Clients should prefer s instead. (#1629)
- Clarify that read receipts should be batched by thread as well as by room. (#1685)
- Clarify that threads can be created based on replies. (#1687)
- Clarify in the reply fallbacks example that the prefix sequence should be repeated for each line. (#1690)
- Clarify the format of account data objects for secret storage. (#1695, #1734)
- Clarify that the key backup MAC is implemented incorrectly and does not pass the ciphertext through HMAC-SHA-256. (#1712)
- Clarify one-time key and fallback key types in examples. (#1715)
- Clarify that the HKDF calculation for SAS uses base64-encoded keys rather than the raw key bytes. (#1719)
- Clarify how to perform the ECDH exchange in step 12 of the SAS process. (#1720)
- Document the deprecation policy of HTML tags, as per MSC4077. (#1732)
- The font element is deprecated in the HTML spec. Clients should prefer span with the
data-mx-bg-color
anddata-mx-color
attributes instead. (#1739) - Disambiguate uses of
PublicRoomsChunk
in theGET /hierarchy
endpoint. (#1740) - Clarify that
sdpMid
andsdpMLineIndex
are not required inm.call.candidates
. (#1742) - Fix various typos throughout the specification. (#1748)
- Clearly indicate that each
Content-Type
may have distinct behaviour on non-JSON requests/responses. (#1756) - Clarify that the
m.push_rules
account data type cannot be set using the/account_data
API, as per MSC4010. (#1763)
Server-Server API
Spec Clarifications
- Clarify Server-Server API request signing example by using the
POST
HTTP method, asGET
requests don't have request bodies. (#1721) - Disambiguate uses of
PublicRoomsChunk
in theGET /hierarchy
endpoint. (#1740) - Clarify that the
children_state
,room_type
andallowed_room_ids
properties in the items of thechildren
array of the response of theGET /hierarchy
endpoint are not required. (#1741)
Application Service API
Spec Clarifications
- Clarify that the
/login
and/register
endpoints should fail when using them.login.application_service
login type without a validas_token
. (#1744)
Identity Service API
No significant changes.
Push Gateway API
No significant changes.
Room Versions
Spec Clarifications
- For room versions 7 through 11: Clarify that
invite->knock
is not a legal transition. (#1717)
Appendices
No significant changes.
Internal Changes/Tooling
Spec Clarifications
- Update the spec release process. (#1680)
- Minor clarifications to the contributing guide. (#1697)
- Update Docsy to v0.8.0. (#1699, #1762)
- Fix npm release script for
@matrix-org/spec
. (#1713) - Add some clarifications around implementation requirements for MSCs. (#1718)
- Update HTML templates to include links to object schema definitions. (#1724)
- Factor out all the common parameters of the various
/relations
apis. (#1745) - Add support for
$ref
URIs containing fragments in OpenAPI definitions and JSON schemas. (#1751, #1754)
The Foundation needs you
The Matrix.org Foundation is a non-profit and only relies on donations to operate. Its core mission is to maintain the Matrix Specification, but it does much more than that.
It maintains the matrix.org homeserver and hosts several bridges for free. It fights for our collective rights to digital privacy and dignity.
Support us