This Week in Matrix

Matrix Live

Dept of Spec 📜

Andrew Morgan (anoa) says

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:

• There were no new MSCs this week.

MSCs in Final Comment Period:

• No MSCs are in FCP.

Accepted MSCs:

• No MSCs were accepted this week.

Closed MSCs:

• No MSCs were closed/rejected this week.

Spec Updates

No movement through the process on the surface for any MSCs according to the above chart, but some things have been happening! Other than the usual background hum of IETF work, conversations across many MSCs have been moving along. We also saw MSC3930 (Polls push notifications) have FCP proposed! The latter would stop a notification from being generated every time someone voted in a poll, which is sorely needed.

A reminder that in keeping with the spec's quarterly release schedule, Matrix v1.8 is due to release this month and Matrix v1.9 is due for November. We want to plan well ahead for the v1.9 release though, so if you would like to see anything in particular land in v1.9, please raise that concern in the Office of the Spec Core Team room!

See this message in the same room for more information including the currently planned v1.9 spec changes.

Random MSC of the Week

The random MSC of the week is... Refine and clarify how presence works!

This is a very old "MSC" (still on google docs), but it's come up and I've seen folks taking a look at revamping presence recently, so I figured it may be interesting to share.

The document lists a number of confusing behaviours that come with the current presence spec (at the time, though it hasn't moved much since then). There is also a bullet-point list of what a redesigned presence could look like.

Given the conversation on the GitHub issue, this document appears lost to time. But perhaps someone will find it useful today.

Continue reading…

Matrix Live

Dept of Spec 📜

Andrew Morgan (anoa) says

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:

• MSC4039: Add an MSC for a new Widget API action to upload files into the media repository

MSCs in Final Comment Period:

• MSC3381: Polls (mk II) (merge)

Accepted MSCs:

• No MSCs were accepted this week.

Closed MSCs:

• No MSCs were closed/rejected this week.

Spec Updates

We've been quite busy at IETF 117 this last week discussing MLS and MIMI in several contexts, meetings, and sessions. Overall things have moved pretty fast in the last week, but the short summary is we're working with MIMI to get (Linearized) Matrix used as the new-found "signalling layer". This layer delegates membership of the room to the crypto layer when the crypto layer (namely MLS) supports being used as such, and is responsible for enforcing all policies. Policies in the context of MIMI are things like join rules, history visibility, and power levels, but with an added twist: we're looking at supporting Role-Based Access Control (RBAC) in combination with power levels in MIMI, which should also bring RBAC to Matrix in the form of a currently-unwritten MSC.

All told, we've got several new documents to write and MSCs to draft, but we'll get there in time. The MIMI working group is expecting solutions in place by about September, so watch this space for more news as we progress. An architecture draft is also in progress on the MIMI side to further explain what all of these new layers mean. In the meantime, if you have questions then please visit the matrix-spec room on Matrix!

We're also looking for more Matrix 1.9 candidates. Currently we have just custom emoji and anything to do with MIMI on the agenda - if you'd like to add more, let us know in the Office of the Matrix Spec Core Team room on Matrix.

Random MSC of the Week

The random MSC of the week is... MSC3062: Bot verification!

This MSC describes a method for verifying (cross-signing) the devices of a bot user, and how verification of that sort could be done. Obviously it wouldn't make much sense to verify emoji with a bot. Instead, this MSC suggests that the bot provide a URL to present to the user. If the URL appears trustworthy (those who would control this URL should also be in charge of this bot), then the user can choose to continue the verification.

The user's Matrix client would then make a request to the URL with details of the verification. If the server responds successfully, some cryptographic magic happens, and your client will consider the bot verified!

This is essentially tying a bot's verification with control of a domain's DNS, which I think is a smart way to do things. But you do need to watch out for those pesky UTF-8 control characters when asking the user to verify the URL!

Continue reading…

Dept of Spec 📜

Andrew Morgan (anoa) says

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:

• MSC4038: Key backup for MLS

MSCs in Final Comment Period:

• No MSCs are in FCP.

Accepted MSCs:

• MSC3291: Muting in VoIP calls

Closed MSCs:

• No MSCs were closed/rejected this week.

Spec Updates

This week we have been preparing for IETF117, Matrix 1.8, Matrix 1.9, and Messaging Layer Security (MLS) for Matrix. Most of our work on globally interoperable communications is ongoing through the More Instant Messaging Interoperability (MIMI) working group at the IETF, and will be making significant strides in the coming days as we head to the IETF117 hackathon and meetup.

Over the last few months we've been working on a version of Linearized Matrix which supports the simplicity of linear event history while being fully compatible with today's Matrix network, and while we think that the 03 draft we wrote up accomplishes a lot of this, there's further work to be done to make it cleaner and easier to use. We've also been writing implementations of it to prove the semantics (and find areas which need improvement), starting with our cleanroom eigen-server TypeScript implementation and interoperating it with a branch of Synapse. During IETF117 we expect more implementations to sprout and have their interoperability tested - watch this space for updates on how that goes.

Aside from IETF117, we're continuing to look at the previously-selected Matrix 1.8 MSCs for release in mid-late August 2023. This might be slow over the next couple of weeks while half of us are at IETF117, but expect more forward progress when we get back. Matrix 1.9 is scheduled to be released sometime in November 2023, and a few months ago we said we were aiming to plan ahead for releases a bit more deliberately. Starting this week, we're accepting submissions for ideas and specific MSCs which need our attention in Matrix 1.9. If you have an MSC (current or future) which will need Spec Core Team (SCT) attention between August 2023 and November 2023, let us know in the SCT Office room. Once Matrix 1.8 is released (exact date TBD) we will have limited availability to add things to the Matrix 1.9 target - please raise your MSCs & themes as soon as possible. The current set of MSCs up for consideration can be found on the SCT Intake Board.

If you've made it this far in our weekly update, congratulations, and thank you. We expect things will rapidly start to happen with IETF117 kicking off tomorrow (July 22, 2023), and we will do our best to keep folks updated. Next week's TWIM in particular will have a post-IETF117 debrief for your reading enjoyment :)

As always, if you have any questions or concerns about what we're working on, visit the SCT Office and let us know. We can't promise a prompt reply (particularly during IETF117), but we will take a look when we can.

Random MSC of the Week

The random MSC of the week is... MSC3105: Previewing UIA flows!

This MSC addresses a shortcoming in the current User-Interactive Authentication (UIA) mechanism where attempting to deduce the required authentication flows for an action will result in that action being carried out if it turns out no flows were required. This makes it tricky for a client to present a "are you sure you want to do X?" as a final step in completing an action that requires authentication.

The proposals aims to allow an OPTIONS pre-flight HTTP request to the same endpoint in order to retrieve the flows necessary, without actually carrying out the action. The proposal does note that using OPTIONS for this case is a bit non-standard though, and some clients may treat the typical 401 error code returned during User-Interactive Auth as a fatal error.

While this does address a flaw in the UIA system, it's worth noting that many other flaws exist! Matrix is planning to move over to an OpenID Connect-based authentication system in the not too distant future, which will likely have far fewer edge cases than our traditional, home-grown one. You can visit https://areweoidcyet.com/ for more information and to track the current progress on that front.

Continue reading…

Matrix Live

Dept of Spec 📜

Andrew Morgan (anoa) announces

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:

• MSC4037: Thread root is not in the thread
• MSC4036: Room organization by promoting threads
• MSC4034: Media limits

MSCs in Final Comment Period:

• MSC3291: Muting in VoIP calls (merge)

Accepted MSCs:

• No MSCs were accepted this week.

Closed MSCs:

• No MSCs were closed/rejected this week.

Spec Updates

Not a lot to say this week. The Spec Core Team is humming along with review, while we also wait for progress of various MSCs from their authors. The full list of what's in flight can be found in this week's Tuesday ping in the Office of the Spec Core Team room.

IETF and MIMI work is still continuing on in the background. Look out for a TWIM in the near future for an update to progress on that front!

Random MSC of the Week

The random MSC of the week is... MSC3192: Batch state endpoint!

This MSC defines an endpoint to send lots of state (max 50 at once) into a room in one go. This sounds useful for all sorts of tasks, and it's a wonder that it hasn't come up before.

If that sounds like an endpoint you'd like to go, give feedback on the MSC linked above!

Continue reading…

Matrix Live

Dept of Spec 📜

Andrew Morgan (anoa) announces

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:

• MSC4033: Explicit ordering of events for receipts

MSCs in Final Comment Period:

• No MSCs are in FCP.

Accepted MSCs:

• MSC4025: Local user erasure requests

Closed MSCs:

• MSC3746: Render image data in reactions
  • An alternative proposal: MSC4027: Propose method of specifying custom images in reactions

Spec Updates

Work to use Matrix as the standard for interoperable messaging at the IETF is continuing in full stride. At IETF 117 (July 22nd - 28th, 2023) we'll be talking about the precise requirements of an interoperable protocol, and encouraging Matrix be that protocol. Linearized Matrix is our proposal for the room model, with more updates expected in the coming days ahead of the submission deadline, meanwhile yours truly is working on using MSC1767 Extensible Events for a content format. Watch this space for updates leading up to IETF 117 🙂

We're also well on track to test interoperability of different Linearized Matrix implementations at the Hackathon - get in touch with us via the #sct-office:matrix.org if you're working on such an implementation so we can coordinate details. It's not too late to get started either; Linearized Matrix itself is relatively simple to implement compared to the full capability of Matrix, by design.

Random MSC of the Week

The random MSC of the week is... MSC3903: X25519 Elliptic-curve Diffie-Hellman ephemeral for establishing secure channel between two Matrix clients!

This MSC provides a means of establishing a trusted, secure communications channel across a potentially untrusted network. Subsequent MSCs could then use this channel to transfer details such as login tokens or key backup credentials in the context of setting up a new Matrix device. MSC3906 is one proposal that takes advantage of this.

This is just one piece of work building on the tree of MSCs supporting the shift of authentication in Matrix from home-brewed to OIDC. See https://areweoidcyet.com/ for more details on that effort.

Continue reading…

Matrix Live

Dept of Status of Matrix 🌡️

Thib announces

You might have seen the news already, but the Matrix.org Foundation is pleased to welcome the first public sector organisation as part of its membership: Gematik joined us as a Silver member!

If you're an organisation of the public sector it might not be obvious why spending money on an open source product is important: you will probably be interested in why it makes sense for gematik to contribute, and how it benefits the public sector in general.

Whether you're an individual, a business, a non-profit, a public sector organisation, you can join the Matrix.org Foundation as a member to support us in our mission and help us steer Matrix in the right direction!

Continue reading…

Matrix Live

Dept of Status of Matrix 🌡️

Thib says

Not only have we formally launched the Matrix.org Foundation membership programme… we're happy to already welcome our first member: Beeper!

Wondering why it makes sense for Beeper to support the Foundation? In short: we're mission-aligned, and it's a strategic business choice.

Thanks again to Beeper for all their contributions to the Matrix ecosystem, and we can't wait for more prospective members to show that they really mean to stand for open, decentralised secure communications 🚀

Continue reading…

Matrix Live

Dept of Spec 📜

Andrew Morgan (anoa) [GMT-6] 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.

MSC Status

New MSCs:

• MSC4030: Progressive image in Matrix
• MSC4029: [WIP] Fixing X-Matrix request authentication
• MSC4028: Push all encrypted events except for muted rooms
• MSC4027: Propose method of specifying custom images in reactions

MSCs in Final Comment Period:

• MSC3989: Redact origin property on events (merge)
• MSC3821: Update the redaction rules, again (merge)
• MSC3077: Support for multi-stream VoIP (merge)

Accepted MSCs:

• MSC4009: Expanding the Matrix ID grammar to enable E.164 IDs

Closed MSCs:

• No MSCs were closed/rejected this week.

Spec Updates

This actually happened last week, but a huge shoutout to Kévin Commaille, aka @zecakeh, for their work on upgrading the OpenAPI schema data for the Matrix Spec to version 3.1. This schema describes all of the requests and responses for all endpoints in the spec, as well as various event types and other bits and pieces. It directly powers the Matrix spec website, the Matrix API Playground and several Client and Homeserver SDKs that generate code from it.

With a diff of +14,997 −12,660, this was a multi-month effort of both implementation and review (thank you @richvdh and @KitsuneRal!). This change will allow us to use all the new features that OpenAPI 3 has to offer, as well as generally keeps us up to date with modern tooling.

Thank you!

Random MSC of the Week

The random MSC of the week is... MSC3051: A scalable relation format!

This MSC describes a different way of describing how an event relates to other events. In the current Matrix spec, you can use the m.relates_to property to indicate that this event (say, a reaction) relates to another event (say, a message) in a certain manner. You can specify how it relates using the m.relates_to->rel_type key; a value of "m.annotation" for reactions.

But sometimes you may want to relate to multiple other events. For instance, what if that message you're reacting to is also in a thread? In fact, this MSC has come up recently as one possible way to solve the problem of efficiently discerning whether an event should belong in a thread or not (discussion). This MSC isn't the only option for solving such a problem - MSC4023 would also work, and both have tradeoffs.

MSC3051 could also allows for actions such as editing replies; both the text and the message it was a reply to. Neat!

Do read the MSC and give feedback if relations is something that excites you.

Continue reading…

Matrix Live

We didn't have time for a Matrix Live this week, but don't miss next week's episode!

Dept of Spec 📜

TravisR says

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:

• MSC4026: Allow /versions to optionally accept authentication

MSCs in Final Comment Period:

• MSC4009: Expanding the Matrix ID grammar to enable E.164 IDs (merge)

Accepted MSCs:

• No MSCs were accepted this week.

Closed MSCs:

• No MSCs were closed/rejected this week.

Spec Updates

On the Spec Core Team (SCT), we've started converting the list of MSCs we received into a roadmap for the next 8-ish weeks. This is all to prepare for Matrix 1.8, and we're already starting to think a bit about what Matrix 1.9 looks like too. You can see what the team plans to look at here - each column is ordered in relative priority, where the top is more likely to receive attention first. Not everything is actionable at the moment, but that's the point 😄 As we work through the next month or so, the remaining MSCs should be unblocked or near-unblocked enough to allow the SCT to make progress on them.

Most of the MSCs on the roadmap have a target state of acceptance (and merge, if we can make that happen), though some do have a simple task of reviewing the MSC ahead of implementation effort. We're aiming to test this process over the next few releases, where the SCT unblocks progress by providing review ahead of review actually being needed, but to do that we need to know what people plan to work on. If you have something which could do with review (not just acceptance) in the August-November window of time, let us know in the SCT Office.

As always, if you have questions about a particular MSC's state or what this process actually means, let us know in the SCT Office.

Meanwhile, the SCT is continuing its IETF/MIMI adventures by pushing Linearized Matrix towards working group adoption. The current stages involve updating the Internet-Draft (I-D, or MSC in IETF terms) to cover the MIMI-specific bits of the room model and working on multiple implementations of the proposal. We'll be updating the MSC at a later stage to account for the DAG interop components, though how to get a DAG to work with the linear, append-only, MIMI variant is very much top of mind. You can see the current rapidly-changing I-D here.

As mentioned, to further adoption of Linearized Matrix within MIMI we're looking for independent implementations. "Independent" here means not written by the Matrix Core Team and not written by Element given the potential for conflict of interest, though the Matrix team is working on proving the I-D through eigen-server and possibly a dual-stack Synapse (watch this space). We have a line on ~2 completely independent (but undisclosed 😇) Linearized Matrix implementations already, but more is often better for these things: if you work for a messaging service provider and are interested in writing an implementation, get in touch with us so we can coordinate some interop testing. You don't already have to be using Matrix to write an implementation, and in fact it's probably better if you aren't already using Matrix, awkwardly.

Random MSC of the week

The script of fate has decided to put forward MSC3060: Room Labels this week. This is a relatively small MSC, but one which provides a ton of value to discovering rooms. The labels/topics your room covers are listed in a state event and can inform users of what to expect beyond the room name/avatar. For example, if your room has primarily NSFW/18+ content, you can disclose that in the labels.

Leave your thoughts and concerns on the MSC via threads on the diff 🙂

Continue reading…

Matrix Live

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.

MSC Status

New MSCs:

• MSC4025: Local user erasure requests
• MSC4023: Thread ID for 2nd order-relation
• MSC4021: Archive client controls

MSCs in Final Comment Period:

• No MSCs are in FCP.

Accepted MSCs:

• No MSCs were accepted this week.

Closed MSCs:

• MSC3523: Timeboxed/ranged relations endpoint

Spec Updates

Part of the SCT's goals with Matrix 1.8 is to pre-plan the majority of our review attention, which means we need to be told what folks are working on to plan accordingly. We'll still have some room for random/surprise MSC work, but this is expected to be harder to acquire going forward (and so should not be relied upon).

Please let us know if you're working on something which affects the spec! We want to hear about:

• things that aren't MSCs (yet)
• things that are MSCs but aren't planned to be merged in 1.8
• MSCs which are expected to be ready in time for Matrix 1.8 (in ~2 months)

If you aren't sure if your project affects the spec, talk to us about it. We do not want to be the bottleneck in your development cycle, instead preferring to know ahead of time that something will need attention from us.

All we need is for you to mention your project/MSC and timeline in the #sct-office:matrix.org - DMs and private rooms with SCT members are not enough to get something on the roadmap. This is to ensure there is full transparency in why the SCT is looking at something, and to ensure that the MSC moves through the process in an efficient manner. If your project has a sensitive context (commercial or otherwise), then we ask that you reference that here and someone from the team will contact you to get more information, relaying as much (non-sensitive) detail as possible back to the room here.

Our expected outcome for this system is to not only be a more effective team, but also to give you a faster/more reasonable turnaround on MSC review (at all stages), more rapid deployment of stable features (dropping unstable prefixes), and overall fewer review iterations as the SCT can think about problems ahead of you actually needing a review. We seriously do not want to be a blocker, but we need to know what we could end up blocking by accident.

Starting approximately August 1st, we will be starting to plan out what Matrix 1.9's release cycle will look like. A similar call to action will be raised at that point. Note that Matrix 1.8 is set to be released in late August, meaning we're aiming to have Matrix 1.9 thought out before Matrix 1.8 is released, which is a deliberately accelerated timeline than the current Matrix 1.8 release cycle planning.

As always, if you have any questions about this, please let us know in #sct-office:matrix.org.

Random MSC of the Week

The random MSC of the week is... MSC3869: Read event relations with the Widget API!

This MSC would allow Matrix Widgets, knowing an event ID, to request any and all other events that relate to it. Thus, if you had a m.room.message event, you could ask the client whether any edits have been made to that event, via asking for m.room.message events with m.replace relations.

This would be useful for Widgets to traverse any data structure that used relations to tie together events - which could model all sorts of use cases!

As always, leave your feedback on the MSC if this is something you're interested in or want to push forwards :)

Continue reading…