🔗Matrix Live

🔗Dept of Status of Matrix 🌡️

🔗Matrix.org Foundation

Michael Downey announces

Don't miss this week's Matrix Live, where Amandine & Matthew talk about the growth of the Foundation and how it will help all of us working in the Matrix ecosystem be more successful. And in case you missed it, a job description for the Foundation's first Managing Director has now been posted. If you think you have what it takes, or if you want to share it with others who might, don't delay!

🔗Matrix.org Website Bug Hunt

Thib says

Some of you might have heard of it, but we're about to launch a (long overdue) update of the matrix.org website! The current one has served us well, but it grew organically as exciting projects and features were added to it. It became a little impractical to navigate and sometimes confusing.

The new matrix.org website, nicknamed "Zola" after the static site generator it uses, is not just a fresh coat of paint on the website: it's a complete rewrite to address three kind of people who would browse the website. Sorted by time they're willing to spend on a web page:

• The general public, who is not tech savvy and doesn't want to understand how things work, but who wants to get an easy onboarding
• Community managers, who are not too tech savvy but are willing to spend a bit of time to understand more advanced use cases
• Developers who want to understand how matrix works, and who want to build & break things!

We're in the final stages of developing the website, and we need you to help us making it ready! Head to the preview of the website, use the website, and give is feedback by opening an issue on the website tracker. Please make sure the issue doesn't already exist before opening it.

Reporting the following is particularly helpful:

• Something looks off, misplaced, is not aligned well or behaves oddly
• Something is missing (the doc is incomplete? Some informationg is missing somewhere?)
• There's an accessibility issue
• Something doesn't work on your browser
• It's not clear how to get to a particular information (you're looking for a client or a SDK, and after visiting the website you still don't know which one to use or how to get it?)

We still need to:

• Finish up the Bots page (which will likely be replaced by an Integrations page)
• Flesh out the support page to highlight more of the work of the Matrix.org Foundation
• Import the historical projects that are no longer maintained (clients, servers, bots, bridges, sdks)

If you want to follow along, you can join the #matrix.org-website:matrix.org room.

Help us make the website look as neat as possible for launch!

Matthew reports

The UK's online safety bill is a catastrophe in the making, and as currently written empowers the UK telecoms industry regulator (OFCOM) to obligate end-to-end encrypted messaging apps to embed proprietary 3rd party scanning software which attempts to identify and flag abusive content and report it to the authorities. If you are in the UK, please sign this petition https://petition.parliament.uk/petitions/634725 to try to force the government to reconsider. Element, for instance, would rather be blocked by the UK govt from the app stores than embed third party scanning technology. For more info: https://element.io/blog/the-uks-online-safety-bill-undermines-everyones-safety/ and https://element.io/blog/the-online-safety-bill-an-attack-on-encryption/

Continue reading…

🔗Matrix Live

Continue reading…

🔗Matrix Live

An unfortunate series of events prevented us from recording this week! Stay tuned for great bridge news next week.

🔗Dept of Spec 📜

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

• MSC3999: Add causal parameter to /timestamp_to_event
• MSC3998: Add timestamp massaging to /join and /knock
• MSC3997: Add timestamp massaging to /createRoom
• MSC3996: Encrypted mentions-only rooms.
• MSC3995: [WIP] Linearized Matrix

MSCs in Final Comment Period:

• MSC3970: Scope transaction IDs to devices (merge)

Accepted MSCs:

• No MSCs were accepted this week.

Closed MSCs:

• No MSCs were closed/rejected this week.

🔗Spec Updates

The concept of Linearized Matrix (MSC3995) is moving forwards as a potential answer to the European Union's, Digital Markets Act. The fully-decentralised Direct Acyclic Graph (DAG) model of Matrix is well-known, yet complex to implement and thus a potential blocker to gatekeepers who are looking for an interoperable messaging protocol to link their chat service to. Enter Linearized Matrix, a concept of a Matrix room that uses a linked-list to store events in a room, rather than a DAG. Crucially, while being simpler to implement, our aim is to be forward-compatible with the DAG version of Matrix, such that gatekeepers may switch over to DAG-style Matrix in the future if they so chose.

See MSC3995 for more information, and a reminder that this is all still very much in flux!

🔗Random MSC of the Week

The random MSC of the week is... MSC2943: Return an event ID for membership endpoints!

Currently, when you send a (state) event manually via PUT /_matrix/client/v3/rooms/{roomId}/send/{eventType}/{txnId}, you'll receive an event ID in the response. While you can send membership events this way, it's often a bit nicer to use the various POST /_matrix/client/v3/rooms/{roomId}/join,leave,kick endpoints instead. However, these do not return an event ID in their response. For clients that don't use /sync, this would force them to use the former, generic endpoint in order to retrieve the event ID of the membership event.

MSC2943 attempts to rectify that by specifying that membership-related endpoints should return an event ID, similar to the generic event send endpoint. Currently this MSC is just waiting on an implementation in a homeserver (and possible a client) in order to move forward. If you feel strongly about this change being included in the Matrix spec, why not get your hands dirty with some homeserver dev?

Continue reading…

🔗Matrix Live

🔗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:

• MSC3994: Display why an event caused a notification
• MSC3993: Room takeover
• MSC3991: Power level up! Taking the room to new heights
• MSC3989: Redact origin field on events
• MSC3995: [WIP] Linearized Matrix

MSCs in Final Comment Period:

• No MSCs are in FCP.

Merged MSCs:

• MSC3980: Dotted Field Consistency

🔗Spec Updates

This last week the core team has been working on Linearized Matrix, which now exists in MSC form. The idea is still very much in flux, but the MSC covers a large part of the backing context for the overall approach. More detail about IETF116, Linearized Matrix, and the overall mission can be found in last week's TWIM, and we're happy to answer any questions in #matrix-spec:matrix.org on Matrix.

Meanwhile, the Spec Core Team (SCT) has been focusing on Matrix 2.0 MSCs for OIDC, VoIP, etc alongside quite a few other smaller MSCs. You can follow along with the SCT's weekly priorities in the #sct-office:matrix.org room on Matrix.

🔗Random MSC of the week

Today's random proposal is MSC3860: Media Download Redirects! Quite a few medium-large servers use a CDN of some kind to host media shared in rooms, and currently the usefulness of that CDN is diminished by servers not necessarily being able to tell clients that the media is actually found on another URL. This proposal formalizes HTTP 307 redirects, and the SCT is interested to hear if this will break any clients - check it out, leave some comments, and let us know :)

Continue reading…

🔗Matrix Live

🔗Dept of Status of Matrix 🌡️

uhoreg announces

🔗Messaging Layer Security approved by the IETF

The IETF has approved Messaging Layer Security (MLS) for publication. MLS is an end-to-end encryption method designed for group messaging. We have been working on integrating a variant of MLS into Matrix. Keep an eye out for demos in the near future.

🔗Dept of Spec 📜

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

• MSC3987: Push actions clean-up
• MSC3985: Break-out rooms
• MSC3984: Sending key queries to appservices

MSCs in Final Comment Period:

• MSC3980: Dotted Field Consistency (merge)

Accepted MSCs:

• MSC3923: Bringing Matrix into the IETF process
• MSC2677: Annotations and reactions

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!

Continue reading…

Today we are issuing security releases of matrix-js-sdk and matrix-react-sdk to patch a pair of High severity vulnerabilities (CVE-2023-28427 / GHSA-mwq8-fjpf-c2gr for matrix-js-sdk and CVE-2023-28103 / GHSA-6g43-88cp-w5gv for matrix-react-sdk).

Affected clients include those which depend on the affected libraries, such as Element Web/Desktop and Cinny. Releases of the affected clients should follow shortly. We advise users of those clients to upgrade at their earliest convenience.

The issues involve prototype pollution via events containing special strings in key locations, which can temporarily disrupt normal functioning of matrix-js-sdk and matrix-react-sdk, potentially impacting the consumer's ability to process data safely.

Although we have only demonstrated a denial-of-service-style impact, we cannot completely rule out the possibility of a more severe impact due to the relatively extensive attack surface. We have therefore classified this as High severity and strongly recommend upgrading as a precautionary measure.

We found these issues during a codebase audit that we had previously announced in an earlier security release of matrix-js-sdk and matrix-react-sdk. The earlier release had already addressed a set of similar vulnerabilities that were assigned CVE-2022-36059 / GHSA-rfv9-x7hh-xc32 and CVE-2022-36060 / GHSA-2x9c-qwgf-94xr, which we had initially decided not to disclose until the completion of the audit. Now that the audit is finished, we are disclosing those previous advisories as well.

🔗Matrix Live

🔗Dept of Spec 📜

Andrew Morgan (anoa) says

🔗MSC Status

New MSCs:

• MSC3984: Sending key queries to appservices
• MSC3983: Sending One-Time Key (OTK) claims to appservices
• MSC3982: Limit maximum number of events sent to an AS
• MSC3981: /relations recursion

MSCs in Final Comment Period:

• MSC3923: Bringing Matrix into the IETF process (merge)
• MSC2677: Annotations and reactions (merge)

Accepted MSCs:

• No MSCs were accepted this week.

Closed MSCs:

• MSC1796: improved e2e notifications

🔗Spec Updates

The Matrix.org Foundation (mostly Travis) are beavering away preparing for the MIMI meeting at IETF 116 this weekend! This is part of our continual work to contribute to a IETF standard that can be used for interoperable messaging between gatekeepers (large companies in the chat world) under the EU's Digital Markets Act. See our earlier blogpost for more context on this topic.

In terms of our previous proposals on this subject; it turns out that implementing full-scale DAGs is a bit difficult, particularly when aiming to achieve interoperability on a short timeline. So we've been working on building an API surface for Matrix which makes rooms easier to access/implement in chat settings. We unfortunately don't have much to share today, but keep an eye on next week's TWIM for details 👀

🔗Random MSC of the Week

The random MSC of the week is... MSC3480: Make device names private!

This MSC proposes hiding device names from any other user, while still allowing your own devices to see the names of the others.

You may question why device names being shown to other users was considered a good idea at all in Matrix. Initially these being public was really useful for verifying the devices of other users! Back in the days before cross-signing (where you only need to verify another user once), you had to verify every one of your friend's devices from every one of your own devices. It was an n * m problem, whereas if you had 4 devices, and your friend had 5, you'd need to do 20 verifications! And 4 more if your friend got a new phone!

So having device names back then were handy, but today any justification is moot and they're just a metadata leak. So we should get rid of them!

This MSC is blocked on a proven implementation. I actually wrote one up for Synapse a little while ago, and I plan to polish and merge it soon. Anyone else is free to do so in the meantime as well (just let me know first if you plan to do so in Synapse :).

Here's to improved privacy by default in Matrix!

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:

• 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…

A few weeks ago we found ourselves in Brussels to participate in the second stakeholder workshop for the Digital Markets Act (DMA).

The DMA is new antitrust/competition regulation from Europe which came into force in November, whose objective is to make digital markets more competitive by forcing gatekeepers (i.e. large tech companies) to reconsider some of their anti-competitive or self-preferencing practices. Gatekeepers are defined as companies which have a clear position of influence in a given market (based on revenue / market cap / number of users thresholds), and “an entrenched and durable position”. The process for designating which companies count as gatekeepers will start in May 2023.

The DMA touches upon different key topics, from self-preferencing behaviour to app store management practices - but most importantly includes interoperability for “number-independent interpersonal communication services” (NIICS), otherwise known as chat and voice/video calling and conferencing services (social media was left out for now).

This particular workshop was focused on the latter: interoperability between messaging services, with the aim of getting the different stakeholders of the industry in the same place to discuss how the legislation could be implemented. The whole idea is to figure out a practical way in which WhatsApp could interoperate with iMessage, Google Messages and others, creating an interoperable communication network where users are no longer locked into communication silos and pick their preferred service provider without compromising on who they can talk to.

About 900 people participated online, and around 80 people were present in person: the maximum the room could hold. It was particularly fun to see representatives from the whole industry turning up in person, including folks from XMPP, MIMI (the new IETF working group on messaging interoperability), MLS, us from Matrix obviously (alongside Matrix ecosystem representatives from Beeper and NeoChat!) - all together with the Body of European Regulators for Electronic Communications (BEREC), civil society representatives (like the Federation of German Consumer Organisations (VZBV) and European Digital Rights (EDRi)), mobile network operators, local network agencies, and obviously some of those who are likely to be designated as gatekeepers, such as Meta, Apple and Google.

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…