The Matrix.org Foundation and community are very happy to announce that this year, they will be in full force at FOSDEM, with a community event right before the conference, a booth to welcome everyone during the conference, and a dev room to explore topics in depth!
Will L announces
Work on Sliding Sync – which provides a significantly faster and more scalable sync experience in Matrix clients – has moved to focus on native support, and away from the proxy.
The Sliding Sync Proxy on the Matrix.org homeserver will be decommissioned on November 21st, and client support in Element X will be removed on January 17th.
More details for users as well as server and client developers in Matrix.org's latest blog post
HarHarLinks says
It is
FridayTWIMday the 15th of November, and the Governing Board just came out of their first official meeting after the informal one at the Matrix Conference back in September. The focus of this meeting was to define the structure of the Governing Board, so we expect the results will not have an immediate tangible effect outside the Governing Board, but it gives the Governing Board the basic process to enable taking more perceptible decisions.This includes discussion about how we want to communicate with each other, but we also defined how we vote on actual decisions and some other basic rules for the Governing Board. As a part of that we elected a chair and vice chair for the Governing Board, who are going to help the Governing Board with facilitation tasks. Greg "Gwmngilfen" (chair) and Kim "HarHarLinks" (vice) were elected and are happy to share this post as one of our first actions in this role today. 😁 We also started some subcommittees of the Governing Board, to enable us to work efficiently in smaller groups focussed on specific topics. The rough topics for the initial four committees are Governance, Trust & Safety, Community, and Finances. What their exact scopes are going to be is left as a first task to the respective committees to define along with other bootstrapping, such as electing committee chairs and vice chairs. The set of initial committees is intentionally kept small to remain flexible and open the door for refining them later when we have more experience with how our day to day operations look like. We also discussed defining initial working groups, which would be structured as groups below the committees to fulfil more specific roles and would be the primary way for the Governing Board to include the community. However, we decided to defer that to the committees for now. We got through all the big parts on our agenda but ran out of time before having a formal vote on what communication tools we want to use. We have a great proposal which we are going to vote on asynchronously.
In general we had quite a productive meeting and reached agreements on many topics with clear next steps in other areas. The Governing Board might not have tackled yet the topics you would have prioritised, but it now has an asynchronous voting process and should be able to progress in other areas using the committees.
See you soon with more news from the Governing Board!
We will be decommissioning the sliding sync proxy next week (21/11/2024) and Element are removing client support in mid-January (17/01/2025).
Sliding Sync is designed to provide a significantly faster and more scalable sync experience in our clients. The initial implementation was first prototyped in Element Web backed by an entirely experimental server proxy. The implementation had half an eye on low bandwidth use cases, and the prototype led to MSC3575. We then realised that a simpler approach would be beneficial, and reused the same (experimental) proxy concept to facilitate beta testing with Element X, this time making it available on matrix.org. In doing so, we learned valuable lessons, leading to a refined and simplified API design in MSC4186. The proxy itself was only ever considered as a temporary arrangement to aid speed of development, rather than being a long term solution.
Simplified Sliding Sync MSC4186 (also known as native sliding sync), has since been implemented in Synapse, with encouraging results. Now that we don’t expect the API shape to change significantly, we recommend homeserver developers to implement MSC4186 natively.
The Matrix.org Foundation does not have the resources to keep up maintenance of the proxy service or its codebase, and plans to decommission the proxy from Mid-November and archive the sliding-sync repo.
Recognising that the community needs time to adopt sliding sync natively, Element will keep client support for the old API (MSC3575) until the 17th of January, 2025.
Thib (m.org) says
We're happy to announce that this year again we will have a DevRoom at FOSDEM!
We have half a day to talk about all the great projects we have been working on as a community. Our devroom should be on Sunday afternoon, even if it's not completely set in stone for now.
You can submit a talk following one of the two formats:
- 20 min talk + 10 min Q&A, for topics that can be covered briefly
- 50 min talk + 10 min Q&A, for more complex subjects which need more focus
Be quick, the Call for Proposals ends on December 1st and we can't extend it. FOSDEM organizers will close all DevRooms CfPs, and we can't bypass it!
Find all the dates & details on our Call for Proposals
Hello everyone,
The Matrix.org Foundation is excited to host a Matrix.org Foundation and Community devroom in person next year again at FOSDEM! Half a day of talks, demos and workshops around Matrix itself and projects built on top of Matrix.
We encourage people working on the Matrix protocol or building on it in an open source project to submit a proposal! Note that companies are welcome to talk about the Matrix details of their open source projects, but marketing talks are not welcome.
Matthew reports
We've also announced Matrix 2.0 as now being usable by mainstream users, to complement the keynote from The Matrix Conference - giving an update on all the APIs that will form Matrix 2.0! https://matrix.org/blog/2024/10/29/matrix-2.0-is-here/
Matthew reports
The Matrix Conference talk videos have been published - check them out at https://2024.matrix.org/watch/ and see Josh's round-up of the conference at https://matrix.org/blog/2024/10/29/matrixconf/
uhoreg 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:
- MSC4223: Error code for disallowing threepid unbinding
- MSC4222: Adding
state_afterto sync v2- MSC4221: Room Banners
MSCs in Final Comment Period:
Accepted MSCs:
Closed MSCs:
- No MSCs were closed/rejected this week.
PHEW! One month later and I’m still buzzing from the inaugural Matrix Conference in Berlin. This was the first time we’ve gathered such a broad cross-section of the ecosystem both upstream and downstream, bringing together contributors, vendors, and end-users in the same place at the same time.
The result was a fantastic demonstration of how much we can learn from each other, how much progress we’ve made, and how valuable it is to have The Matrix.org Foundation as an ecosystem steward that can bring us all together.
When we were planning the conference, we weren’t sure how big the demand would be. Having hit capacity and sold out of tickets weeks before the event, we know to aim higher next time! We’ll get a larger venue next year, but it was very gratifying to have sessions where the room was literally full!
You could really feel the energy: all told, we had 236 participants from 12 countries across 3 continents, representing 79 different organisations, join us across 4 days of events featuring 52 speakers.
You can find the slides and video recordings on the website, or see the photo albums.
Thumbnails of all the conference talks
And the world noticed, with press in The Guardian, Heise, and Fast Company.
Hi all,
Since the outset of Matrix, our aim has always been to provide a protocol that lets you build open, decentralised, secure communication apps which outperform the mainstream centralised alternatives. It’s been a twisty journey - first focusing on making Matrix work at all (back in 2014), and then getting it out of beta with Matrix 1.0 in 2019, and now focusing on making Matrix fast, usable and mainstream-ready with Matrix 2.0.
Meanwhile, the pendulum of decentralisation continues to accelerate in our direction. Our friends at Bluesky have shown that it’s possible to build decentralised social apps which are mainstream friendly enough for Presidents to recommend them; Elon continues to destroy Twitter and showcase the importance of decentralisation to everyone, and even Meta is dabbling in decentralised social media (and decentralised communication!)
So, where does Matrix sit in all this? Well, in order to make the transition to mainstream, we’ve been beavering away to implement four main pillars in Matrix 2.0:
Between these, we believe that Matrix can now be used to build apps which genuinely outperform the mainstream alternatives - and what’s more, these MSCs now all have implementations you can use today. The MSCs themselves are not all finalised and ready for merge (but are getting close), and when they pass FCP (Final Comment Period) to merge into the spec, we will formally bump the spec release to version 2.0.
We actually declared Matrix 2.0 as ready for action back at The Matrix Conference last month, and now that the videos have been published you can watch the launch right here:
Since the conference talk things have already moved on a bit, though, and we’ve landed a bunch of tweaks to address teething issues - and so here’s the current state of action:
Simplified Sliding Sync is the final version of Sliding Sync - the API which provides instant login, launch & sync in Matrix 2.0. To say that the API has been through a lot of iterations is an understatement, but we’re finally there with MSC4186, which simplifies the original Sliding Sync API (MSC3575) by removing the concept of a server-determined room list ordering entirely, and instead lets the client sort the roomlist as needed (while letting the client paginate in the roomlist incrementally, to ensure instant responsivity, no matter how large your room list is).
Simplified Sliding Sync is now implemented natively in Synapse as of 1.114, and so there is no longer any need to run a Sliding Sync Proxy in order to use the API. In fact, the Sliding Sync Proxy is being deprecated and the old Sliding Sync code will be removed from matrix-rust-sdk in the nearish future. Unfortunately we don’t have bandwidth to maintain both the native implementation Synapse as well as the proxy shim - and the proxy inevitably has suffered from a lot of limitations (e.g. having to do a full v2 initial sync for new logins, slowing them down to v2 performance - as well as duplicating storage between Synapse and the proxy). There’ll be a dedicated deprecation blog post for the proxy and pre-simplified Sliding Sync shortly. Meanwhile, work is well underway for native Sliding Sync support in conduit, conduwuit and grapevine - conduwuit guesses “next few weeks” for native Simplified Sync Support to land. Dendrite is unfortunately still not funded, so will happen on a best effort basis.
In terms of performance, native Simplified Sliding Sync in Synapse is spectacular - outperforming the proxy throughout, and making the old sync v2 API look positively prehistoric. Gone are the days of waiting for your app to sync, even if you’ve been offline for weeks/months; gone are the days of waiting minutes to login, and gone are the days of staring at a spinner as your app launches. It really is a new era - and having been hyping it since the first demo at FOSDEM 2023, I promise we won’t bang on about sliding sync any more after this; it’s finally here and landed and we can move on and enjoy it! For more details, see Ivan’s talk from The Matrix Conference:
Next Generation Auth is what we’re calling the migration to using industry standard OpenID Connect as the authentication API in Matrix 2.0, moving on from the custom auth API that Matrix has historically used. We’re calling this Next Gen Auth because we were seeing a lot of folks incorrectly assuming that adopting OpenID Connect for auth meant we would somehow be encouraging 3rd party social login or single-sign-on - which is not the case.
Next Gen Auth is simply swapping out Matrix’s old custom auth APIs with equivalents which are defined by the OpenID Foundation; after all, Matrix is a communication protocol, not an authentication protocol. In return, we get much more mature and secure authentication APIs - and access to the whole OpenID Identity Provider ecosystem, including support for Two Factor Auth and Multi-Factor Auth, hardware authentication tokens, passkeys, and device-based login flows (aka QR Login). We also stop both Matrix clients and servers having to implement the sprawling legacy Matrix authentication API surface - ensuring that users only ever hand their account password to their auth server, rather than having to trust their clients to handle it securely, which in turn plays much nicer with password managers (who only have to remember how to auth with your auth server, rather than a myriad different clients). It also lets you share authentication between apps if you want; gives us access_token refresh (at last!) to avoid long-lived access_tokens hanging around; and in future will also support OIDC scopes so you can limit the access particular clients get to your account.
In short, Next Gen Auth is transformative, and the initial implementation at matrix-authentication-service (MAS) is ready for admins to deploy and use (and in future will be available embedded in Synapse too). Unfortunately it is not yet live on matrix.org (given we have to migrate tens of millions of accounts, complete with all the social login complexities) but we’re hoping to get it there in the coming months.
Probably one of the clearest immediate benefits of Next Gen Auth is the ability to do a full login including setting up all your end-to-end-encryption simply by scanning a QR code on an existing client, courtesy of MSC4108 and OAuth 2.0 Device Authorization Grants. In other words, you don’t have to specify a server, or your username, or account password, or your recovery key - you just scan a QR code and you’re in. The very latest Element X releases on iOS & Android have this implemented and enabled by default, and so if you’re on a server which has deployed MAS, you can go to “link new device” in Element Web/Desktop to show a QR code to instantly log in.
For more info on all things Next Gen Auth, see Quentin’s talk from The Matrix Conference:
Next we have MatrixRTC: end-to-end-encrypted group voice and video conferencing over Matrix. Historically, group VoIP in Matrix has relied on third party conferencing systems (Jitsi, and before that FreeSWITCH) - providing no support for Matrix’s end-to-end encryption, or indeed Matrix’s user identities, decentralisation or decentralised access control.
With MatrixRTC this changes: we now have a standard way to establish large-scale end-to-end-encrypted group video calls via Matrix, leveraging all the benefits of Matrix’s end-to-end-encryption infrastructure, user identity, room permissions, etc. It also supports different media stacks to actually handle the media conferencing - today, the main implementation uses the LiveKit SFU, but there’s also an experimental full-mesh WebRTC implementation.
Element Call has been the driving app behind MatrixRTC, and as of today is now enabled in the release versions of both Element Web/Desktop and Element X to provide native MatrixRTC calling embedded in the apps: if you hit the video call button you will now have the option to spin up a MatrixRTC call via Element Call rather than via Jitsi or Legacy 1:1 calling, and if the room is end-to-end-encrypted, all the conference will be too.
Meanwhile - MatrixRTC isn’t just Element Call: Famedly showed off experimental interop with FluffyChat at FOSDEM back in Feb, and Element showed off experimental interop with BigBlueButton in August. Given more and more conferencing tools are converging on LiveKit as a best-in-class SFU, it’s an amazing opportunity to use Matrix and MatrixRTC to power the end-to-end-encryption and decentralisation and get standardised voip/video interop from the outset.
For more info, see Timo’s talk from The Matrix Conference:
That said, there are a few caveats right now:
The final pillar of Matrix 2.0 is Invisible Encryption - making Matrix’s end-to-end encryption as seamless and invisible as the centralised alternatives (Signal, WhatsApp, iMessage and friends). This does not mean reducing security in any way - just the opposite, in fact. It means:
We are excluding non-cross-signed devices from Matrix (MSC4153). The fact that Matrix ever supported the idea of users enabling encryption on a device without proving that they are the valid owner by signing it (by verifying it with another device, or providing their recovery key/passphrase) is a nasty hangover from back before we introduced cross-signing. Nowadays, the fact that non-cross-signed devices exist acts to reduce security and complicate UX and implementations with big scary red warnings whenever an unverified device joins a conversation. Instead, once MSC4153 lands, we’re going to simply exclude unverified devices entirely - not encrypt to them, and not decrypt from them. We can then get rid of all the confusing warnings associated with them.
We’re also solving the confusing “grey shield” warnings: “the authenticity of this message cannot be confirmed on this device” and similar. These are avoidable warnings caused by message keys which can no longer be tracked back to the original sender - e.g. if they’re restored from backup, or if the original sending device has been deleted. We’re fixing these with authenticated backup (MSC4048) and including device keys on Olm events (MSC4147) respectively.
Finally, we’re moving to Trust On First Use (TOFU). This means that even if you didn’t explicitly verify another user, you still get warned if their identity changes (unlike previously, when it was ignored). An initial implementation just landed in matrix-rust-sdk a few weeks ago, and so appropriate warnings at the application level should arrive shortly - matching the equivalent Signal or WhatsApp “this user’s identity has changed” warnings, albeit not yet synced between devices.
As you can probably tell, Invisible Encryption is something of a moving target; for instance, the scope could extend to cover all scenarios where users might expect messages to be decryptable (e.g. Dehydrated Devices: the ability to decrypt messages sent to you when you are not logged in anywhere - or Sharing Keys when new users join a room/space). However, the 4 points above are the main ones, and they are in the process of landing right now.
The end result is already an immeasurable improvement in the reliability and robustness of Matrix’s encryption - and once the remaining pieces land, the user experience of a Matrix client should be that the encryption is almost entirely invisible to the user - unless something bad is happening; much like TLS.
Valere & Patrick’s talk on Invisible Crypto from The Matrix Conference would get embedded here, but unfortunately the audio was mangled - we’ll rerecord it and publish it shortly. In the meantime, you can find their slides here.
Well, first of all we’re going to stop announcing Matrix 2.0 - it’s finally here (modulo the spec release)!
There’s obviously a bit of follow-up still to be done though:
Beyond Matrix 2.0, though, there’s a large pile of other areas which need attention:
And then, in the longer term - what might Matrix 3.0 bring? Honestly, at this point, it’s an open question. Could it be landing major Trust & Safety changes in order to radically empower users to avoid and mitigate abuse? Could it be switching to MLS (or Decentralised MLS) for encryption? Could it be the glorious return of P2P Matrix (if it was funded)? Could it even be figuring out if/how to converge with (or layer on top of) MIMI or other federation protocols? Answers on a postcard to #sct-office:matrix.org please!
If ever there was a time to exhort your friends to give Matrix another go - this is it.
Matrix 2.0 has been a long time coming, and we need to get the word out that the step change forwards has finally arrived, and that apps built on Matrix 2.0 can seriously outperform the mainstream alternatives. Ideally, this could be Matrix’s “Firefox moment” - when from the ashes of old open source code, a new generation appears which can punch its weight against the proprietary incumbents.
Right now the only Matrix 2.0 client is Element X (and Element Web/Desktop if you enable the experimental Simplified Sliding Sync implementation in labs on develop/nightly builds) - see element.io/blog for full details - but we expect to see at least matrix-rust-sdk and matrix-js-sdk based clients using the new APIs as a matter of course in the coming months, and then hopefully everyone else too.
So: if you run a Matrix server, please consider deploying MAS to enable next-gen auth (Sebastien Spaeth’s blog also has a good indie tutorial) - and add Element Call to give MatrixRTC a try. Over the coming months we should see more support in more Matrix distributions, until hopefully we will all be living in a Matrix 2.0 world!
Huge thanks are due to everyone who has helped design, build, and iterate on Matrix 2.0, and to everyone who has kept the faith as we’ve put it all together. A special thanks also to BWI who helped fund much of Element’s work on this for the benefit of Matrix as a whole.
Finally, if you want Matrix to prevail - please join the Foundation and support the project financially. We urgently need organisational members, especially after the costs of running The Matrix Conference, and particularly if your organisation is commercially dependent on Matrix, you simply must become a member. While it’s very flattering that Matrix gets treated as a commons these days, without financial support the underlying Matrix project will die and your project will fail. Whereas if everyone building on Matrix supported us, we would be moving way faster and with fewer constraints - so please get involved at matrix.org/support and help.
Thanks for flying Matrix!
Matthew
Andrew Morgan (anoa) {he/him} 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:
- MSC4220: Local call rejection (m.call.reject_locally)
- MSC4218: Improving performance of profile changes
MSCs in Final Comment Period:
Accepted MSCs:
- No MSCs were accepted this week.
Closed MSCs:
- No MSCs were closed/rejected this week.
Spec Updates
Steady progress across a range of MSCs this week. I'm particularly excited to see MSC2409 to reach FCP given its widespread use. Perhaps MSC4203: Sending to-device events to appservices is next?
spaetz says
The German Data Protection Officer is creating a catalogue of criteria to assess messengers. They still take feedback till Nov 15. List of criteria is available in German and English.
Toot: https://social.bund.de/@bfdi/113306169664247379
English criterion pdf link is: https://www.bfdi.bund.de/SharedDocs/Downloads/EN/Konsultationsverfahren/3_Messengerdienste/Katalog-SMA-Front-End.pdf?__blob=publicationFile&v=2
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:
MSCs in Final Comment Period:
- No MSCs are in FCP.
Accepted MSCs:
Closed MSCs:
Spec Updates
Matrix 1.12 went out last week! This release contains a few Trust & Safety improvements, bug fixes for authenticated media, an ability to mark rooms as unread, and several other quality of life features. Check it out, and get an early preview for what the next release might look like 👀
If there's something you'd like the Spec Core Team to take a look at, let us know in our office room: #sct-office:matrix.org