Dept of Social Good 🙆
we know there have been some questions about the recent ban on Element by the Indian Central Government. We are still trying to get answers ourselves and have put out a public statement on our understanding of the situation so far: https://element.io/blog/india-bans-flagship-client-for-the-matrix-network/
Dept of Spec 📜
Andrew Morgan (anoa) reports
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.
- MSC4011: Thumbnail media negotiation
- MSC4010: Push rules and account data
- MSC4009: E.164 Matrix IDs
- MSC4006: "completed elsewhere" hangup reason.
- MSC4005: Explicit read receipts for sent events
MSCs in Final Comment Period:
- MSC3882: Allow an existing session to sign in a new session (merge)
- MSC3860: Media Download Redirects (merge)
- MSC2659: Application service ping endpoint (merge)
- MSC2463: Exclusion of MXIDs in push rules content matching (close)
- MSC2249: Require users to have visibility on an event when submitting reports (merge)
- No MSCs were accepted this week.
- No MSCs were closed/rejected this week.
Lots of MSCs moving through the pipeline this week! Plus a myriad of spec changes too! The spec seems to be gently humming along.
In other news, the next release of the spec, v1.7, is coming up in the not-too-distant future. In keeping with our roughly quarterly release schedule - the release of v1.6 was on February 14th, 2023 - a new release of the spec should come some time in next few weeks.
We haven't set a date yet, but expect to do so soon. So watch this space!
Random MSC of the Week
The random MSC of the week is... MSC3741: Revealing the useful login flows to clients after a soft logout!
This MSC fixes an edge case in the spec. Imagine the following scenario. You're logged into your homeserver via an SSO flow (let's say by signing into GitLab), and then you try to change your password on GitLab. Doing so may cause a "soft logout" to occur for your Matrix client. A soft logout, by the way, happens when your access token is invalidated, but your client is told explicitly not to wipe its local state (including encryption keys).
Your Matrix client is telling you to log back in again, and in doing so calls out to the
GET /_matrix/client/v3/loginendpoint to see what login methods are available. Your homeserver supports both password-based and SSO-based login, so that's what you get back. Your client happily presents you both options. You try to type your GitLab password, but it's incorrect. And you've just given your GitLab password to this Matrix homeserver in plaintext - oh no!
The problem here stems from the fact that
GET /loginis unauthenticated. The homeserver doesn't know who you are when you attempt to log in again, and thus can't tailor the available login methods to those that make sense for you. This MSC aims to fix this by having your Matrix client, upon trying to learn how to log in again after a soft logout, provide your expired access token in an
Authorizationrequest header. The homeserver can then check and see that 1) you were just soft logout'd and 2) you are an account that is authorised via SSO - so it doesn't make sense to suggest you log in again via a password specific to your Matrix homeserver!
While this MSC discusses a valuable solution, it is worth considering that the User-Interactive Authentication system as a whole is going to be completely replaced by OpenID Connect instead, which will make this problem (and solution) moot. Still, that day is not here yet, so if you suffer from this problem today, this may be one method to deal with it.