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.

Continue reading…

🔗Matrix Live

🔗Dept of Status of Matrix 🌡️

🔗Matrix at FOSDEM 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

Continue reading…

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.

Continue reading…

🔗Dept of Status of Matrix 🌡️

🔗Matrix 2.0

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/

🔗The wait is over, videos from The Matrix Conference 2024 are 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/

🔗Dept of Spec 📜

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_after to sync v2
• MSC4221: Room Banners

MSCs in Final Comment Period:

• MSC2781: Remove the reply fallbacks from the specification (merge)

Accepted MSCs:

• MSC2409: Proposal to send EDUs to appservices

Closed MSCs:

• No MSCs were closed/rejected this week.

Continue reading…

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.

And the world noticed, with press in The Guardian, Heise, and Fast Company.

Continue reading…

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:

1. Instant login, instant launch, and instant sync (aka Simplified Sliding Sync, MSC4186)
2. Next Generation Auth (aka Native OIDC, MSC3861)
3. Native Matrix Encrypted Multiparty VoIP/Video (aka MatrixRTC, MSC4143)
4. Invisible Encryption (MSC4153 & friends).

Continue reading…

🔗Matrix Live

🔗Dept of Spec 📜

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:

• MSC2409: Proposal to send EDUs to appservices (merge)

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?

Continue reading…

🔗Dept of Social Good 🙆

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

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

• MSC4213: Remove server_name parameter
• MSC4211: WebXDC on Matrix

MSCs in Final Comment Period:

• No MSCs are in FCP.

Accepted MSCs:

• MSC4170: 403 error responses for profile APIs

Closed MSCs:

• MSC3060: Room labels
• MSC4214: Embedding Widgets in Messages

🔗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

Continue reading…

Hi all,

We are disclosing two high-severity vulnerabilities in matrix-js-sdk and matrix-react-sdk related to MSC3061, which specifies sharing room keys with newly invited users for message history access.

🔗Affected versions

• matrix-js-sdk ≥ 9.11.0, < 34.8.0 (CVE-2024-47080 / GHSA-4jf8-g8wp-cx7c). Fixed in 34.8.0.
• matrix-react-sdk ≥ 3.18.0, < 3.102.0 (CVE-2024-47824 / GHSA-qcvh-p9jq-wp8v). Fixed in 3.102.0.

🔗Vulnerability details

When inviting a user to an encrypted room, in the legacy (pre-Rust) encryption implementation, matrix-react-sdk forwarded existing message keys to the newly invited user so they could decrypt shared message history as per MSC3061. The implementation is provided by matrix-js-sdk, which incorrectly applied the same rules for sending existing keys to the invited user as for sending new keys, which allows them to be sent to unverified devices and unverified users. While there's always some risk of key exposure to a server-side attacker when you're interacting with unverified users, the risk is higher for historical keys.

🔗Root cause and remediation

The root cause of the matrix-react-sdk vulnerability is a function call into vulnerable functionality implemented in the matrix-js-sdk. The matrix-react-sdk vulnerability was addressed earlier, in matrix-react-sdk version 3.102.0, by removing the call. The matrix-js-sdk vulnerability will be addressed in version 34.8.0 to remove the vulnerable functionality completely. Because of these differences, two separate advisories were warranted.

Note that the vulnerability is only present in the matrix-js-sdk when running the old, non-Rust encryption stack. The vulnerable functionality was never implemented in the Rust-based stack. As a result, clients using the matrix-js-sdk in Rust crypto mode (i.e. calling initRustCrypto rather than initCrypto) are not vulnerable, even if on a nominally vulnerable version.

Furthermore, matrix-android-sdk2 and matrix-ios-sdk have similar functionality that is gated behind an experimental setting—we recommend avoiding use of this setting, though there are no specific advisories since the feature has only been available in an experimental state.

🔗Proposed specification changes

To fix this functionality in terms of the specification process, we will open an MSC to explicitly clarify that MSC3061 key forwarding should only forward keys to verified devices owned by verified users, ensuring that historical keys are never shared with untrusted devices. This also encourages users to verify each other to enable reading message history, thereby improving Matrix security against interception.

🔗Note on project ownership

The matrix-react-sdk is no longer a Foundation project but that of Element and has been moved to https://github.com/element-hq/matrix-react-sdk. However, the vulnerability in question was introduced, found and patched while it was still under Foundation ownership. For this reason, the Matrix.org Security team decided to treat this as a Foundation advisory. Future advisories for matrix-react-sdk (if any) will come from Element.

🔗Matrix Live

Continue reading…