Thib

We were already proud to announce that the national agency for the digitalisation of the healthcare system in Germany (gematik) had selected Matrix as the open standard on which to base all its interoperable instant messaging standard, back in 2021.

We are now delighted to let the world know that they are doubling down on sovereignty and sustainability: gematik is the first organisation of the public sector to join the Matrix.org Foundation as a Silver member.

Collaboration in the public sector

Our friends at the FSFE have been calling for software used in public services to be free software in their Public Money Public Code campaign. As advocates of open standards and an open source project ourselves, this is something we can get behind.

Software development can be an impenetrable world for people who don’t work in the field. It can sometimes be difficult for people outside of our industry to understand the importance of bitrotting and refactoring. One very unfortunate effect of this is that new features are easy to fund because they feel very tangible, but the most critical housekeeping work is not as appealing.

Yet, without regular refactoring to clean things up, it gets increasingly costly and difficult to add new features. Counterintuitively, spending money on “the boring tasks” is the most efficient use of money: without it the technical stack would become either obsolete, bloated, or both, and it would be much more costly to move to something else or maintain an in-house fork.

We’re very happy gematik is doing the right thing by supporting the technical stack it builds TI-Messenger on. By supporting the Matrix.org Foundation, gematik contributes to the sustainability of the protocol powering the communications of the German healthcare system… but not exclusively.

Sharing costs across public services, and with the private sector

Matrix is an open standard, which means not only everyone can use it: when someone contributes to Matrix, everyone benefits from it. This makes Matrix particularly interesting for the public sector: if the German healthcare contributes to Matrix, the German Armed Forces benefit from it, and the other way around. It allows both to contribute less of their budget, instead of contributing each to an entirely different product. The German Federal Ministry of Defence already actively contributes to Matrix development and funding via its public IT services provider BWI GmbH, who relies on Element’s consulting services to develop their own Matrix-based messenger.

But Matrix being open source, it also allows the public and private sector to share the costs of maintenance by design. The public sector benefits from the contributions of the private sector to Matrix, and the opposite is true as well.

The Foundation plays a critical technical and social role in this system: it centralises and curates contributions to the protocol so it remains unbiased, coherent, and efficient.

This is just a beginning

We’re extremely happy to welcome the first public sector organisation in the Matrix.org Foundation! Given how popular Matrix is among governments and the public sector in general, we know this is just a beginning: it would be illogical to deploy any solution at a large scale without contributing to its sustainability.

Whether you’re an organisation from the public or the private sector, looking to cut costs down by building on a common, standard and reliable foundation, you can support Matrix and join the Foundation today.

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…

We're proud to announce Beeper is the first member to join the Foundation! Beeper is a universal chat app, built on top of Matrix. Beeper is strongly committing to support Matrix by becoming the first member in the Gold tier as well.

Matrix is a strategic choice

Beeper allows you to connect accounts from up to 15 different chat platforms to get a unified inbox in a single app. The core business of Beeper is to provide a polished app and service to their users. Beeper is built upon Matrix: behind the scenes, a Beeper account is a Matrix account on the Beeper homeserver, and the company hosts bridges for its users. The experience is completely transparent for them.

Matrix was an obvious choice in Beeper's stack because of its interoperable nature. Bridges are the core of Beeper's business: they are the most active bridges maintainer of the Matrix ecosystem, and most of them are open source too. It makes a lot of sense for Beeper to build on top of Matrix so they don't have to reinvent the wheel: homeservers exist, the AppService API that allows them to create bridges exists, and maintaining an in-house solution for this all would cost more than their contribution to Matrix.

Matrix also solves the difficult problem of End-to-Bridge Encryption: it allows bridges to decrypt messages from a third party platform like WhatsApp and re-encrypt it for Matrix users. This makes the homeserver completely oblivious to the content of the messages. It protects customers against passive leaks, and the most privacy conscious ones can even self-host their bridges to get total control of the messages making it through.

Mission aligned

Beyond the obvious business choice of relying on Matrix, Beeper and the Foundation have a lot of values in common. The Foundation is fighting for interoperability possible at a technical level… but it's also fighting to make it possible at a legal and systemic level. We've been very vocal in the Digital Markets Act discussions In Europe. Beeper's CEO Eric Migicovsky also took part in the consultation launched by the EU in the hopes of opening up the walled gardens of Gatekeepers. The regulation change brought by the DMA will accelerate the adoption of interoperability across the board, bringing the tools to make it sustainable and reliable, which is a direct business enabler for Beeper.

Join us

We once again welcome Beeper and congratulate them for being the first member to support the stack they rely on! As for organisations who depend on Matrix: we still need your support to make Matrix sustainable.

Join us in our mission to make Matrix the ubiquitous foundation for respectful products and services, become a member today!

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…

Hello federation,

TLDR: New website is coming tomorrow, your RSS reader might be disoriented during the switch.

That's right, after several months of studying, designing and implementing: we're finally going to deploy the new matrix.org website on June 16! Let's have a look back at the why and how.

I also need to thank Jonas Platte not only for his technical expertise but also for his kind support and patience. Thanks to MTRNord as well for kickstarting the project, and to the various designers involved.

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…

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:

• [WIP] MSC4014: Pseudonymous Identities
• MSC4013: Poll history cache

MSCs in Final Comment Period:

• No MSCs are in FCP.

Accepted MSCs:

• MSC3882: Allow an existing session to sign in a new session
• MSC3860: Media Download Redirects
• MSC2659: Application service ping endpoint
• MSC2249: Require users to have visibility on an event when submitting reports
• Mechanism to communicate 3PID binding updates or deletions to homeservers

Closed MSCs:

• MSC2463: Exclusion of MXIDs in push rules content matching

Spec Updates

A regular reminder that every Tuesday, the Spec Core Team (SCT) publishes their approximate priorities in the public Office of the Spec Core Team room - check it out to see what the SCT is working on. Similarly, if you’d like the SCT to engage with your MSC, mention so in that room.

The release of Matrix 1.7 is expected in the next 1-2 weeks! Keep an eye out for announcement blog post specifically for it. We'll call it out in the following TWIM as well of course :)

Matrix 1.8 is currently scheduled for around August 2023.

Random MSC of the Week

The random MSC of the week is... MSC3914: Matrix native group call push rule!

This MSC adds a new push rule that causes your Matrix client to emit a notification if a group call (as defined by MSC3401 is started in a Matrix room. This MSC (obviously) depends on MSC3041, so that MSC will need to be accepted before this one can be.

There is currently a client-side implementation for this MSC, but it is missing a homeserver side one (for adding the push rule).

Check out the MSC if you're interested, or perhaps take a look at adding that server-side implementation?

Continue reading…

Matrix Live

Dept of Social Good 🙆

Denise announces

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.

MSC Status

New MSCs:

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

Accepted MSCs:

• No MSCs were accepted this week.

Closed MSCs:

• No MSCs were closed/rejected this week.

Spec Updates

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/login endpoint 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 /login is 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 Authorization request 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.

Continue reading…

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…