This Week in Matrix

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:

• MSC3980: Dotted Field Consistency
• MSC3979: Revised feature profiles
• MSC3977: Matrix as a Messaging Framework (IETF/MIMI)

MSCs in Final Comment Period:

• MSC1796: improved e2e notifications (close)

Accepted MSCs:

• No MSCs were merged this week.

Closed MSCs:

• MSC3978: Deprecate room tagging

Spec Updates

The Spec Core Team has started to publish their weekly list of MSCs to focus on reviewing in the Office of the Spec Core Team room. The list consists of the MSCs that are ready for immediate review, and would most help advance the Matrix protocol on any given week. This used to happen internally (they started out as weekly ping by a bot, and then slowly became curated by our resident human, Travis). But the idea to publish the list both allows people to easily follow along with what they're doing on a weekly basis (much like these posts, but in real time!), as well as helps push subsequent discussion to public channels.

Otherwise, Travis continues to be hard at work integrating Matrix into the IETF process. MSC3923 - initially published in November 2022 - was proposed for FCP this week (and has nearly passed!). Additionally, MSC3977 was published this week and talks about how Matrix is a great fit for the goals of the IETF's MIMI working group.

This is all ahead of the IETF 116 event which starts on March 26th. The Matrix.org Foundation will be attending remotely.

Random MSC of the Week

The random MSC of the week is... MSC3735: Add device information to m.room_key.withheld message!

This MSC proposes adding a new field, from_device, to m.room_key.withheld messages. This to-device message type is used to inform devices why a megolm session was not sent to them after they requested it.

Devices can request megolm sessions from multiple devices at once, but upon receiving a m.room_key.withheld message from one of them is currently unable to tell which of the devices responded with that message.

The proposed from_device field should not be added to m.room_key.withheld messages that are sent outside of key request flows.

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:

• MSC3975: rel_type for Replies

MSCs in Final Comment Period:

• No MSCs are in FCP.

Accepted MSCs:

• MSC3966: event_property_contains push rule condition
• MSC3873: event_match dotted keys
• MSC3758: Add event_property_is push rule condition kind

Closed MSCs:

• No MSCs were closed/rejected this week.

Spec Updates

Review this week from the SCT focused on the future of OIDC and logging in via a QR code (MSC3906) - a feature other platforms have and one I would love immensely. Fixing notifications (MSC3966, MSC3873, MSC3758, MSC3952, MSC3958) as per last week, as well as trying to finally get MSC2677 (spec'ing the current state of Annotations and Reactions) into FCP.

Random MSC of the Week

The random MSC of the week is... MSC3972: Lexicographical strings as an ordering mechanism!

While there already is an MSC for a top-level ordering of Spaces in use across some client implementations today (MSC3230), the algorithm recommended for clients to implement apparently has some consistency flaws, leading to edge cases. MSC3972 attempts to address this by providing a different algorithm that does not have these flaws. A real-world implementation of the algorithm is also available today in Kotlin at https://github.com/Dominaezzz/MatrixSort.

Neither of these algorithms have been merged to the spec yet, but this new MSC may finally push this conversation forwards! I recommend client developers give it a read and leave their feedback as Pull Request Review comments on the MSC.

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:

• MSC3973: Search users in the user directory with the Widget API
• MSC3972: Lexicographical strings as an ordering mechanism
• MSC3971: Sharing image packs

MSCs in Final Comment Period:

• MSC3966: event_property_contains push rule condition (merge)
• MSC3873: event_match dotted keys (merge)
• MSC3758: Add event_property_is push rule condition kind (merge)

Accepted MSCs:

• No MSCs were accepted this week.

Closed MSCs:

• MSC3887: List matching push rules

Spec Updates

Other than spec text fixes in the matrix-spec repo, the Spec Core Team has mainly been focusing on push notifications, push rules and generally improving notifications across Matrix. This includes improving behaviour such as accidentally notifying someone when you mention their name, accidentally notifying people when you reply to a message, accidentally notifying when you edit a message and so on. The relevant MSCs are MSC3958, MSC3873, MSC3966 and MSC3758.

In addition, review of MSC3575 (Sliding Sync) and other sliding sync MSCs saw some in-depth review from Nico.

Random MSC of the Week

The random MSC of the week is... MSC3013: Encrypted Push!

When you get a push notification for a new message on your phone, you may wonder how that message travels from your homeserver to you. Typically it isn't done directly - instead, when you receive a message that should notify you, your homeserver will generate a push notification specifically for you, and send this off to a Matrix Push Gateway. That Push Gateway is then configured to send your notification off to a service which knows how to route it to your device. This is usually Apple's Push Notification Service in the case of iOS devices, or Google's Firebase Cloud Messaging service in the case of Android devices (though FCM supports iOS devices too!). Your phone's OS will keep a consistent connection to one of these services if an app has registered for push notifications, and thus you can receive notifications from apps even when your Matrix client is not running.

But doesn't that leak all of your message notifications to Apple or Google? 😱 Not quite. While clients can choose to include all contents of a message in a push notification, most instead opt for only including the event's ID. When the push notification containing that event ID reaches your phone, it wakes up a small portion of your Matrix client which goes and fetches the full message content from the homeserver (plus encryption keys if the message needs to be decrypted). This way, you can still get a notification without your Matrix client needing to be open all the time. However, some metadata (such as when you are getting a notification) is still leaked to Apple/Google. Since the third-party service knows the event ID, it can correlate which users are in the same room by cross-referencing event IDs in notifications across multiple users.

It's also a bit of a resource drain that the client needs to go and talk to the homeserver to fetch the full event content. Ideally we'd just include it all in the notification - but then we end up sharing too much information with the push provider!

This MSC proposes a solution; encrypt the message content and send that in the notification! Message contents are encrypted using a public key provided by the client to the homeserver when registering for push notifications. The ciphertext passes through the Push Gateway (which may be run by a separate entity to your homeserver) and the Push Notification service (run by Apple, Google, etc.) and then finally down to your client where it is decrypted without the need for a web request as the private key will just be stored in the client.

And since a separate encryption key is being used per-device, ciphertexts of the same event will differ when encrypted for different users - eliminating the Push Gateway/Push Notification Service from being to correlate notifications across users (timing attacks are still possible, but this can be reduced by introducing a small amount of jitter into when notifications are sent out).

Anyhoo, if you're big on privacy (or security against those running Push Gateway/Notification Services), check out this MSC!

Continue reading…

Matrix Live

Transcription (Community made): https://en.miki.community/wiki/Matrix_Tutorial_7

Dept of Spec 📜

TravisR 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

Merged MSCs:

• MSC3925: m.replace aggregation with full event

Closed MSCs:

• MSC2000: Server-side password policies

MSCs in Final Comment Period:

• No MSCs are in FCP.

New MSCs:

• MSC3970: Scope transaction IDs to devices
• MSC3969: Size limits
• MSC3968: Poorer features

Spec Core Team

In terms of Spec Core Team MSC focus for this week, we've been aiming to get the requirements for MSC3952: Intentional Mentions landed as well as discussing MSC3952 itself, in addition to planning out what the next few spec releases are expected to look like.

Watch this space for progress on the Matrix 2.0 MSCs and other critical path items :)

Curated MSC of the week

This week's random chosen MSC is MSC3575: Sliding Sync! It's one of the largest (or is the largest?) MSCs we've ever had, and dramatically changes how clients actually get updates from the server. It's worth the read if you're a client developer, though the team working on it is ironing out some bugs. Let us know what you think on the MSC :)

The Chart

It seemingly was okay with being generated this week again, so here it is:

Continue reading…

Matrix Live

Thib was away this week, Matrix Live is finally coming back next week!

Dept of Status of Matrix 🌡️

Gitter

madlittlemods (Eric Eastwood) says

If you didn't already catch it this week, Gitter has fully migrated to Matrix! 😎

We brought over all of the historical Gitter content to the gitter.im homeserver and gave everyone free rein over it via app.gitter.im, a Gitter branded Element instance.

Of course, since it's Matrix, you can use whatever client you want to access your public, private and one to one (now DM) conversations!

You can read about the full details in the blog post: https://blog.gitter.im/2023/02/13/gitter-has-fully-migrated-to-matrix/

Happy chatting! 🤠

Dept of Spec 📜

TravisR 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

Merged MSCs:

• No MSCs were merged this week.

MSCs in Final Comment Period:

• MSC3925: m.replace aggregation with full event (merge)

New MSCs:

• MSC3967: Do not require UIA when first uploading cross signing keys

Spec Core Team

The Spec Core Team has been busy working away at Matrix 1.6 (released earlier in the week) and aiming to get MSC3925: m.replace aggregation with full event, MSC3952: Intentional Mentions, and MSC2677: Annotations and reactions and all of their dependencies through the spec process. These are all MSCs the SCT has been asked to help get through the process - if there's an MSC we should be looking at, please let us know in #sct-office:matrix.org.

IETF/MIMI/DMA

With the Extensible Events Core (MSC1767) being accepted last week, the focus now turns to all the other extensible event MSCs for images, files, etc. How does extensible events relate to IETF/MIMI/DMA, you ask? In our mission for having Matrix be the standard for interoperability, we need a content format that works for everyone. Events prior to MSC1767 could work with enough effort, though MSC1767's system makes things a lot easier when representing arbitrarily complex messaging features.

Stay tuned to TWIM for progress in this area. It's a relatively slow process, but we're working through it.

Random MSC of the week

This week's random MSC is MSC2785: Event notification attributes and actions! This is effectively a replacement for the push rules system we have today, and a super interesting one (how do you even design a notifications system?). Focus has shifted a little bit since this MSC was first opened, though its ideas still comes up frequently when aiming to make smaller changes to push rules today.

The Chart

The chart has been giving us a bit of grief when trying to be generated, but today it seems agreeable enough to include - enjoy :)

Continue reading…

Matrix Live

Dept of Spec 📜

Andrew Morgan (anoa) says

MSC Status

New MSCs:

• MSC3964: Notifications for room tags

MSCs in Final Comment Period:

• No MSCs are in FCP.

Accepted MSCs:

• MSC3862: event_match (almost) anything
• MSC1767: Extensible event types & fallback in Matrix (v2)

Merged MSCs:

• MSC3943: Partial joins to nameless rooms should include heroes' memberships
• MSC3783: Fixed base64 for SAS verification

Spec Updates

In keeping with our (roughly) quarterly release schedule of the Matrix Spec, v1.6 is due to be released on February 14th. That's only four days from now! The headline features are a new Jump-to-Date Client-Server API (MSC3030) and initial work on speeding up room joins (MSC3706), along with many other fixes and clarifications to the spec text itself.

If you haven't yet seen it, Matthew's Matrix 2.0 talk at FOSDEM walks through some of the upcoming features in the spec. Each will land in subsequent, future releases of the spec. Once all have landed, we'll call that Matrix 2.0 (in name and in actual version number).

Extensible events is one such upcoming feature. While the core proposal outlining the feature (MSC1767) will land in v1.6, the smattering of MSCs which describe how various event types will work under extensible events will span multiple upcoming spec versions. Watch this space!

Random MSC of the Week

The random MSC of the week is... MSC2974: Widgets: Capabilities re-exchange!

This MSC is relatively simple; proposing a method for widgets to ask the client for additional capabilities after it has already been initialised. Doing so allows for increased security and privacy workflows, as the widget need only ask for access to certain pieces of data at the point that it needs it (rather than all up front).

A similar transition of permission granting happened in mobile devices and apps. Initially mobile apps would ask for all permissions they would need up front - which users would blindly accept. These days, mobile OS's have shifted to a model where individual permissions are requested upon attempting to complete an action in an app. This way, users have better context on the reason for the permissions request. (Oddly, browsers have yet to reach this stage with extensions - those still ask for all permissions up front.)

Do check out the proposal and its technical details if widgets are your thing!

Continue reading…

Matrix Live

No Matrix Live today, but there will be a lot of Matrix content this weekend at FOSDEM in the Matrix devroom, and Matthew's main-track talk.

Continue reading…

Matrix Live

Dept of GSoC 🎓️

Thib reports

The Matrix Foundation is a candidate this year again to the GSoC programme. If you intend to mentor a student around your Matrix project, please ping me (@thib:ergaster.org) in the #gsoc:matrix.org room. Your project doesn't have to be set in stone yet: we need to have a good estimate of the number of mentors and projects applying before FOSDEM (by the end of next week).

Continue reading…

Matrix Live

Unfortunately no Matrix Live this week!

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://matrix.org/docs/spec/proposals.

MSC Status

New MSCs:

• There were no new MSCs this week.

MSCs in Final Comment Period:

• MSC3943: Partial joins to nameless rooms should include heroes' memberships (merge)

Merged MSCs:

• No MSCs were merged this week.

Spec Updates

This week and the week afterwards, the Spec Core Team are mostly focused on improvements to Matrix that we'd like to show off at FOSDEM 2023 this year! That consists of MSCs related to Faster Room Joins (MSC3943 among others) and Extensible Events (MSC1767).

Random MSC of the Week

The random MSC of the week is... MSC3230: Spaces top level order!

This defines an algorithm and a data structure that can be used to order one's top-level list of Spaces and have that order sync across all of their clients. Rooms and spaces within a Space continue to have their order defined by an order key (and failing that, the origin_server_ts field) in the corresponding m.space.child event of their parent's Space's state.

I won't get into the details of the algorithm here (or its criticisms), but feel free to jump into the MSC and take a look!

Continue reading…

Matrix Live

Dept of Status of Matrix 🌡️

Dandellion announces

Back in July I started a discussion on wikidata for adding a matrix space property, after much discussion in the wikidata community (lead mostly by tgr) we instead landed on a Matrix room property. This now enables slightly more accurate semantics when describing matrix rooms belonging to organizations, projects, and people on wikidata.

Wikidata is a knowledge base available under a free license and using standard machine-parsable data to add information to what is known as the "semantic web", this allows querying for information like for example: Organizations with matrix rooms

As the rest of wikimedia's projects it's open for contributions!

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://matrix.org/docs/spec/proposals.

MSC Status

New MSCs:

• [WIP] MSC3956: Extensible Events - Encrypted Events
• MSC3955: Extensible Events - Automated event mixin (notices)
• MSC3954: Extensible Events - Text Emotes
• MSC3953: Server capability DAG
• MSC3952: Intentional Mentions

MSCs in Final Comment Period:

• No MSCs are in FCP.

Merged MSCs:

• MSC3904: Room version 10 as the default room version
• MSC3783: Fixed base64 for SAS verification

Closed MSCs:

• MSC3852: Expose user agent information on Device
• MSC3517: "Mention" Pushrule
  • Deprecated in favour of MSC3952: Intentional Mentions.

Spec Updates

As you can tell from the above MSC list, Extensible Events continues to charge forwards, with Travis working busily away at replicating all of the existing event functionality (plus new functionality - image albums anyone?) in a world containing Extensible Events. As always, take a look at the core MSC (MSC1767) for a background on what Extensible Events is, and why it's so exciting.

This week has also seen room version 10 become the default recommended room version in the spec! As a reminder, v10 brings the ability to have a room that's both knockable and restricted at once, as well as more strictly enforces the types of power level values.

Otherwise we've seen lots of movement in other areas of the spec. Expect to see some work done around push rules (which have historically been rather complicated and fiddly...) and notifications in the days to come.

Random MSC of the Week

The random MSC of the week is... MSC3779: "Owned" State Events!

I remember this MSC fondly. It was originally born out of MSC3489's need to allow any user in the room to send m.beacon_info state events. This can easily be achieved today by lowering the required power level of m.beacon_info to the default user level. However, you then run into the issue of any user being able to edit any other user's m.beacon_info event!

Thus this MSC attempts to modify the state events permission model so that users can "own" certain state events that they send. We already somewhat have this functionality - if you put your Matrix ID as the state ID for any state event, only you or users with a power level higher than you can edit it.

Sadly this little trick (which we use for m.room.member events) doesn't work in the case of live location sharing, as the feature demands the ability to share location from multiple devices at once. Hence, trying to send two m.beacon_info events with the same state key would overwrite each other.

This MSC attempts to expand the functionality by modifying the definition so that a user "owns" a state event if the state key starts with their Matrix ID. Problem solved... for the most part!

Do check out the MSC if you have some use cases in mind that would benefit from something like this.

Continue reading…