Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.
MSC Status
New MSCs:
MSCs in Final Comment Period:
Accepted MSCs:
Closed MSCs:
- No MSCs were closed/rejected this week.
Spec Updates
Last week we mentioned that we'd have more to share this week about an easier API for accessing rooms in Matrix, and while it was our intention to have an MSC out by now, our priorities shifted slightly after the MIMI working group session at IETF 116. Some exciting news on that front though: our proposed easier API, called Linearized Matrix (apologies to all the mathematicians), is very much in line with what the working group is thinking about. So much so that we're going through the effort of writing up Matrix as a series of proper Internet-Draft specifications.
We don't currently have an up-to-date document which covers Linearized Matrix completely, but the short version is it allows a server to support individual rooms being linear arrays instead of DAGs. This doesn't prevent a DAG-capable server from joining the room and speaking full-blown DAG either, which is particularly important for compatibility with the existing Matrix network. Currently our efforts on Linearized Matrix are in implementation rather than documentation, though once things are slightly more stable we'll be getting an MSC out there for everyone to review more easily. Watch this space for news.
Following IETF 116, we have an immense amount of work ahead of us to define Matrix as the standard for interoperable chat, but we're well on our way on getting through it all. Namely, we're going around and mapping Matrix's functionality onto MIMI's concepts, defining Matrix as a proper IETF standard along the way. The expected outcome of this for the implementation authors of Matrix is a spec that is significantly easier to follow, finally.
For an idea of what's ahead, here's what the SCT will be looking at over the next several months:
- Linearized Matrix (implementation & MSC)
- Extensible Events (at least the core types) - this will serve as the basis for an interoperable messaging format in our IETF drafts
- Decentralized MLS & interoperability of crypto
- Clarification gaps and bugs in the current spec
- Pseudonymous user IDs and account portability
- Almost certainly something that was missed when writing this list
Considering the above list, the Matrix 2.0 objectives (sliding sync, OIDC, native VoIP conferencing, and faster room joins), and the core team's work around mentions, abuse reporting, and more, the SCT will be a bit busy. That said, if you have MSCs you think we should be looking at, let us know in the #sct-office:matrix.org room. We've recently started doing our weekly planning in that room too, which should help give an idea for what the SCT is expecting to look at each week.
Random MSC of the Week
The random MSC of the week is... [WIP] MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix!
This MSC provides a mechanism for implementing Dynamic Client Registration (RFC 7591) for OAuth 2.0 between Matrix clients and homeservers. Without this, homeserver admins would need to manually configure OAuth metadata (Redirect URIs, application names, client secrets, and more) for every Matrix client that wanted to connect to the homeserver. Since that doesn't really scale in an environment that allows anyone to use any client they like, dynamic registration is critical! Dynamic registration allows clients to communicate this metadata to the homeserver at the login/registration step.
MSC2966 is part of a series of MSCs that add first-class OpenID Connect (OIDC) support to Matrix. You can see an overview of the related MSCs (here) and https://areweoidcyet.com/ for the latest progress on integrating OIDC into the Matrix spec!
