This Week in Matrix 2023-09-29

29.09.2023 00:00 — This Week in Matrix Thib

Matrix Live

Dept of Servers 🏢

Dendrite (website)

Second generation Matrix homeserver

Devon Dmytro reports

This week we released v0.13.3. Here are a few of the highlights:

  • Room version 11 is now supported
  • Sliding Sync proxy can be configured in the /.well-known/matrix/client response
  • Invitations are now correctly pushed to devices
  • A bug which could result in the corruption of account data has been fixed
  • Clients can request the federation event_format when creating filters
  • Many under the hood improvements for MSC4014: Pseudonymous Identities

...and a whole lot more. Check out the release notes for the full set of changes! As always, feel free to stop by to join in on the discussion and if you encounter a bug make sure to report it here.

Dept of Bridges 🌉

Postmoogle (website)

An Email to Matrix bridge. 1 room = 1 mailbox.

Aine says

Introducing Postmoogle v0.9.16: Bridging Email and Matrix Like Never Before!

We at are delighted to announce the release of Postmoogle v0.9.16, your trusted bridge for seamlessly connecting the worlds of email and Matrix. In this update, we've introduced a host of new features and enhancements to elevate your Matrix email experience.

Here's what's new in this release:

  1. Emoji Support: Express yourself with emojis! You can now react to emails with the ⛔️,🛑, or 🚫 emojis to add the sender to your spam list. Embrace a better quality of life change within your Matrix rooms.
  2. Subaddressing Support: Postmoogle now offers support for subaddressing. Receive emails sent to addresses like [email protected], giving you more control over your email routing.
  3. Enhanced Banlist Modes: We've added two new server ban modes: banlist:auth and banlist:auto. The banlist:auth mode automatically bans users for attempting to authenticate into Postmoogle over SMTP with invalid credentials, while banlist:auto automatically bans for invalid emails, such as those failing MX, SPF, or DKIM checks. You can configure each mode separately, enhancing the security of your Matrix environment.
  4. Improved Banlist Output: The !pm banlist command output has been improved to display bans per day in weekly chunks. This streamlined presentation makes it easier for you to monitor and manage banned IPs effectively.
  5. Enhanced Reply Handling: Postmoogle now ensures that it always replies to your messages, either within the threads or using the reply-tos, depending on your mailbox configuration. This guarantees a more organized and threaded conversation experience within your Matrix rooms.
  6. Custom Mailbox Signatures: The new !pm signature command enables you to set a personalized signature for your mailbox, adding a unique touch to your email messages.
  7. Automatic Replies: With the introduction of the !pm autoreply command, you can configure automatic responses for all incoming emails without existing threads. This feature simplifies communication when receiving new email threads.

Postmoogle v0.9.16 brings you an enhanced email-to-Matrix bridge, bolstered security measures, and an improved quality of life. Whether you're managing email discussions within your Matrix rooms or responding to emails from your Matrix client, Postmoogle ensures a seamless integration.

Upgrade to Postmoogle v0.9.16 today and discover the future of email communication within the Matrix ecosystem. To get started, visit our GitLab repository or explore the room.

Dept of Clients 📱


A client packed with fun and convenient features.

airyz announces

Hello, world!

I'm excited to finally announce Commet! a new client for matrix! We are aiming to create a client that is packed with fun and convenient features, to help you connect with your friends.

We’ve been quietly in development over the past seven months and while we aren’t ready to call Commet stable, it is ‘stable enough’ to reveal it to the community

Despite being early in development, we have a few exciting features that help us stand out:

Built for multiple accounts

Commet was built from the ground up to have great support for running multiple accounts at once.

A Gif searcher in a matrix client?! We are running a proxy service for tenor, so you can easily send sarcastic gifs on matrix!

Custom Emotes / Stickers

We support the same custom emotes implementation that you might be familiar with from other clients!

Thats all for now! Check us out on github or stop by our room and say hi!

Neochat (website)

A client for matrix, the decentralized communication protocol

Tobias Fella says

We've landed a major feature in NeoChat this week: There's a now a page showing the subspaces and rooms in a space. This also allows for basic space administration tasks, like adding new rooms to the space. Internally, our Qt6 port is progressing, with all major changes being done now.

Element X iOS (website)

A total rewrite of Element-iOS using the Matrix Rust SDK underneath and targeting devices running iOS 16+.

Ștefan says

Busy week in Element X land:

  • Following small tweaks here and there Polls are now officially finished! 🥳
  • Work has started on support for voice messages
  • And also on user mention pills
  • We can now reply to more types of room messages
  • Our unit tests are more stable and ever and our coverage is at all time high at 71.4%
  • And we fixed bugs around UI and Integration tests, the Element Call integration, iOS 17 and more

Element X Android (website)

Android Matrix messenger application using the Matrix Rust Sdk and Jetpack Compose

benoit announces

  • Element X Android will be released on the PlayStore - once Google approves it - with a fix for the crash about the Camera permission.
  • Polls are getting the latest design tweak, notification with the poll question is coming.
  • Open a room is smoother than before, some stuff have been move to worker thread.
  • The bloom effect will also be rendered faster.
  • We are adding test to reach the target of 60% of code coverage. We are not far!
  • The Rich Text Editor can now be displayed in full screen mode.
  • Next week we will start October features: Key backup management; pin and biometric unlock; voice message; and rendering pills in the timeline.

Element Web/Desktop (website)

Secure and independent communication, connected via Matrix. Come talk with us in!

Johannes Marbach announces

  • We’re wrapping up some test stabilisation work on our notification test suite and will transition into fixing the failures next.
  • Visual regressions from the Compound adoption have mostly been fixed. We started applying a UI refresh to the right panel and are planning to unlabs it together with the room header once complete.
  • About 80% of our strings have been migrated over to Localazy. We’re getting close to finishing this off and reopening translations to contributors.
  • People living on the edge might have noticed that the Safari 17 update has broken our emoji fonts. We’re planning to put a hotfix together for this today. On the back of this we’re also considering doing away with bundled emoji fonts entirely and falling back to what the OS provides. The situation on this is looking much different these days compared to a few years ago.

Dept of VoIP 🤙

Calling for bridges

Malte E reports

During the Matrix community summit, Timo K.and I discussed reducing friction for video calls with bridged users. Instead of true call bridging, which would likely be months of work, we implemented a workaround within less than a day. Starting an MSC3401 call from Matrix will send an element call link to the remote platform user, which will skip login and room selection, taking them straight to the call in two clicks (one for the link and one to confirm). On the Matrix side, the experience is seamless, once a few prerequisites have been met: the matrix client must use MSC3401 and because element web currently defaults to legacy calling in DMs, a third user, such as the bridge bot, must be present in the room. Furthermore, a modified element call instance is needed. We have so far implemented calls via Element Call for matrix -> Telegram in DMs. We will be working on solutions for incoming calls and group calls as well as support for other platforms. There is currently still a major security concern: To skip the login process, the link comes with a token for the ghost account. Anyone with access to the token - that includes the matrix user who started the call - will be able to log in with that ghost account. We invalidate the token once the call has ended, but that is obviously nowhere near sufficient. Scoped access tokens with permissions for sending and receiving call events in a single room for a limited time would be required. On platforms using Double Ratchet E2E, it should also be possible to use different plaintext for different recipients in the same message, thereby only exposing the token to those who already implicitly have authority over the ghost account through their account on the remote platform.

For those brave enough to try, you will need this fork of mautrix-python, this fork of mautrix-telegram as well as this fork of element call or just use the instance hosted here. In the bridge config.yaml, set bridge.calls.enabled to true and provide the element call instance in bridge.calls.ec_url. Be sure that you trust everyone with access your bridge before deploying, until we have figured out how to make it safer.

We apologize for the subpar audio and glitches. We had limited time and equipment to record the demo and will try to do better next time {{< video src="vrcDiEGzmollhUGuTEONHVCE.m4v" >}}

Dept of SDKs and Frameworks 🧰


Emma [it/its] says

Not much changed this week:

  • Some refactors to how user identities are handled
  • Correction in function names to correctly display async vs non-async functions
  • AuthenticatedHomeserverGeneric.GetRoom(string id) is no longer async, since that is only a constructor call.
  • Sync code has gotten a slight cleanup
  • AuthenticatedHomeserverGeneric.WhoAmI was turned into a property that only gets fetched when attempting to get the info for the first time, rather than fetching it when constructing the homeserver object.
  • Added a null check for creationEvent.Invite when callign CreateRoom
    • This field was also made nullable
  • Renamed canonicalHomeServerDomain to baseUrl in the constructors for homeservers
  • FullHomeServerDomain and HomeServerDomain were removed from homeserver objects
  • Authentication was moved to a functions inside RemoteHomeserver rather than being service-only. This allows for usecases outside of Dependency Injection based applications
  • LoginResponse now tries to get homeserver canonical domain from mxid if not provided by the server (since this field is deprecated)
  • Removed an obsolete way to get room state without providing a type (can still pass JsonElement if required)
  • Fixed sending files in a room via room.SendFileAsync, this now does what you would expect instead of throwing an exception (because I'd written the wrong code)
  • Added room.DisbandRoomAsync() in the case you ever want to completely get rid of a room, ban everyone and make the room private
  • Added AddChildAsync to SpaceRoom, in order to allow adding space children
  • Removed TieredStorage arguments from homeserver constructor
  • Removed explicit http client creation for authenticated homeservers, in favor of re-using the one created in RemoteHomeserver
  • Fixed room.SendMessageEventAsync requiring an event type (this is always afaik)
  • Moved namespace LibMatrix.StateEventTypes.Spec to LibMatrix.EventTypes.Spec.State in order to better represent what's in that folder
  • Increased coverage of MatrixHttpClient to include PUT requests
  • Removed TieredStorageService argument from SyncHelper (I might make SyncHelper not part of homeserver in the future so you can have separate sync loops with different filters)
  • GetRoom(string id) now has a check that the id needs to start with a !
  • Added a Logout function to AuthenticatedHomeserverGeneric so you can properly dispose a session
  • Added the ability to resolve room aliases
  • Last, but definitely not least, some unit tests have been added!

Non-code updates:

  • Unit tests are powered by an unfederated homeserver at - there is no data persistence

As always:

  • The code is available at my git domain
    • If anyone wants to contribute a page to put there instead of a plain dumb git directory, please feel free to!
    • All other contributions are more than welcome, be it documentation, code, anything!
  • Discussion is welcome in

Trixnity (website)

Multiplatform Kotlin SDK for Matrix

Michael announces

We are happy to announce that Trixnity Messenger is open source now. It is a Kotlin multiplatform Matrix messenger SDK built on top of Trixnity. It defines a messenger client without specifying a UI layer (think of it as a headless messenger). All it provides is a series of view models that define the structure and logic of a messenger. It has never been easier to implement a Matrix messenger targeting multiple platforms such as Android, iOS, Desktop or the web. Just define how it should look - all the logic and nitty-gritty details are already accounted for. And if you do not like the behavior of the messenger in some parts, just extend or override the existing logic with your own. There is no need to fork the project. So join us at and in

matrix-rust-sdk (website)

Next-gen crypto-included SDK for developing Clients, Bots and Appservices; written in Rust with bindings for Node, Swift and WASM

Jonas Platte reports

Dept of Internet of Things 💡

Home Assistant - Matrix Integration

Paarth Shah announces

I'm happy to announce that Home Assistant 2023.10 release (in beta at the time of writing) includes my PR to refactor the included matrix integration to use matrix-nio! You can see the full changelog here. As part of the merge, I've also become the code owner for the integration.

In the 2023-06-09 TWIM I announced that I'd created matrix-nio-hacs as a stand-in while this had still been pending merge. As it will no longer be necessary, for those of you who have been using it, I'll eventually be archiving the repository since I now will be able to continue development directly on home assistant core. Any and all bug reports and/or PRs will be greatly appreciated!

Dept of Events and Talks 🗣️

Matrix User Meetup Berlin

saces reports

Long time no matrix meetup? We can help!

Next Matrix user meetup 4.10.2023, 8 pm @ c-base

Meet other matrix users, chat about Matrix, the rest, and everything else, discuss your Matrix ideas, sign each other in persona, and maybe spice the evening with a good mate or beer.

Every first Wednesday of the month in the c-base at 8pm ('til the next pandemic).

Matrix room:

Matrix Salon Podcast (German episode)

Christian Paul (jaller94) says

Meet Nadine, a designer and UX enthusiast who builds Polychat. Polychat is a bridging service for people from different messenger silos. This way, people won't need to leave their familiar messenger silo to talk to group on other platforms.

Episode url: RSS feed: Mastodon post:

For English interviews of Matrix community members, check out some of our previous episodes! Also, in the upcoming weeks, we'll release two more English episodes.

Dept of Interesting Projects 🛰️


Janet Blackquill reports

Hi, I present to y'all a little bot called Mappo. He's technically been around for a while, but I polished him up with some new Matrix features as of late to bring him closer to his presence on Discord, and I haven't really promoted it before.

He's a lil noodly jellyfish fella that lets you play the eponymous social deduction game of Mappo where some people are villagers and some people are creatures. The village is trying to figure out who the creatures are to exile them, but at the same time, the creatures are slowly picking them off, one-by-one until they outnumber them! Who wins is determined by who's the best at deducing the truth (or obfuscating it if you're one of the creatures!) The roles range from the conventional like the Seer and Werewolf to the wild and wacky like Cookie Person and Goose.

His source is located on GitHub at Mappo is unique for a bot due to being multi-protocol with a core logic speaking to an abstraction layer implemented for both Discord and Matrix.

If you wanna check out Mappo in action, come stop by and give the game a try with other people!


HarHarLinks reports

Hi from the Matrix Community Summit Sunday Hackathon!

That's right, a couple people were still alive on Sunday after one awesome Thursday of BarCamp BarCamping and two more excellent days full of Matrix programme and programming across two stages and got together for some creative Matrix hacking!

We had a bunch of interesting projects, see the announcement about VoIP bridging from Malte E. and Timo K. Personally, I was involved in the event T-Shirt creation revised MSC2997 implementation with the wonderful If you look at that more closely, you'll find there is an mxc-URL in the event body. is hosted using GitLab pages, so you can't just do anything you want, however challenge_accepted.jpg. Of course, entering it into your browser works (how?), try it out!

The obvious idea was to also make it all work through matrix so that in the future, once other client's implement the event scheme, the event will properly work? But how would we set up a media on a defined media ID and ...could we circumvent having to set up it's own homeserver just for this gimmick, or even any additional infrastructure at all?

Luckily I was sitting next to the excellent Nico from Nheko and we started hacking! After stumbling over the need to still offer working legacy r0 endpoints, we quickly got it working. Try a with:

  "content": {
    "body": "Summit Logo.png",
    "info": {
      "h": 1578,
      "mimetype": "image/png",
      "size": 386815,
      "w": 2022
    "msgtype": "m.image",
    "url": "mxc://"

We learned during the event that we would have liked its Matrix rooms and space(s) to be more discoverable, so we continued prototyping with the room directory for next year. The /_matrix/federation/v1/publicRooms is not too complicated, it's basically a list of room IDs with a couple attributes we had to hardcode...:

  "avatar_url": "mxc://",
  "guest_can_join": false,
  "join_rule": "public",
  "name": "Matrix Community Summit Berlin 2023",
  "num_joined_members": 1000000,
  "room_id": "!",
  "room_type": "",
  "topic": "Summit on 21-23 September 2023.\n @c-base in Berlin\n \n a barcamp - 21th\n a conference - 22/23th\n open door day - 24th (to be confirmed)",
  "world_readable": true

However it was not quite so easy. As you can see above, the endpoint - like most of Matrix - doesn't use a file type extension. It turns out that Synapse really wants that piece of JSON to served with the JSON mime type, but GitLab pages' does not support setting the mime type manually and can only derive it automatically using some heuristic. Thanks to the manical investigation into that heuristic, Nico came up with the idea to use GitLab's _redirects or more precisely rewrite function to forward from the Matrix endpoint to the actual file served with the .json extension and what can I say - it works as proven by this screenshot from Nheko (it's Other Clients October soon, so try using Nheko)!

What if I told you there were even more hackers there? urp picked up where we achieved our goals and continued testing. You can follow the experiments being done and the documented findings on GitLab/matrix-static and join the effort or give feedback in the matrix room matrix-static-server..

Overall we can absolutely recommend you try hacking with some static Matrix for your project, I can see lots of applications for hosting media alone. Until next time! 👋

Department of Community Initiatives 👪️

For everything impulsed by the community that is not an Foundation initiative.

Matrix Community Forum

MTRNord announces

Changes and new features

  • Email registration should be fixed. If you tried to register and didn't get the activation email, check your spam folder please
  • There now is a way to announce events and get them into a calendar at
    • For example, TWIM is in the calendar (also contains some Tips and Tricks for your next post :) feel free to add more of these if you have them!)
  • Categories have been reorganized to be more useful
  • Login via GitHub is possible - Login via matrix will only be possible after OIDC lands in Matrix spec and is adapted by users
  • Small nice to have features have been added
    • Support for setting a birthdate this seems to break the forum
    • Support for Footnotes
    • Support for templates
    • A dark/light mode toggle
    • User Fields for mxid, git(hub) (and friends) ID, pronouns have been added to be optionally set on the profile.
  • Added the gamification plugin which gives a Forum Leaderboard which may help to motivate some people that are not coders and gives those people rewards too. Additionally, there could be also further integration, for example using

Planned things

  • Support for integration into existing Matrix based communication using
  • Possibly finding a way to get events announced in twim also into the forum automatically

Discussion Area

Anything more permanent like wishes or request should be in the forum itself at

However for quick discussions or questions there is available too.

Asbjørn announces

Other Clients October

We're doing it again!

Other Clients October is a month-long challenge, where we switch away from our daily-driver Matrix clients completely for a the entire month if October.

It's a nice way to explore the rich space of Matrix clients.

Only use Element? Maybe check out Cinny. Only use Fluffychat? Try kicking the tires on ElementX. Only use Nheko? Why not try out Gomuks? Working on a client? Give dogfooding it a shot this month!

Join the Matrix room:

Say hi, and tell us what clients you'll be trying!

Dept of Ping

Here we reveal, rank, and applaud the homeservers with the lowest ping, as measured by pingbot, a maubot that you can host on your own server.

Join to experience the fun live, and to find out how to add YOUR server to the game.

RankHostnameMedian MS

Join to experience the fun live, and to find out how to add YOUR server to the game.

RankHostnameMedian MS

That's all I know

See you next week, and be sure to stop by with your updates!

This Week in Matrix 2023-09-22

22.09.2023 18:30 — This Week in Matrix Thib

Matrix Live

Dept of Status of Matrix 🌡️

Thib announces

Let me start right away with no less than a sneak peek at Matrix 2.0. Matthew walks us through the most exciting MSCs currently in flight with working implementations, that will be drastically changing the experience on Matrix.

One of those MSCs makes Matrix support OIDC. But Synapse already supports OIDC, right? If you want to learn more about the difference between OIDC and OIDC (sic) and how it's going to impact you, the auth team and I wrote a post for you.

Continue reading…

Matrix 2.0: The Future of Matrix

21.09.2023 15:30 — General Matthew Hodgson

TL;DR: If you want to play with a shiny new Matrix 2.0 client, head over to Element X.

Matrix has been going for over 9 years now, providing an open standard for secure, decentralised communication for the open Web - and it’s been quite the journey to get to where we are today. Right now, according to Synapse’s opt-in usage reporting, in total there are 111,873,374 matrix IDs on the public network, spanning 17,289,201 rooms, spread over 64,256 servers. This is just scratching the surface, given we estimate that 66% of servers in the public network don’t report stats, and there are many enormous private networks of servers too. We’ve come a long way from creating Matrix HQ as the first ever room on today’s public network, back on Aug 13th 2014 :)

Meanwhile, the Matrix ecosystem has continued to grow unbelievably - with huge numbers of independent clients, bots and bridges maturing into ecosystems of their own, whole new companies forming around the protocol, and organisations ranging from open source projects to governments, NGOs and Fortune 100 companies adopting Matrix as a way to run their own secure, decentralised, standards-based self-sovereign communication.

The world needs Matrix more than ever. Every day the importance of decentralisation is more painfully obvious, as we concretely see the terrifying risks of centralised Internet services - whether that’s through corporate takeover, state censorship, blanket surveillance, Internet shutdowns, surveillance capitalism, or the spectre of gigantic centralised data breaches. It’s been amazing to see the world pivot in favour of decentralisation over the time we’ve been building Matrix, and our mission has never been more important.

On one hand it feels we’re creeping ever closer to that goal of providing the missing communication layer for the open Web. The European Union’s Digital Markets Act (DMA) is a huge step in that direction - regulation that mandates that if the large centralised messaging providers are to operate in the EU, they must interoperate. We’ve been busy working away to make this a reality, including participating in the IETF for the first time as part of the MIMI working group - demonstrating concretely how (for instance) Android Messages could natively speak Matrix in order to interoperate with other services, while preserving end-to-end encryption.

On the other hand, Matrix has often got stuck in focusing on solving the Hard Problems of decentralisation, decentralised end-to-end encryption, and the logistical complexities of supporting a massive heterogeneous public communication network and its surrounding heterogeneous ecosystem. It’s fair to say that in the early days our focus was on making something that worked at all - and then later, we shifted to focusing on something that worked and scaled correctly… but we hadn’t managed to focus on ensuring that Matrix provides the building blocks necessary to create blazingly fast, hyper-efficient communication apps which has potential to outperform the centralised mainstream messaging services…

…until now!

Matrix 2.0

Back at FOSDEM we announced the idea of Matrix 2.0 - a series of huge step changes in terms of Matrix’s usability and performance, made up of Sliding Sync (instant login/launch/sync), Native OIDC (industry-standard authentication), Native Group VoIP (end-to-end encrypted large-scale voice & video conferencing) and Faster Joins (lazy-loading room state when your server joins a room).

Now, we’re excited to announce that as of today everyone can start playing with these Matrix 2.0 features. There’s still some work to bring them formally into the specification, but we’re putting it out there for folks to experience right now. Developers: watch this space for updates on the spec front.

Practically speaking, this means there are now implementations of the four pillars of Matrix 2.0 available today which you can use to power a daily-driver Matrix 2.0 client. The work here has been driven primarily by Element, using their new Element X client as the test-bed for the new Matrix 2.0 functionality and to prove that the new APIs are informed by real-world usage and can concretely demonstrably create an app which begins to outperform iMessage, WhatsApp and Telegram in terms of usability and performance… all while benefiting from being 100% built on Matrix.

matrix-rust-sdk and Element X

The mission of Matrix 2.0 has been to provide a huge step forwards in real-world performance, usability and stability - and that means using a real client codebase as a guinea pig to ensure the new protocol is fit for purpose. matrix-rust-sdk has been the main vehicle for this, with Element X as the app primarily driving the new features (although other clients built on matrix-rust-sdk such as Fractal 5 can then automatically benefit from the work should they wish).

To see what all the fuss is about, your best bet is probably to head over to the Element X launch blog post and read all about it! But from the Matrix perspective, this is a flag day in terms of the existence of a Matrix client which empirically outperforms the mainstream clients both in terms of usability and performance: it shows that Matrix is indeed viable to power communication for billions of users, should we get the chance.

From a client perspective: this has meant implementing Sliding Sync (MSC3575) in matrix-rust-sdk - and then creating the entirely new matrix-sdk-ui crate in order to expose higher level APIs to help apps efficiently drive their UI, without each app having to keep reinventing the wheel and risking getting it wrong. The new UI crate gives APIs for efficiently managing a lazy-loaded room list, lazy-loaded room timelines (including edits, reactions, aggregations, redactions etc), and even when the app should show a sync spinner or not. As a result, the vast majority of the heavy lifting can be handled in matrix-rust-sdk, ensuring that the app layer can focus on UI rather than Matrix guts - and performance improvements (e.g. roomlist caching and timeline caching) can all be handled in one place to the benefit of all clients using the SDK.

This is a huge breakthrough relative to the old days of Matrix where each client would have no choice but burn significant amounts of time hand-carving its own timeline and encryption glue logic (although of course clients are still very welcome to do so if they wish!) - but for those wanting higher-level building blocks, matrix-rust-sdk now provides an excellent basis for experimenting with Matrix 2.0 clients. It’s worth noting that the library is still evolving fast, though, and many APIs are not long-term stable. Both the Sliding Sync API and the UI crates are still subject to significant change, and while the crypto crate and its underlying vodozemac E2EE implementation is pretty stable, features such as E2EE Backup are still being added to the top-level matrix-rust-sdk (and thence Element X).

In order to hook matrix-rust-sdk up to Element X, the Element team ended up contributing cancellable async bindings to uniffi, Mozilla’s language binding generator, so you can now call matrix-rust-sdk directly from Swift, Kotlin and (in theory) other languages, complete with beautifully simple async/await non-blocking semantics. This looks to be a pretty awesome stack for doing modern cross-platform development - so even if you have a project which isn’t natively in Rust, you should be able to lean on matrix-rust-sdk if you so desire! We hope that other projects will follow the Rust + Swift/Kotlin pattern for their extreme performance needs :)

Sliding Sync

The single biggest change in Matrix 2.0 is the proposal of an entirely new sync API called Sliding Sync (MSC3575). The goal of Sliding Sync is to ensure that the application has the option of loading the absolutely bare essential data required to render its visible user interface - ensuring that operations which have historically been horribly slow in Matrix (login and initial sync, launch and incremental sync) are instant, no matter how many rooms the user is in or how large those rooms are.

While matrix-rust-sdk implements both Sync v2 (the current API in Matrix 1.8) as well as Sliding Sync, Element X deliberately only implements Sliding Sync, in order to focus exclusively on getting the fastest UI possible (and generally to exercise the API). Therefore to use Element X, you need to be running a homeserver with Sliding Sync support, which (for now) means running a sliding-sync proxy which bolts Sliding Sync support on to existing homeservers. You can check out Thib’s excellent tutorial for how to get up and running (or Element Server Suite provides packages from the Element team)

Now, implementing Sliding Sync in matrix-rust-sdk has been a bit of a journey. Since we showed off the very first implementation at FOSDEM, two big problems came to light. For a bit of context: the original design of Sliding Sync was heavily inspired by Discord’s architecture - where the server calculates an ordered list of large numbers of items (your room list, in Matrix’s case); the client says which window into the list it’s currently displaying; and the server sends updates to the client as the view changes. The user then scrolls around that list, sliding the window up and down, and the server sends the appropriate updates - hence the name Sliding Sync.

Sliding Sync was originally driven by our work on Low Bandwidth Matrix - as it makes no sense to have a fancy line protocol which can run over a 2400 baud modem… if the first thing the app tries to do is download a 100MB Sync v2 initial-sync response, or for that matter a 10MB incremental-sync response after having been offline for a few days (10MB takes 9 hours to shift over a 2400 baud modem, for those who missed out on the 80s). Instead, you clearly only want to send the absolute essentials to the client, no matter how big their account is, and that’s what Sliding Sync does.

The first minor flaw in the plan, however, is that the server doesn’t necessarily have all the data it needs to order the room list. Room ordering depends on what the most recent visible events are in a room, and if the room’s end-to-end encrypted, the server has no way of knowing which events are going to be visible for a given client or not. It also doesn’t know which rooms have encrypted mentions inside them, and we don’t want to leak mention metadata to the server, or design out keyword mentions. So, MSC3575 proposed some complicated contortions to let the client tweak the order client-side based on its superior knowledge of the ordering (given most clients would need to sync all the encrypted rooms anyway, in order to index them and search for keyword notifications etc). Meanwhile, the order might be ‘good enough’ even without those tweaks.

The second minor flaw in the plan was that having implemented Sliding Sync in Element X, it turns out that the user experience on mobile of incrementally loading in room list entries from the server as the user scrolls around the list is simply not good enough, especially on bad connectivity - and the last thing we want to do is to design out support for bad connectivity in Matrix. Users have been trained on mobile to expect to be able to swipe rapidly through infinite-scrolling lists of tens of thousands of photos in their photo gallery, or tens of thousands of emails in their mail client, without ever seeing a single placeholder, even for a frame. So if the network roundtrip time to your server is even 100ms, and Sliding Sync is operating infinitely quickly, you’re still going to end up showing a placeholders for a few frames (6 frames, at 60fps, to be precise) if the user starts scrolling rapidly through their room list. And empirically that doesn’t look great - the 2007-vintage iOS team have a lot to answer for in terms of setting user expectations!

So, the obvious way to solve both of these problems is simply to pull in more data in the background, to anticipate the user scrolling around. In fact, it turns out we need to do that anyway, and indeed pull in all the room data so that room-search is instantly responsive; waiting 100ms or more to talk to the server whenever the user tries to search their roomlist is no fun at all, and it transpires that many users navigate their roomlist entirely by search rather than scrolling. As a result, the sliding sync implementation in matrix-rust-sdk has ended up maintaining an ‘all rooms’ list, which starts off syncing the roomlist details for the most recent N rooms, and then in the background expands to sync all the rest. At which point we’re not really sliding a window around any more: instead it’s more of a QoSed incremental sync.

So, to cut a long story short: while the current Sliding Sync implementation in matrix-rust-sdk and Element X empirically works very well, it’s ended up being a bit too complicated and we expect some pretty significant simplifications in the near future based on the best practices figured out with clients using it. Watch this space for updates, although it’s likely that the current form of MSC3575 will prevail in some respect in order to support low-bandwidth environments where roomlist ordering and roomsearch latency is less important than preserving bandwidth. Critically, we want to figure this out before we encourage folks to implement native server implementations - so for now, we’ll be keeping using the sliding-sync proxy as a way to rapidly experiment with the API as it evolves.

Native Matrix Group VoIP

Another pillar of Matrix 2.0 is that we finally have native Matrix Group VoIP calling (MSC3401)! Much like Sliding Sync has been developed using Element X as a testbed, Element Call has been the guinea pig for getting fully end-to-end-encrypted, scalable group voice/video calling implemented on top of Matrix, building on top of matrix-js-sdk. And as of today, Element Call finally has it working, complete with end-to-end encryption (and integrated in Element X, for that matter)!

Much like Sliding Sync, this has also been a bit of a journey. The original implementations of Element Call strictly followed MSC3401, using full mesh conferencing to effectively have every participant place a call to every other participant - thus decentralising the conference and avoiding the need for a conferencing ‘focus’ server… but limiting the conference to 7 or 8 participants given all the duplication of the sent video required. In Element Call Beta 2, end-to-end encryption was enabled; easy, given it’s just a set of 1:1 calls.

Then the real adventure began: to implement a Selective Forwarding Unit (SFU) which can be used to scale up to hundreds of users - or beyond. The unexpected first move came from Sean DuBois, project lead of the awesome Pion WebRTC stack for Golang - who wrote a proof-of-concept called sfu-to-sfu to demonstrate the viability of decentralised heterogenous cascading SFUs, as detailed in MSC3898. This would not only let calls on a single focus scale beyond hundreds of users, but also share the conferencing out across all the participating foci, providing the world’s first heterogeneous decentralised video conferencing. Element took the sfu-to-sfu implementation, hooked it up to Element Call on a branch, and renamed it as waterfall.

However, when Sean first contributed sfu-to-sfu, he mentioned to us that if Matrix is serious about SFUs, we should take a look at LiveKit - an open source startup not dissimilar to Element who were busy building best-in-class SFUs on top of Pion. And while waterfall worked well as a proof of concept, it became increasingly obvious that there’s a lot of work to be done around tuning congestion control, error correction, implementing end-to-end encryption etc which the LiveKit team had already spent years doing. So, Element reached out to the LiveKit team, and started experimenting with what it might take to implement a Matrix-capable SFU on top of the LiveKit engine.

The end result was Element Call Beta 3, which is an interesting hybrid between MSC3401 and LiveKit’s existing signalling: the high-level signalling of the call (its existence, membership, duration etc) is advertised by Matrix - but the actual WebRTC signalling is handled by LiveKit, providing support for hundreds of users per call.

Finally, today marks the release of Element Call Beta 4, which adds back end-to-end encryption via the LiveKit SFU (currently by using a shared static secret, but in the near future will support full Matrix-negotiated end-to-end encryption with sender keys) - and also includes a complete visual refresh. The next steps here include bringing back support for full mesh as well as SFU, for environments without an SFU, and updating all the MSCs to recognise the hybrid signalling model that reality has converged on when using LiveKit. Meanwhile, head over to to give it a go, or read more about it in the Element X Ignition blog post!

Native Open ID Connect

Finally, last but not least, we’re proud to announce that the project to replace Matrix’s venerable existing authentication APIs with industry-standard Open ID Connect in Matrix 2.0 has taken a huge leap forwards today, with matrix-authentication-service now being available to add Native OIDC support to Synapse, as well as Element X now implementing account registration, login and management via Native OIDC (with legacy support only for login/logout).

This is a critical step forwards in improving the security and maintainability for Matrix’s authentication, and you can read all about it in this dedicated post, explaining the rationale for adopting OpenID Connect for all forms of authentication throughout Matrix, and what you need to know about the transition.


There has been an enormous amount of work that has gone into Matrix 2.0 so far - whether that’s implementing sliding sync in matrix-rust-sdk and sliding-sync proxy, matrix-authentication-service and all the native OIDC infrastructure on servers and clients, the entirety of Element Call and its underpinning matrix-js-sdk and SFU work, or indeed Faster Joins in Synapse, which shipped back in Jan.

It’s been a pretty stressful sprint to pull it all together, and huge thanks go to everyone who’s contributed - both from the team at Element, but also contributors to other projects like matrix-rust-sdk who have got caught in the crossfire :) It’s also been amazing seeing the level of support, high quality testing and excellent feedback from the wider community as folks have got excited about the promise of Matrix 2.0.

On the Foundation side, we’d like to thank the Members whose financial support has been critical in providing bandwidth to enable the progress on Matrix 2.0 - and for those who want to help accelerate Matrix, especially those commercially building on top of Matrix, please consider joining the Foundation as a member! Also, in case you missed it, we’re super excited to welcome Josh Simmons as Managing Director for the Foundation - focusing on running the Foundation membership programme and generally ensuring the growth of the Foundation funding for the benefit of the whole Matrix community. Matthew and Amandine continue to lead the overall project (alongside their day jobs at Element), with the support of the other three independent Guardians - but Josh is working full time exclusively on running the non-profit foundation and gathering funds to support Matrix.

Talking of funding, we should mention that we’ve had to pause work in other places due to lack of Matrix funding - especially while focusing on successfully shipping Matrix 2.0. Major next-generation projects including Third Room, P2P Matrix, and Low Bandwidth Matrix have all been paused unless there’s a major shift in circumstances - so, if you have money and you’re interested in a world where the more experimental next-generation Matrix projects progress with folks working on them as their day job, please get in touch with the Foundation.

What’s next?

While this is the first usable release of Matrix 2.0 implementations, there’s loads of work still to be done - obvious work on Matrix 2.0 includes:

  • Getting Native OIDC enabled on, and providing migration tools to Native OIDC for existing homeservers in general
  • Reworking Sliding Sync based on the lessons learned implementing it in matrix-rust-sdk
  • Actually getting the Matrix 2.0 MSCs stabilised and matured to the point they can be approved and merged into the spec
  • Adding encrypted backups to matrix-rust-sdk
  • Reintroducing full-mesh support for Native Matrix Group VoIP calling
  • Having a big Matrix 2.0 launch party once the spec lands!

Outside of Matrix 2.0 work, other big items on the horizon include:

  • Adding Rust matrix-sdk-crypto to matrix-js-sdk, at which point all the official client SDKs will (at last!) be using the same stable performant E2EE implementation
  • Continuing to contribute Matrix input to the MIMI working group in IETF for Digital Markets Act interoperability
  • Working on MLS for next-generation E2EE
  • Next generation moderation tooling and capabilities
  • Account Portability and Multihomed accounts
  • …and much much more.

So: welcome to our brave new Matrix 2.0 world. We hope you’re excited about it as we are - and thanks to everyone for continuing to use Matrix and build on it. Here’s to the beginning of a whole new era!

Matthew, Amandine and the whole Matrix team.

Better authentication, session management and permissions in Matrix

21.09.2023 14:00 — General Thib , Matrix Auth Team

Before we explain all about our new authentication system - don't panic! This change is part of Matrix 2.0, the next step for Matrix that will be introduced in a blog post later today.

Nothing breaks

Matrix 2.0 is a reference to Matthew’s FOSDEM talk Matrix 2.0, itself a reference to the name he coined in the Matrix Summer Special 2022: evolutions of the spec that are making the Matrix experience so much better it almost feels like a different protocol. One of the major changes in this bundle is the introduction of OpenID Connect-native Matrix and its implementation matrix-authentication-service (MAS).

Don’t panic: your current setup is not at risk, you don’t urgently need to deploy the matrix-authentication-service to keep using Matrix.

Let’s walk together through what OIDC-native Matrix, what changes as compared to the Matrix we know and love, and what’s the impact for your deployment.

From OIDC-ish to OIDC

One of the most popular Matrix server implementations, Synapse, supports authentication via OIDC. This is the only mainstream server implementation to support authentication via an OpenID Connect Provider. OpenID Connect, SAML, and more generally Single Sign On (SSO) are a requirement for most companies past a certain size, as well as a security best practice.

As it is today, Synapse is more OIDC-compatible than OIDC-native. This means that it’s possible to use SSO (typically OpenID Connect) to connect to Synapse, but that’s about where the OpenID Connect adventure stops. Once you’re authenticated, Synapse generates a Matrix Access Token for your client, but that is not an OAuth2/OIDC Access Token. From your client point of view, it is doing the “Matrix SSO dance” defined by the spec, but the fact that Synapse does a login via OIDC, SAML or CAS is irrelevant to the client. Whenever your client asks Synapse for anything that requires being logged in, it sends that Matrix Access Token in the Authorization header of the http requests.

While this approach has served Matrix well, the Matrix Access Token method is reimplementing some concepts of OpenID Connect without all the benefits of thousands of developers battle testing and fixing every edge case they meet.

MSC3861, which proposes the adoption of OIDC in Matrix, is all about embracing the best of OIDC to make Matrix even better. By adopting the standard OIDC flows we allow Matrix to stand on the shoulders of another battle-tested industry standard. Not only does it improve security overall, it also unlocks new use cases for Matrix.

Unlocking use cases

The Matrix Access Tokens Matrix currently relies on are secure, but not very flexible. A unique token is granted to each and every client during user login. This Matrix Access Token is only revoked when the user manages their sessions and logs a device out. A Matrix Access Token gives full access to a Matrix Account. Session management based on Matrix Access Tokens is quite nuclear.

Using OpenID Connect for Matrix comes with three major areas of improvements:

  • Standard authentication process on every client, including on devices without a keyboard
  • Improved security with token rotation
  • Better granularity of permissions (which improves security too!)

Authenticate like you want

When relying on OIDC, the client delegates authentication to the OpenID Provider. This means that the client redirects the user to a web page on the OpenID Provider, where the user needs to authenticate. This authentication can happen through a username and password, WebAuthn (passwordless login), additional steps if you want to add MFA… and much more.

Since the authentication happens on the OpenID Provider, the client doesn’t need to support any authentication method other than “redirect the user to the OpenID Provider, and handle the result”. Once the user has authenticated against the OpenID Provider, it is going to be redirected back to its client, to allow it to retrieve an Access Token on their behalf.

During the whole process, no password was given to the client, and the client doesn’t even know how the user authenticated. All that matters to the client is that it now has an Access Token it can use to perform the regular Matrix API calls.

From the user perspective, the authentication is a very familiar process very well integrated in their password manager regardless of the client they use. They can use any client that supports OIDC, without having to worry about whether it supports every particular step of their authentication process. It’s also worth noting that matrix-authentication-service has a compatibility layer to support the m.login.password flow. This means compatibility with older clients will not break!

From the administrator perspective, it’s possible to force authentication flows (e.g. MFA), making sure the login is secure and matches their organisation’s policies. It also makes it possible to have a central management of all users' devices, including the ability to enforce policies upon them as provided by the OpenID Provider. For example, it becomes possible to the re-authentication of the user if they leave a trusted network.

From the developer perspective, neither clients nor servers have to add support for every new authentication method, existing or to come.

Element has been spearheading the effort to implement MSC3861 and matrix-authentication-service, and Element X is the first client to support them. Here is how the authentication flow and account management look like as seen from Element X iOS.

Token rotation

While current Matrix Access Token can expire thanks to MSC2918, this best practice didn’t make it to most of the clients of the ecosystem. If the access token of a user was leaked for one reason or another, they wouldn’t notice since this wouldn’t create a new session, and the leaked token would be valid forever. Please note that thanks to E2EE, attackers who gain access to a Matrix Access Token would not be able to read the encrypted content in encrypted rooms.

OpenID Connect relies on two tokens:

  • an Access Token, that is used to perform the authenticated API calls, and that expires regularly,
  • and a Refresh Token that is used in conjunction with the Access Token to rotate both.

This ensures that if the Access Token was leaked during an API call, its validity would be very limited in time. Leaking a Refresh Token will also have limited impact, since the server would notice that two different clients are trying to consume the same Refresh Token and would log the user out from devices using this token.

Principle of least privilege

Matrix is not just about apps and servers. It’s also a vibrant ecosystem of widgets, bots and various CLI to toy with. One of the strengths of Matrix has been its hackability: log into a client, dump the matrix access token, and you can hand it to a CLI or a bot for it to do things on your behalf.

While this approach is particularly convenient for development, it comes with its own lot of issues. Most of the time you don’t want the CLI or bot to be able to do everything on your behalf.

Widgets are another case where OIDC can help. While widgets are not yet part of the spec, in practice they are already commonly used. In essence, a widget is a tiny app that has access to an (unspecified) widgets API that allows it to do a limited amount of things on behalf of the user, such as sending a message in the rooms it’s in. While this has served several clients well, this can be improved. Indeed, it’s up to the client to enforce the restrictions mandated by the widgets API. This means you can’t be assured that all the clients will consistently enforce them.

With OpenID Connect, widgets can eventually become tiny embedded Matrix clients on their own, and they can get their own Access Token with explicit and granular permissions of their own. Those restrictions will be enforced by the server, who will not even be aware it’s a widget calling the API, making the experience consistent across clients. This behaviour still needs to be added to the specification, but a more OIDC-native Matrix paves the way for it.

Upgrading to use matrix-authentication-service

MSC3861 (and friends) define how the OIDC flows and concepts (e.g. token exchange, dynamic client registration) should be used in Matrix, as well as the requirements for things which need to be coordinated with the homeserver (e.g. session lifecycle management).

The goals of matrix-authentication-service (MAS) are two-fold: firstly, it provides an implementation of the MSCs to support the Matrix Specification Change (MSC) process; secondly, it provides capabilities to facilitate the transition of the Matrix ecosystem to OIDC.

Because MSC3861 is changing the technical mechanism by which your client gets access to your account it is not something that can be done by pushing a single, big button.Instead we need a transition period where both OIDC and the existing legacy Matrix authentication methods coexist so that different clients and homeservers can migrate at their own pace.

One way in which MAS facilitates this transition is by allowing deployments without an external Identity Provider (IdP) to use OIDC out-of-the-box. This means that MAS will support some of the current flows that Synapse supports, primarily in the form of password-based login. Please note those flows are not supported yet: MAS requires an external IdP for now.

Another way is that MAS allows for existing sessions and access tokens to be imported (just from Synapse so far) so that there is no need for clients to re-authenticate when a homeserver is migrated.

Because of these migration capabilities we expect MAS to be widely used, however, in keeping with the open philosophy of Matrix, we expect other implementations to exist either standalone or integrated with other OIDC providers like Keycloak or Dex.

MAS is not intended to be a fully fledged IdP solution: we suggest using a dedicated software for this if you want to do more than what is included.

Currently MAS is deployable as a sidecar service alongside the homeserver. While larger setups shouldn’t see this as a problem, it might be seen as cumbersome in smaller self-hosted setups. For the sake of convenience, the Synapse and MAS team are investigating how to bundle MAS along with Synapse natively using PyO3. We anticipate such a bundle to exist by the end of Q2 2024.

You can browse the matrix-authentication-service docs to get all the technical details and installation steps.

This Week in Matrix 2023-09-15

15.09.2023 00:00 — This Week in Matrix Thib

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

MSC Status

New MSCs:

MSCs proposed for Final Comment Period:

MSCs in Final Comment Period:

  • No MSCs are in FCP.

Accepted MSCs:

  • No MSCs were accepted this week.

Closed MSCs:

  • No MSCs were closed/rejected this week.

New MSCs in detail

In this new segment, we aim to give a bit more context as to why an MSC was opened, beyond what is available in the MSC's introduction.

MSC4056 stems from a conversation held back at IETF 117, where members of the Spec Core Team (SCT) were attempting to make RBAC work in Matrix. Thankfully, there was prior art in the form of MSC2812, but a problem with decentralization (and specifically state resolution) was discovered. Thoughts were had about how to fix it, and MSC4056 is the result of those thoughts. Implementation work is eventually planned for this MSC, but in the meantime it should see forwards movement with the SCT's involvement in the MIMI working group at the IETF.

If you have thoughts or suggestions about the very Discord-centric approach, please leave them on the MSC :)

Continue reading…

Welcoming Josh Simmons as Managing Director of the Foundation!

05.09.2023 00:00 — Foundation Matthew Hodgson , Amandine Le Pape

Hi all,

Today is a big day! As you know, over the last few months we’ve been searching for a Managing Director to join the Foundation full-time, focused on managing the Foundation’s finances, organising the Foundation’s membership programme, helping raise funding to support Foundation work, working with the Guardians to ensure the Foundation stays on mission, and ensuring the Foundation can operate successfully as a fully independent entity.

Continue reading…

This Week in Matrix 2023-09-01

01.09.2023 00:00 — This Week in Matrix Thib

Matrix Live

Dept of Status of Matrix 🌡️

Thib says

We’d like to thank everyone for their patience as we continue to work toward restoring the Libera.Chat bridge, and apologize for the continued inconvenience. We’ve heard from many people and communities who are impacted, who have confirmed that operating this bridge is an important service and we remain committed to getting it back online.

It’s been a month since our last update and folks have been reaching out, so we wanted to take this opportunity to provide a brief update.

The bridge team at Element is still actively working on the issues that led to the bridge being disabled in the first place. You can see some of the work that’s in flight through GitHub PRs: #1757, #1766, #1764, #1734.

We’re also looking into a way to transition responsibility for the bridge from Element to being directly run by The Foundation over the coming months - more details as we have them.

Unfortunately, we do not yet have a clear timeline for bringing the bridge back online. We’ll continue providing regular updates and will share more information as soon as we can. Thank you again for your patience! Please do not hesitate to reach out at if you have any questions or concerns.

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

MSC Status

New MSCs:

  • There were no new MSCs this week.

MSCs in Final Comment Period:

Accepted MSCs:

  • No MSCs were accepted this week.

Closed MSCs:

  • No MSCs were closed/rejected this week.

New MSCs in detail

In this new segment, we aim to give a bit more context as to why an MSC was opened, beyond what is available in the MSC's introduction.

For MSC4026, the primary motivation came out of the Element Backend team's desire to selectively enable new and experimental Matrix features for only a subset of users on Experimental features are exciting, but also have the chance to break clients completely. By only enabling a feature for a small subset of users, system administrators can ensure that there is no breakage before widening the set of users.

By adding optional authentication to the /versions client endpoint, which has a set of unstable_features flags, the homeserver is able to know which user the request came from. From there, it can decide whether a certain feature should be advertised as enabled or disabled.

The expected outcome of this is safer deployments - and ultimately less panicking when (not if) something breaks.

Spec Updates

Matrix v1.8 was released last week, and hot on the heels we're now working towards Matrix v1.9, due November 2023.

See the "Upcoming in Matrix 1.9" section of the linked blogpost for the MSCs that the Spec Core Team plan to land in time for v1.9!

Random MSC of the Week

The random MSC of the week is... MSC3160: Message timezone markup!

This MSC proposes new HTML syntax for formatted with a <time> tag that could display a time automatically based on the receiving user's timezone/12 or 24hr/etc. preferences. This saves users from manually calculating timezone offsets in their head.

I think this would be an excellent feature, and I've seen it in use already in platforms like Discord. Discord lacks any UI for the user to construct these though, instead hoping users just magically figure it out. This leads to sites like existing. But it would be nice to see clients providing a similar native UI.

What do you think? Have thoughts? Leave them on the MSC as a new pull request comment!

Dept of Servers 🏢

Synapse (website)

Synapse is a Matrix homeserver implementation developed by the core team

dmr says

This week we released Synapse 1.91, which contains

We are aware of a performance regression in this release which gradually consumes more CPU over time. We have just (within the last hour) begun to understand this and have a fix planned. We'll need to test this properly at the start of next week; you can expect a bugfix release shortly after, if all goes well.

The full changelog is available on GitHub. Thank you to our contributors for this release: Alexander Fechler, Gabriel Rodríguez, Nick Mills-Barret, Nico, Matthew Ma, Maximilian Bosch and Theodore Ni.

Aside from the release, this week we have been working on a few small bugfixes, which should make a nice addition to the upcoming 1.92 release.

In other news, for the last few releases Erik has been working to fix database corruption problems relating to room retention and purging historical events. He put out a call for testing in the Synapse Announcements room last Friday. It is not risk-free, but if anyone is feeling bold and is prepared to handle potential data loss, we would appreciate testing and feedback.

Finally, let me once thank our community of server operators in the room. It is an invaluable asset; we are indebted to everyone for all of your efforts and are extremely grateful.

Dept of Clients 📱

Benedict says

Just wanted to mention, that Konstantin Tskhovrebov created a really cool little Matrix messenger based on Trixnity. It is called smalk, uses Compose Multiplatform and already works on Desktop, Android and iOS with the same code base. Maybe web is coming soon too.

Neochat (website)

A client for matrix, the decentralized communication protocol

Tobias Fella says

This week, we've implemented a bunch of cool features:

  • You can now create matrix accounts directly in NeoChat. As part of the, the entire login UI has been revamped to a more modern look.
  • On the other end of an account's life cycle, we've also implemented deactivating accounts
  • You can now forward messages to a different room
  • The right sidebar has been improved for mobile devices

Apart from that, we're improving a lot of our code behind the scenes and preparing for the move to Qt6 (hopefully completed later this

Element X iOS (website)

A total rewrite of Element-iOS using the Matrix Rust SDK underneath and targeting devices running iOS 16+.

Ștefan says

Happy Friday everybody, ending another week that very much kept us on our toes:

Element X Android (website)

Android Matrix messenger application using the Matrix Rust Sdk and Jetpack Compose

benoit reports

  • Element X Android is not far from being released to production, but we want to fix the issue about notification without content first. This happens when the SDK cannot decrypt the Event content.
  • Polls are now enabled, you can create, vote and end polls, and they are correctly rendered in the timeline.
  • We have started to integrate Element Call to the application.
  • Still working on polishing OIDC and making progress on integrating the Rich Text Editor.
  • We are fixing lots of bugs, keep reporting bug reports, it’s really helpful!

Dept of SDKs and Frameworks 🧰

Trixnity (website)

Multiplatform Kotlin SDK for Matrix

Benedict announces

A small Trixnity release this week (v.3.10.4):


  • add default user agent "Trixnity"
  • allow subscribeAsFlow in SyncApiClients Subscribable


  • fix createRoomRepositoriesModule

matrix-rust-sdk (website)

Next-gen crypto-included SDK for developing Clients, Bots and Appservices; written in Rust with bindings for Node, Swift and WASM

Jonas Platte says

Over the last few weeks, we added

We also fixed lots of issues, including

… and improved our logging setup, as well as CI.

Dept of Services 🚀

matrix-docker-ansible-deploy (website)

Matrix server setup using Ansible and Docker

Slavi announces

Thanks to Aine of, matrix-docker-ansible-deploy can now set up the SchildiChat client.

See our Configuring SchildiChat documentation to get started.

Dept of Bots 🤖


Gwmngilfen announces

Historically, Ansible has relied on an old IRC bot called Zodbot to run our official chat meetings - take notes, log action items, and so forth, as well as posting the logs to a webhost for people to read later. With the IRC bridge currently down, we decided to dust off a 2-year-old action item to write a Matrix Meeting bot. Since (a) Zodbot is written in Python, and (b) I was already using Maubot for other things, it made sense to write it in the Maubot framework.

If you also have a need to a meeting Matrix, you might have a use for this! If so, you can check out the extremely hacky code on GitHub and deploy it to your own Maubot host in the usual way. By default the bot will post the meeting logs to the room when #endmeeting is called, but optionally (because this is useful to me) you can also post the logs to a Discourse instance instead. More backends for log handling are also planned.

Comments/feature requests/bug reports are of course very welcome!

Dept of Events and Talks 🗣️

Matrix User Meetup Berlin

saces says

This will be the last meetup before the matrix community summit, a good opportunity to test your [m]atrix outfit.

Next Matrix user meetup 6.9.2023, 8 pm @ c-base

Meet other matrix users, chat about Matrix, the rest, and everything else, discuss your Matrix ideas, sign each other in persona, and maybe spice the evening with a good mate or beer.

Also when the bbq is lit you may wish you brougth your favorite item :)

Every first Wednesday of the month in the c-base at 8pm ('til the next pandemic).

Matrix room:

Matrix Community Summit 2023 (website)

HarHarLinks reports

The Matrix Community Summit 2023 🗻 is taking place September 21st through September 24th at the awesome hacker space station c-base in Berlin!

News: The schedule had a slight adjustment to fix times being shown later than intended. The talks on Friday and Saturday start at 10:00 AM (CEST). The schedule has also been updated to include the breakfast, lunch break, dinner, and social events.

If your talk was accepted and you are participating as a speaker, please do still get a ticket!

The range of available T-Shirts has been extended! There are now 4 variants for you to choose from (or get them all!). If you already bought a ticket that includes a free T-shirt, you should be able to switch your choice to any of the new ones, in case you prefer them.


  • 📆 We updated the schedule from last week to show sessions in Berlin local time properly and also include breaks and meals. View it online here or import to your schedule consuming apps.
  • 🎫 Tickets are available! We are counting on Matrix businesses and professionals to buy our supporter tickets or sponsoring packages so we can provide everyone with food and drinks.
  • 👕 T-Shirts available for preordering, including new additional variants!
  • 🗨️ Join the event space for all related rooms including news and general discussion, etc.
    • 🚗🏨 Carpools and Roomshares if you're looking for how to travel or where to sleep.
    • 💪 If you can and want to help out with the event organisation, join the orga room!
  • 🗣️ The call for participation ended last Sunday, August 20th, however if you missed it until now and just came up with the greatest new idea, don't hesitate to contact us at Matrix Community Summit Orga and we will see how we can squeeze you in.

See you soon in Berlin!

Dept of Ping

Here we reveal, rank, and applaud the homeservers with the lowest ping, as measured by pingbot, a maubot that you can host on your own server.

Join to experience the fun live, and to find out how to add YOUR server to the game.

RankHostnameMedian MS

Join to experience the fun live, and to find out how to add YOUR server to the game.

RankHostnameMedian MS

That's all I know

See you next week, and be sure to stop by with your updates!

This Week in Matrix 2023-08-25

25.08.2023 00:00 — This Week in Matrix Hubert Chathi

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

MSC Status

New MSCs:

MSCs in Final Comment Period:

  • No MSCs are in FCP.

Accepted MSCs:

Merged MSCs:

Matrix 1.8 is here!

If you haven't yet seen the blog post, check it out. Room version 11 is new in this release, and we've already got an idea for what Matrix 1.9 looks like :)

New MSCs in detail

In this new segment, we aim to give a bit more context as to why an MSC was opened, beyond what is available in the MSC's introduction.

MSC4049 is highly experimental investigative work into what it would take to support making messages as appearing to be sent by a room or server instead of a user. There are some use cases highlighted in the MSC itself, but the primary driving factor is a point of relatively minor feedback from the MIMI working group: "does sender really need to be a user ID?". The spike-shaped experiment overlaps heavily with both crypto IDs and pseudo IDs by accident, but might help inform those two projects via MSC4047 and MSC4046. Currently there is not a plan to push any of the 3 MSCs towards FCP, though feedback is very much welcome on how the stack feels.

MSC4048 is part of the crypto team's mission to improve encryption across all of Matrix, with this particular MSC looking to improve the trustworthiness of key backups. Watch this space for updates as the MSC progresses, and please provide feedback on the proposal itself.

Dept of Servers 🏢

Synapse (website)

Synapse is a Matrix homeserver implementation developed by the core team

Shay announces

This week we released 1.91.0rc1. Highlights include:

  • Implements an admin API to lock an user without deactivating them. Based on MSC3939
  • Fix performance of state resolutions for large, old rooms that did not have the full auth chain persisted
  • Fix a bug introduced in 1.87 where synapse would send an excessive amount of federation requests to servers which have been offline for a long time
  • Allow customising the IdP display name, icon, and brand for SAML and CAS providers (in addition to OIDC provider)

and much more. If you'd like to take a deep dive into the changes, you can find the release notes here and as always, if you encounter a bug feel free to report it at

Dendrite (website)

Second generation Matrix homeserver

Devon Dmytro announces

This week we released v0.13.2. Here are a few of the highlights:


  • Further improvements and fixes for MSC4014: Pseudonymous Identities
  • Space summaries (MSC2946) have been moved from MSC to being natively supported
  • The default room version to use when creating rooms can now be configured using room_server.default_room_version


  • Migrations in SQLite are now prepared on the correct context (transaction or database)
  • Event size checks are more in line with Synapse
  • Getting local members to notify has been optimized, which should significantly reduce memory allocation and cache usage
  • Background federated joins should now be fixed and not timeout after a short time
  • Database connections are now correctly re-used

...and a whole lot more. Check out the release notes for the full set of changes! As always, feel free to stop by to join in on the discussion and if you encounter a bug make sure to report it here.

Dept of Clients 📱

Neochat (website)

A client for matrix, the decentralized communication protocol

Carl Schwan announces

This week we released a new major version for NeoChat as part of the KDE Gear 23.08 release. This will be likely the last version using Qt5.

NeoChat received a full visual overhaul of its user interface, which should make it looks a lot cleaner. The timeline bubbles use nicer shadows, we revamped the room list style and improved the notification images to display both the user and the room avatar at the same time. Read markers from the other participants in the room will be displayed in the timeline. The right sidebar which displays the list of participants and the room information now has a special look for direct chats and the whole sidebar is scrollable now instead of just the participants list.

Apart from a visual overhaul, NeoChat can now display location events and also a map with the location of all the users currently broadcasting their location using Itinerary's Matrix integration. Great for locating where your friends are.

We also made it possible to send stickers and the existing custom emoji editor now lets you add new custom stickers too. Finally, we improved our development tools, which allow users to inspect the state of a room and fixed a lot of stability issues all other the place.

Ement.el (website)

Matrix client for Emacs

alphapapa reports

Ement.el, a Matrix client for the GNU Emacs text editor and Lisp environment, has been released at v0.11. Changes since the last version include:


  • Commands ement-room-image-show and ement-room-image-scale (bound to RET and M-RET when point is at an image) view and scale images. (Thanks to Steven Allen for these and other image-related improvements.)
  • Command ement-room-image-show-mouse is used to show an image with the mouse.


  • Enable image-mode when showing images in a new buffer. (Thanks to Steven Allen.)
  • Command ement-room-image-show is not used for mouse events.
  • Show useful message in SSO login page.


  • Allow editing of already-edited events.
  • Push rules' actions may be listed in any order. (Fixes compatibility with v1.7 of the spec. Thanks to Steven Allen.)
  • Call external browser for SSO login page. (JavaScript is usually required, which EWW doesn't support, and loading the page twice seems to change state on the server that causes the SSO login to fail, so it's best to load the page in the external browser directly).
  • Clean up SSO server process after two minutes in case SSO login fails.
  • Don't stop syncing if an error is signaled while sending a notification.
  • Command ement-room-list-next-unread could enter an infinite loop. (Thanks to Visuwesh and
  • Events in notifications buffer could appear out-of-order. (#191. Thanks to Phil Sainty.)


  • The ement-read-receipt-idle-timer could be duplicated when using multiple sessions. (#196. Thanks to Phil Sainty.)

Feel free to join us in the chat room:!

Element X iOS (website)

A total rewrite of Element-iOS using the Matrix Rust SDK underneath and targeting devices running iOS 16+.

Ștefan reports

  • This week we continued our foray into OIDC and we’re making very good progress, it won’t be long now
  • There’s a brand new user-defined notification settings screen 👏
  • We also built the underlying structure for what’s going to become mention pills
  • Deep dove into startup performance and made sure that the rooms load in 0.1 shakes of a lamb's tail
  • plus tackled a significant number of bugs, developer experience improvements and testing additions

Element X Android (website)

Android Matrix messenger application using the Matrix Rust Sdk and Jetpack Compose

benoit announces

  • OIDC has been integrated into Element X Android. Users using a compatible server should be able to sign in using this solution. You can test it using the latest nightly build.
  • In the meantime we are still stabilising the application
  • Work on polls has made big steps, as well as integrating the Rich Text Editor.
  • Coming soon: Account setup screen, displayed the first time the user signs in to an account, since the very first sync performed by the sliding sync proxy may still take time for big accounts.
  • Regarding the release, we will make an update of the open testing version, and move it to production in the coming days if we’re happy with it.

Element Web/Desktop (website)

Secure and independent communication, connected via Matrix. Come talk with us in!

Johannes Marbach says

  • Progress on stuck notifications, sadly, slowed down a little this week as we've been busy with maintenance and infrastructure issues.
  • Our work around using Compound components in the room header continues. We've finished up the avatar component changes and dealt with some of the expected / unexpected fallout from making app-wide changes.
  • Finally, we also proceeded moving from Weblate to Localazy for our translations. We've reduced the number of source strings by using built-ins for language names and similar things and started realising string reuse with the Element X mobile apps.

Dept of Non Chat Clients 🎛️

KDE Itinerary

Carl Schwan reports

KDE Itinerary is a digital travel assistant that protects your privacy. It makes collecting all the information about your travel inside a single application easy and straightforward. KDE Itinerary is available for Plasma Mobile and Android. We release Itinerary at the same time as NeoChat, and in this release, apart of the integration of many more transport providers, it lets you connect your Matrix account with Itinerary to share your live location inside a Matrix room based on the on-board APIs from your train or flight.

Itinerary broadcasts the position, as specified in the relevant MSCs, and extends it with the direction the user is headed towards.

About this release: More information about Itinerary:

Dept of SDKs and Frameworks 🧰

Trixnity (website)

Multiplatform Kotlin SDK for Matrix

Benedict reports

Trixnity v3.10.3 has been released with some minor improvements and a fix of a long standing (March 2023) bug.


  • move [Event] extensions from trixnity-client to trixnity-core
  • server discovery fallback when no .well-known exists


  • fix wrong check of mac in sas verification (failed, when other client accepts emojis first)

Dept of Ops 🛠

matrix-docker-ansible-deploy (website)

Matrix server setup using Ansible and Docker

Slavi reports

Thanks to Johan Swetzén's efforts (who finished what was started by James Reilly and Shreyas Ajjarapu), matrix-docker-ansible-deploy now supports bridging to Android SMS and Apple iMessage via the mautrix-wsproxy service (in combination with a mautrix-imessage bridge running on your Mac or Android phone).

See our Setting up Mautrix wsproxy for bridging Android SMS or Apple iMessage documentation page for getting started.

Dept of Services 🚀 (website)

Your matrix server on your conditions

Slavi reports

TLDR: Bring-your-own-server orders on no longer incur a one-time setup fee ($50) as part of a pricing change experiment, thus making Matrix hosting with us more accessible and encouraging more people to host on their own server. Additional details are below.

At, we're working on a new ordering form, new services and pricing changes to match. We're always trying to cut down costs and to make prices more fair - smaller/simpler setups costing less, while orders with many components (requiring more work to setup and to support) having a higher cost.

At the same time, we're working on automating more of the order-handling flow and of server maintenance, so that we can keep costs low for everyone.

While all these changes are still being worked on (coming soon!), we'd like to announce another change - the experimental removal of the $50 one-time setup fee that we used to charge for Bring-your-own-server orders. With this fee removed, we're aiming to encourage more people to try Matrix on their own server (on-premise or rented from any provider in any location), as opposed to renting Hetzner Cloud servers out through us via our Turnkey offering.

While our Turnkey offering (optionally combined with hosting on a domain of ours like or is still the easiest way to get started, we'd like to promote our more-independent and vendor-lock-in-free Bring-your-own-server offering more.

Bring-your-own-server orders are more difficult/costly for us to process compared to hosting Turnkey servers that we are in complete control of, so removing the one-time setup fee may come back to bite us through an influx of many and difficult to process orders. For now, we've decided to take this risk and see how it goes. If you've been wishing to host Matrix via but this fee was holding you back, now is your chance!

Dept of Bots 🤖

Dominik reports

MatrixJoinLink is bot that allows the creation of invite links to non-public rooms in matrix.

Two weeks ago, I've mentioned the bot the first time in TWIM. Since then, I've made several improvements regarding UX. Now I'm happy to announce the next (probably interesting) version of the bot has been released (Release 0.10.0). Additionally, I've added more pictures of the workflow & technical details to the README of the project; so take a look at it if you like :)

The most important change is the new link command and more detailed error responses to the users (e.g., if permissions are missing). It was not that easy to create an invite link for a space without using development tools in Element to send messages in the space room itself. Thus, I've extended the link command of the bot: You can now send a message like !join link !internal.roomId A fancy link name in order to create an invite link to the room with the mentioned internal id (actually, a link will also work as long as it contains the internal id of the room).

So, feel free to test the bot and raise any issue using GitHub or using the development room that is mentioned in the project's README.

Dept of Events and Talks 🗣️

Matrix Community Summit 2023

HarHarLinks reports

The Matrix Community Summit 2023 🗻 is taking place September 21st through September 24th (in 4 weeks!!!) at the awesome hacker space station c-base! That time seems to be approaching quite fast, so we just published the first version of the schedule which you can view online here or import to your schedule consuming apps.

Join the event space for all related rooms including news and general discussion, car pools and room shares, etc. If you can and want to help out with the event organisation, join the Matrix Community Summit Orga!

Tickets 🎫 are now available! In order to be able to provide food and drinks for everyone during the whole event, we are counting on Matrix businesses and professionals to buy our supporter tickets. Specific sponsoring packages are also available. Beyond that, we are looking for a "Media Sponsor" to step up, which would enable us to produce media coverage of the event.

Similar to last year, T-Shirts 👕 commemorating the event will be available again and you can already pre-order them with your tickets, with more details following soon.

The call for participation 🗣️ ended last Sunday (August 20th), however if you missed it until now and just came up with the greatest new idea, don't hesitate to contact us at Matrix Community Summit Orga and we will see how we can squeeze you in.

See you soon in Berlin!

That's all I know

See you next week, and be sure to stop by with your updates!

Matrix v1.8 release

23.08.2023 16:25 — Releases Travis Ralston

Hey all,

Matrix 1.8 is out now! The last release, Matrix 1.7, was full of features and laid out a plan for what Matrix 1.8 was expected to become. We spent most of our time focusing on the MSC3995-related MSCs from that original plan, but made an effort to get the other stuff looked at as well.

With this release we see a total of 9 MSCs achieve their formally adopted status. The full changelog at the bottom has all the details, but please read on for what’s new in room version 11, and Matrix 1.9’s roadmap :)

Room version 11

Matrix 1.8 features a new room version! Normally a room version wouldn’t have a particular theme, but for v11 we aimed to clean up the different algorithms and event format details. After 10 prior room versions there were some artifacts of the past sticking around (but not causing problems necessarily) - many of them are cleaned up here.

Specified originally as MSC3820, v11 introduces the following changes:

  • MSC2174 - Move redacts to the content of events.
  • MSC2175 - Remove creator from events (use sender instead).
  • MSC3989 - Remove origin from events.
  • MSC2176, MSC3821 - General updates to redaction algorithm.

Alongside being a cleanup room version, v11 is the initial base we used for our efforts in the IETF world. It provides an easier starting point for new server implementations, particularly when paired with Linearized Matrix (described as both an IETF Internet-Draft and MSC3995).

In future room versions the cleanup effort will continue, alongside additional features for supporting the IETF use cases. Watch this space for updates.

Upcoming in Matrix 1.9

We’re continuing the trend of planning ahead and have the following themes planned for work in Matrix 1.9:

  • Anything required by the MIMI/IETF efforts we’re undertaking. This currently includes:
    • Extensible Events
    • Role-Based Access Control (RBAC; new MSC expected)
    • Next generation of Linearized Matrix (already)
    • MSC4044 and MSC4045
    • Binary-encoded events (maybe, but probable)
    • Canonical DMs (maybe)
    • Sending events as rooms/servers instead of just users (maybe)
    • Further room version cleanup as needed
  • Merging MSC3939.
  • Accepting a combination of MSC2545, MSC1951, MSC3892, and MSC4027. This may involve creating a new MSC to cover the functionality of each, plus the needful for IETF and Extensible Events efforts.
  • Merging MSC3391 (time permitting).

A lot of this stuff might take the shape of opening MSCs or thinking about the problems, but we’re also very optimistic about getting them through FCP before November 2023. Watch this space for updates :)

The full changelog

There’s so many more things than what we covered in this blog post - flip through the changelog below for a full idea of what’s landed.

Client-Server API

Backwards Compatible Changes

  • Require callers to be joined to the room to report its events, as per MSC2249. (#1517)

Spec Clarifications

  • Fix missing type property in the JSON schema definition of the m.reaction event. Contributed by @chebureki. (#1552)
  • Make sure examples types match schema in definitions. (#1563)
  • Allow null in room_types in POST /publicRooms endpoints schemas. (#1564)
  • Fix broken header formatting. Contributed by @midnightveil. (#1578)
  • Render binary request and response bodies. (#1579)
  • Fix description of MAC calculation in SAS verification. (#1590)
  • Update link to SAS emoji definition data. (#1593)
  • Fix various typos throughout the specification. (#1597)

Server-Server API


  • Deprecate matrix SRV lookup steps during server discovery, as per MSC4040. (#1624)

Backwards Compatible Changes

  • Add matrix-fed SRV lookup steps to server discovery, as per MSC4040. (#1624)

Spec Clarifications

  • Document why /state_ids can respond with a 404. (#1521)
  • Fix response definition for POST /_matrix/federation/v1/user/keys/claim. (#1559)
  • Fix examples in server keys definition. (#1560)
  • Make sure examples types match schema in definitions. (#1563)
  • Allow null in room_types in POST /publicRooms endpoints schemas. (#1564)
  • Fix broken header formatting. Contributed by @midnightveil. (#1578)
  • Remove spurious mention of a "default port" with respect to SRV record lookup. (#1615)
  • Switch to ordered list for server name resolution steps. (#1623)

Application Service API

Spec Clarifications

  • Fix type of custom fields in thirdparty lookup queries. (#1584)

Identity Service API

Spec Clarifications

  • Make sure examples types match schema in definitions. (#1563)

Push Gateway API

No significant changes.

Room Versions

Backwards Compatible Changes

  • Add room version 11 as per MSC3820. (#1604)
  • Move redacts from top level to content on events in room version 11, as per MSC2174. (#1604)
  • Remove creator from events in room version 11, as per MSC2175. (#1604)
  • Remove remaining usage of origin from events in room version 11, as per MSC3989. (#1604)
  • Update the redaction rules in room version 11, as per MSC2176 and MSC3821. (#1604)


Backwards Compatible Changes

Spec Clarifications

  • Clarify spec re canonical JSON to handle negative-zero; also, give an example of negative-zero and a large power of ten. (#1573)

Internal Changes/Tooling

Backwards Compatible Changes

  • Upgrade Swagger data to OpenAPI 3.1. (#1310)
  • Create @matrix-org/spec npm package to ship the SAS Emoji data definitions & translations. (#1620)

Spec Clarifications

  • Update the CI to validate the file extension of changelog entries. (#1542)
  • Disclosure sections now only display their title when collapsed. (#1549)
  • Fix the sidebar in recent versions of Hugo. (#1551)
  • Bump jsonschema to validate JSON Schemas against Draft 2020-12. (#1556)
  • Use Redocly CLI to validate OpenAPI definitions. (#1558)
  • Use tag name as the OpenAPI definition version. (#1561)
  • Make sure version in x-changedInMatrixVersion is a string. (#1562)
  • Clarify usage of ABNF for grammar in the documentation style guide. (#1582)
  • Remove unnecessary oneOfs in JSON schemas. (#1585)
  • Update the version of Hugo used to render the spec to v0.113.0. (#1591)
  • Fix rendered changelog with new version of towncrier. (#1598)
  • Improve the layout of tables on desktop displays. Contributed by Martin Fischer. (#1601)