🔗Dept of Status of Matrix 🌡️

Thib (m.org) announces

FOSDEM was a huge success for the Matrix.org Foundation and community this year again!

• 🍕60 pizzas and an uncountable amount of drinks at the Fringe event
• 👕 100 t-shirts sold at the booth on the first day!!
• 🧑‍🏫 A completely packed devroom
• 🤝 Many great conversations at the booth

Shout out to Workadventure, Nordeck and Famedly who sponsored the Fringe Event and kept us refreshed and fed. And a huge thanks to everybody who showed up at the booth either to staff it or to say a kind word, bring constructive criticism, or have a casual conversation.

A more detailed wrap up post will be published this week. In the meantime, I’m leaving FOSDEM with a sense that we are doing the right thing, going in the right direction, and that people notice. I'm looking forward to meeting you all again, as well as those who couldn't make it to FOSDEM!

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

• MSC4260: Reporting users (Client-Server API)
• MSC4259: Bulk Profile Sync API for Federation
• MSC4258: Federated User Directory
• MSC4257: Profiles Arent Auth: Move profile contents to a separate event
• MSC4256: RFC 9420 MLS mode Matrix

MSCs in Final Comment Period:

• No MSCs are in FCP.

Accepted MSCs:

• MSC4239: Room version 11 as the default room version
• MSC4133: Extending User Profile API with Key:Value Pairs

Closed MSCs:

• No MSCs were closed/rejected this week.

🔗Spec Updates

Many of the SCT members are at FOSDEM this weekend to talk to folks about Matrix, so won't be doing too much MSC review, but we've still got the next-gen auth MSCs at the highest priority for review once everyone is back!

We're also looking to cut a release of the spec soon, possibly in February, with as many Matrix 2.0 features as possible - if there's an MSC you think should be in this release, let us know in the #sct-office:matrix.org room on Matrix :)

🔗Dept of Servers 🏢

🔗Synapse (website)

Synapse is a Matrix homeserver implementation developed by Element

Devon Dmytro says

This week we released Synapse v1.123.0.

This release adds the following new features:

• Implement MSC4133 for custom profile fields. Contributed by @clokep. (#17488)
• Add a query parameter type to the Room State Admin API that filters the state event. (#18035)
• Support the new /auth_metadata endpoint defined in MSC2965 (OAuth 2.0 Authorization Server Metadata discovery). (#18093)

... and a whole lot more!

Thank you to all our contributors for helping to make Synapse the best it can be. As always, feel free to stop by #synapse:matrix.org to join in on the discussion and if you encounter a bug make sure to report it here.

🔗Dept of Clients 📱

🔗Element X iOS (website)

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

Mauro Romito says

• Knocking, alongside security and privacy settings work is almost completed, recently a testing session was done, where we determined that the features work well, and require only some small polishing before release
• Media gallery also received a lot of improvements and updates and is being closer to get completed
• Today we release our first RC with calendar versioning, which will soon become the new standard for marking releases
• Some small design improvements were made for the DM Details view
• Alongside some improvements for the macOS version

🔗Element X Android (website)

Android Matrix messenger application using the Matrix Rust SDK and Jetpack Compose.

benoit reports

• Knocking, alongside security and privacy settings work is almost completed, recently a testing session was done, where we determined that the features work well, and require only some small polishing before release (yes, I have shamefully copied what Mauro said about EXI 🙈)
• It will be possible to swipe between media when open from the timeline in the next release. Previously it was only possible to scipe when the media was opened from the gallery.
• Next release will be versioned using calendar versioning, so that it will be easier to know the release date and also how old is a particular release just by knowing its version. Also iOS and Android will share the same version!

🔗Tammy (website)

Multiplatform messengers build on top of Trixnity Messenger

Benedict reports

Tammy just got a new release! This update brings speed boosts, fresh features, and tons of fixes to make your messaging experience smoother than ever.

✨ What’s New?

• Typing indicators in the room list – see who’s responding in real time!
• A sleek new image details view for a better media experience.
• Send attachments with Enter for quicker sharing on Desktop.
• Under-the-hood improvements to make Tammy even faster and more reliable.

⚠️ Heads-up! We had to change the database, so you’ll need to log in again. Should we ever have more Tammy users and this happens again, we will do an automatic migration. It's just not worth it at the moment.

Checkout the new Tammy version at https://tammy.connect2x.de and give us feedback in https://matrix.to/#/#tammy:imbitbu.de 🚀

🔗Dept of VoIP 🤙

🔗Element call on Room Kit (Cisco) devices

Emma [it/its] reports

You may or may not have seen my demo at FOSDEM last saturday. In short, I've been working with Robert on integrating Element Call into the closed garden ecosystem of Cisco's meeting devices. This gives businesses and government agencies a migration flow to Matrix, without having to spend a large amount of money on new hardware - by meeting them where they are at.

In the current state of things, we're able to join a call, but dont yet have any interface for interacting with the call once it's running, but it's a great start!

If you're interested, join us in #roomos-matrixrtc:rory.gay, though we do hang out in #webrtc:matrix.org quite regularly aswell!

Today's Matrix Live: https://youtube.com/watch?v=HvdKdjZZLyU

🔗Dept of SDKs and Frameworks 🧰

🔗Trixnity (website)

Multiplatform Kotlin SDK for developing Clients, Bots, Appservices and Servers

Benedict reports

A new version of Trixnity is out! The release brings massive performance enhancements to Trixnity, significantly improving sync processing efficiency. Processing times have been boosted by up to 5x, while RAM usage has been slashed by the same factor. These improvements were achieved by optimizing how the cache interacts with the local database—bypassing the cache entirely when no listeners are active. On top of this, the cache now supports rollbacks, which helps maintain consistency between the cache and the database, even in edge cases.

A noteworthy change in this release is the removal of support for the Realm database. As Realm-Kotlin is no longer actively maintained or compatible with the latest Kotlin versions, we’ve decided to discontinue its support. However, there’s good news! The Androidx Room database implementation has been fixed and is now a solid alternative for those seeking a reliable, cross-platform database solution.

In addition to these major updates, the release includes several smaller but impactful improvements and bug fixes. For example, refresh token support has been added. Be sure to check out the full changelog for all the details.

🔗Dept of Bots 🤖

🔗Draupnir (website)

A moderation bot for open Matrix communities

Gnuxie 💜🐝 announces

We have released Draupnir v2.1.0 with some bug fixes in the wake of the v2.0.2 release:

• Some moderators noticed that on upgrading from v1.87.0 to v2.0.* some rooms would appear unprotected. It later turned out that the functionality for the config option protectAllJoinedRooms was missing from this release. We've now fixed this and also updated the !draupnir rooms command to show which rooms Draupnir is and isn't protecting. Your rooms should be automatically protected again on upgrading to v2.1.0.

• The config option commands.allowNoPrefix has been fixed again. Some commands would interact badly with the setting in the v2.0.* releases, this has now been fixed.

• Functionality has been added in conjunction with protectAllJoinedRooms to automatically unprotect rooms that it has been kicked from and notify the management room.

A couple other issues have been fixed around Draupnir startup time, and manually entering safe mode, so checkout the CHANGELOG if you are interested in those. As always you can find us in #draupnir:matrix.org. Thank you to everyone who has been promptly reporting bugs and making these fixes possible <3

🔗Dept of Events and Talks 🗣️

🔗Matrix User Meetup Berlin

saces says

Next Matrix user meetup 4.2.2025, 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: #mumb:c-base.org

🔗Dept of Guides 🧭

🔗Matrix Spec for Dash & Zeal: Looking for help

Christian Paul (jaller94) announces

Hi everyone, for the past 2.5 years I've submitted new versions of the Matrix Spec to Dash and Zeal. Dash is a documentation browser which works offline. Zeal is an open source browser supporting the same docset format.

The Matrix Spec is built with Hugo and in v1.13 the Hugo config changed enough to break my build script. Currently, I'm unable to release new docsets as these require relative URLs in all HTML files.

Is anyone using this docset? Can someone help to maintain this or figure out the changes needed for v1.13?

https://github.com/matrix-org/matrix-spec/issues/583#issuecomment-2615430745

🔗Matrix Federation Stats

Aine [don't DM] announces

collected by MatrixRooms.info - an MRS instance by etke.cc

As of today, 10438 Matrix federateable servers have been discovered by matrixrooms.info, 3094 (29.6%) of them are publishing their rooms directory over federation. The published directories contain 22196 rooms.

Stats timeline is available on MatrixRooms.info/stats

How to add your server | How to remove your server

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

🔗#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	codestorm.net	252.5
2	bi-vibes.com	262.5
3	nerdhouse.io	353
4	littlevortex.net	402
5	tomfos.tr	517.5
6	mtest.eyer.life	521
7	flauschwelle.de	545
8	lewd.social	546
9	rom4nik.pl	598

🔗That's all I know

See you next week, and be sure to stop by #twim:matrix.org with your updates!

To learn more about how to prepare an entry for TWIM check out the TWIM guide.

🔗Matrix Live

Today's Matrix Live: https://youtube.com/watch?v=RvVC0wNgNC0

🔗Dept of Events and Talks 🗣️

🔗Matrix@FOSDEM 2025

As a reminder Matrix will again be present at FOSDEM this year!

As always, FOSDEM is free to attend and will happen at the 1. and 2. of February. Additionally we will have a fringe event on the 31st of January. You can find more information in the "Matrix in full force at FOSDEM" blog post.

Additionally please be aware that the Health and Safety Policy for the fringe event will be the same as the one of the Matrix Conference. Extremely briefly: You need to wear a mask while indoors, except while eating and drinking.

🔗Dept of Spec 📜

Andrew Morgan (anoa) {he/him} reports

Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.

🔗MSC Status

New MSCs:

• MSC4253: Modifying or rejecting accepted MSCs
• MSC4252: Extensible Events modification: State event handling
• MSC4250: Authenticated media v2 (Cookie authentication for Client-Server API)

MSCs in Final Comment Period:

• MSC4213: Remove server_name parameter from join and knock endpoints (merge)

Accepted MSCs:

• No MSCs were accepted this week.

MSCs in Proposed Final Comment Period:

• MSC4133: Extending User Profile API with Key:Value Pairs
• MSC3765: Rich text in room topics
• MSC3266: Room summary API
• MSC4239: Room version 11 as the default room version
• MSC3757: Restricting who can overwrite a state event
• MSC4183: Additional Error Codes for submitToken endpoint

Closed MSCs:

• MSC3575: Sliding Sync (aka Sync v3)
  • Superseded by MSC4186: Simplified Sliding Sync
• [WIP] MSC4097: Interactions between media redirection and authentication
  • Replaced by spec-independent approaches.

🔗Spec Updates

As suggested from folks in the TWIM room, the above status now contains MSCs that are currently in proposed Final Comment Period. The hope is that this directs attention to MSCs that are close to being either merged/closed.

Let me know what you think!

🔗Dept of Servers 🏢

🔗Synapse (website)

Synapse is a Matrix homeserver implementation developed by Element

Matthew announces

In Chapter 46 of Element’s neverending mission to persuade enormous Matrix deployments to contribute to Synapse and Matrix development costs, we’ve put out a blog post explaining precisely what Synapse Pro is, why it exists, and why if you base a huge national Matrix deployment on open source Synapse it will fail - https://element.io/blog/scaling-to-millions-of-users-requires-synapse-pro/

Andrew Morgan (anoa) {he/him} announces

This week the Element team released Synapse v1.122.0. Please note that the minimum required version of PostgreSQL is now 13 - upgrade your DB cluster if necessary!

Otherwise this release contains a number of nice additions to the module API and the Admin API. It also stabilises the implementation of MSC3823: Account Suspension.

The usual round of bug fixes and dependency upgrades are also present. Enjoy and thanks!

🔗matrix-media-repo (website)

Matrix media repository with multi-domain in mind.

TravisR announces

matrix-media-repo v1.3.8 is out now! This release is a security release with other bug fixes and features contained within. Operators are encouraged to update as soon as possible.

Highlights from the changelog are:

• Fix GHSA-rcxc-wjgw-579r / CVE-2024-56515
• Fix GHSA-gp86-q8hg-fpxj / CVE-2024-52791
• Fix GHSA-r6jg-jfv6-2fjv / CVE-2024-52602
• Guests are now able to upload media, as per MSC4189.
• Federated servers will have their Authorization headers parsed correctly now, giving them a higher chance at being able to download media.

If you run into issues upgrading, please visit #media-repo:t2bot.io on Matrix, or open issues in the issue tracker.

🔗Dendrite (website)

Second generation Matrix homeserver

Till announces

This week we released Dendrite 0.14.1! This is a security release with just one additional fix for loading server ACLs.

gomatrixserverlib, which is powering Dendrite, was vulnerable to server-side request forgery under certain conditions. CVE-2024-52594/GHSA-4ff6-858j-r822 has been fixed by implementing Allow and Deny lists for network requests.

Loading server ACLs on startup has seen a huge improvement, this is mostly noticeable on larger instances with many ACL'd rooms.

On the PR side of things: There is a work in progress PR, adding support for MSC3861 and the matrix-authentication-service which is quite exciting.

Like always, feel free to join us at #dendrite:matrix.org if you encounter any issues or for Dendrite-related discussions.

🔗Dept of Clients 📱

🔗gomuks android

tulir says

I made an Android wrapper for gomuks web using GeckoView to get push notifications. There are a bunch of other new features too, read https://mau.fi/blog/2025-01-mautrix-release/ for more info

🔗Fractal (website)

Matrix messaging app for GNOME written in Rust.

Kévin Commaille says

In this cold weather, we hope Fractal 10.rc will warm your hearts. Let’s celebrate this with our own awards ceremony:

• The most next-gen addition goes to… making Fractal OIDC aware. This ensures compatibility with the upcoming authentication changes for matrix.org.
• The most valuable fix goes to… showing consistently pills for users and rooms mentions in the right place instead of seemingly random places, getting rid of one of our oldest and most annoying bug.
• The most sensible improvement goes to… using the send queue for attachments, ensuring correct order of all messages and improving the visual feedback.
• The most underrated feature goes to… allowing to react to stickers, fixing a crash in the process.
• The most obvious tweak goes to… removing the “Open Direct Chat” menu entry from avatar menu and member profile in direct chats.
• The clearest enhancement goes to… labelling experimental versions in the room upgrade menu as such.

As usual, this release includes other improvements, fixes and new translations thanks to all our contributors, and our upstream projects.

It is available to install via Flathub Beta, see the instructions in our README.

As the version implies, it should be mostly stable and we expect to only include minor improvements until the release of Fractal 10.

If you are wondering what to do on a cold day, you can try to fix one of our newcomers issues. We are always looking for new contributors!

🔗Element X Android (website)

Android Matrix messenger application using the Matrix Rust SDK and Jetpack Compose.

benoit announces

Working on the media gallery. It will be possible to swipe between media (images and videos) when displaying media in full screen. For the first iteration, and because of technical - temporary - limitations, it will be possible only when coming from the gallery (navigate to Room settings / Media and files).

Also finalizing (?) the work on the Knock feature.

A technical note: there has been an update on how we configure the log of the SDK, it's now limited to setting a log level.

🔗Element Android (website)

Secure and independent communication for Android, connected via Matrix. Come talk with us in #element-android:matrix.org!

benoit announces

We are publishing a new release of Element Android (v1.6.28), that will advertise user to migrate to Element X if they want to create an account on a homeserver with MAS support. As a reminder, matrix.org will migrate to MAS in a near future. This is the first step of redirecting user to Element X, which will become the main client that Element will support on Android and iOS platforms.

Also, Element Android is now dual-licensed: AGPL-3.0 and commercial license.

🔗Dept of Widgets 🧩

🔗Miro to Matrix-Neoboard converter

MTRNord (they/them) announces

As a weekend project I wanted to solve the usecase we got at work where we develop Neoboard but mainly still use Miro for a lot of things. Hence, I wrote a tool to migrate :)

You can find it hosted at https://miro-export.neoboard.midnightthoughts.space/. Note that it requires you to be logged in to Miro to work, but then it allows also using urls.

You can also find the source code at https://gerrit.midnightthoughts.space/gitweb?p=neoboard-miro-converter.git;a=summary

🔗Catches/Gotchas

• Neoboard lacks feature compatibility
  • Arrows do not show up the same
  • Sticky notes don't have dedicated rendering
  • No border colors
• Miro API doesn't tell me the position of unattached lines -> Unable to export those

  

🔗Dept of SDKs and Frameworks 🧰

🔗Rory&::LibMatrix (website)

.NET 8 matrix bot/client library/SDK

Emma [it/its] says

I've been hard at work squashing compile warnings! Hopefully pushing those in a few days? User impact is not expected for those changes. Not worth a separate TWIM post: Fixed a bug in Rory&::MatrixUtils that caused some tools to crash when you have an invalid session logged in. Additionally: I hope you had a great new year!

🔗Changes

• Trim leading slashes out of well-known URIs. LibMatrix and anything that uses it (hello Rory&::MatrixUtils!) should now work more reliably for homeservers!
• Update dependencies, keeping us up to date with the latest bug fixes and security improvements.
• Allow building all parts of LibMatrix without depending on a local checkout of ArcaneLibs. This should help with packaging LibMatrix in NuGet/... in the future, making LibMatrix far more accessible for developers!

And, as always:

• The code is available at cgit.rory.gay (or Github - read only, may be outdated)!
  • All contributions are more than welcome, be it documentation, code, anything! Perhaps, example usecases, bots, ...?
• Discussion, suggestions and ideas are welcome in #libmatrix:rory.gay (Space: #mru-space:rory.gay)
• Got a cool project that you're working on and want to share, using LibMatrix? Be sure to let us know, we'd love to hear all about it!

🔗Matrix Rust SDK (2025-01-17) (website)

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

Jorge reports

First of all, we have some important updates about Sliding Sync vs Simplified Sliding Sync:

Sliding Sync exists in 2 MSC: 3575 and 4186 (aka Simplified Sliding Sync). As announced, after a period where both MSC were supported, it's time to “deprecate” MSC3575. Here is the PR that removes the support of MSC3575 in the SDK. The plan is to merge it next week.

Besides that, we kept working on the persistent event cache storage, and some other topics:

• The time when an event is added to the send queue is stored in some metadata so the send queue has a better understanding on how stale the event is. Thanks @zzorba! (#4385).
• A new RoomPrivacySettings helper was added through Room::privacy_settings to customise a room's aliases, join rules, visibility, etc. (#4401).
• We fixed a bug where we incorrectly discarded previous batch tokens when the persistent event cache storage is disabled, which caused some events to be missing while paginating (#4495).
• When a room is forgotten by the SDK, we now also clear all the events related to it from the event cache (#4521).
• Fixed a bug where UTD events where always added to any timeline unconditionally while syncing, including those that filter out events such as the pinned events timeline or the media one (#4525).
• Added a Room::own_membership_details function to get both the current user's room member details and the ones of the sender of that room member event. Also, the FFI RoomMember struct now also contains the optional reason for the membership change (#4529).
• We now handle redactions of redacted events (#4533).
• Fix a bug that caused the logs at the FFI layer to be way too verbose (#4542).

🔗Dept of Services 🚀

🔗etke.cc (website)

Your matrix server on your conditions

Aine [don't DM] reports

🔗Synapse Admin Updates

A while back, we at etke.cc announced our Synapse-Admin fork. This week, we’re excited to introduce a new feature and more bugfixes!

Account Data Tab for Users

You can finally see what's inside your users' account data! It is extremely handy for bots using account data as main data store

Respect base url when loading config.json

If you serve Synapse Admin under a subdir (e.g. example.com/admin), this one is for you! Previously Synapse Admin attempted to fetch config.json as-is, completely ignoring the base url you use

Respect other GET params when reading SSO login token

Previously, Synapse Admin extracted loginToken using regular expressions, and that didn't work well if you have any other GET params (like server). Well, the issue is no more!

Explore the source code or try the admin.etke.cc (CDN version). Don’t forget to join the discussion in #synapse-admin:etke.cc

🔗Dept of Bots 🤖

🔗Draupnir (website)

A moderation bot for open Matrix communities

Gnuxie 💜🐝 says

Draupnir 2.0 is finally out!

The 2.0-beta programme has concluded and the long-awaited Draupnir 2.0 is here, bringing substantial improvements to moderation for public Matrix rooms. This update reflects over a year of hard work and community feedback.

🔗A Milestone for Matrix moderation

This release marks a turning point for Draupnir, which has become an essential tool for moderators across Matrix's open communities. With the introduction of new features and optimizations, the bot is easier to use and more capable than ever.

The key improvements are:

• Intuitive Prompts: Routine tasks like protecting rooms or watching policy lists are now as simple as inviting the bot and clicking a reaction. Prompts in the management room replace many manual commands.
• Faster and Smarter: Draupnir now caches room state using a persistent revision system, significantly reducing the need to query homeservers. An optional room state backing store also cuts startup time dramatically.
• Resilient and Recoverable: The new Safe Mode feature can diagnose and recover from configuration problems by using the bot's familiar prompts and commands UI.
• Revamped Protections: The protections system has been overhauled, offering better hooks into room state, community membership, and policy changes. Protection settings and configurations are now also easier to manage.

In addition to hundreds of other fixes and smaller changes that add up to make a big difference. For full details, see the release notes. Thank you to everyone who contributed to Draupnir in any way to making this release possible, whether that was reporting an issue, feature request, or coming to talk in #draupnir:matrix.org.

🔗Matrix Federation Stats

Aine [don't DM] announces

collected by MatrixRooms.info - an MRS instance by etke.cc

As of today, 10589 Matrix federateable servers have been discovered by matrixrooms.info, 3152 (29.8%) of them are publishing their rooms directory over federation. The published directories contain 20436 rooms.

Stats timeline is available on MatrixRooms.info/stats

How to add your server | How to remove your server

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

🔗#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	nexy7574.uk	212
2	codestorm.net	234
3	synapse.rntpts.de	279
4	pissing.dev	283
5	matrix.sp-codes.de	363
6	girlboss.ceo	424
7	tomfos.tr	489
8	transgender.ing	559.5
9	matrix6.rainerzufall.click	678
10	melthecat.dev	740

🔗That's all I know

See you next week, and be sure to stop by #twim:matrix.org with your updates!

To learn more about how to prepare an entry for TWIM check out the TWIM guide.

Check also out the Office of the Governing Board if you want to get more involved in the Matrix community.

The Matrix.org homeserver will see changes related to authentication in Q1 2025. The team will turn off guest account access on Matrix.org on January 16th and roll out Matrix Authentication Service (MAS) to embrace Matrix 2.0 after February 10. Client developers need to ensure their clients support the required changes.

🔗What is MAS

Matrix Authentication Service is Matrix's next-generation authentication stack. It allows for more flexible authentication journeys without requiring client developers to support every one of them.

You can find all the technical details in Quentin's Matrix Conf talk, Harder Better Faster Stronger Authentication with OpenID Connect.

🔗What's the impact

Client developers need to ensure that their projects support the requirements listed on areweoidcyet.com and, more precisely, the requirements listed in MSC3824.

Developers can already use beta.matrix.org to see if their clients are compatible with MAS. If you notice anything that doesn't work as intended, make sure to give your feedback on those MSCs. If clients work on beta.matrix.org, they will be able to connect to matrix.org after the rollout.

Homeserver administrators from the public federation don't have to worry about this deployment. MAS only affects the APIs between the clients and the server, so this deployment only impacts clients connecting to matrix.org. Federation APIs, used for servers to talk to each other, remain unchanged.

🔗Disabling guest accounts

Guest accounts are a legacy Matrix feature that allows clients to create temporary, limited technical accounts to participate in specific rooms that allow it.

The Matrix.org Foundation would have liked to find an efficient way to let people create guest accounts when joining a conversation and then turn them into fully fledged accounts later. Nobody in the ecosystem found resources to design and implement such a user journey, and guest accounts ended up being used for technical reasons, like displaying room previews or badges via shields.io.

Those accounts make up a significant load on the matrix.org homeserver. For that reason, the Matrix.org Foundation has decided to disable them at least temporarily to save precious resources and go ahead with the rollout of the new authentication stack.

The Matrix.org Foundation is open to re-enabling guests accounts once it has the financial capacity to support them. If guest accounts on matrix.org are important to you and your business, please join the Matrix.org Foundation as a supporting member to contribute to its financial sustainability.

We encourage developers using guest access for room information, such as topics, aliases, or member counts, to utilize the endpoint proposed by MSC3266. This endpoint is publicly accessible without authentication and can serve as an alternative resource until guest access is reinstated in a more robust form.

We appreciate your understanding as we take these steps to enhance the user experience on Matrix.org.

🔗Dept of Status of Matrix 🌡️

Matthew reports

The 2024 Matrix Holiday Special: https://matrix.org/blog/2024/12/25/the-matrix-holiday-special-2024/

🔗Dept of Clients 📱

🔗SchildiChat (website)

SchildiChat is a fork of Element for Android and Desktop, that used to focus on UI changes such as message bubbles and a unified chat list, but now also provides some additional tweaks and community-driven features that may not be on the roadmap for the upstream clients.

SpiritCroc says

Over the holidays, I added two new (old) features to SchildiChat Next (our Element X Android fork) that I've been missing since switching to the new codebase.

First, inline images and custom emotes are now rendered again, so you don't miss out when users on other clients or certain bridges send these. If you prefer not having images rendered in text message, you can also disable them via a setting, in order to render the fallback text instead - rather than not rendering anything at all as done previously.

Second, I added back the functionality to fetch and render previews for links found in text messages, so you have a better idea what to expect before clicking them. For now, this is an experimental setting, so remember to enable it first if you want to try it out once it lands in the next release.

🔗Neochat (website)

A client for matrix, the decentralized communication protocol

Tobias Fella says

This week, Kai Uwe has worked on improving the notifications showing the progress of a file upload or download.

James has continued to bring thread support to neochat, this time by making it possible to reply to an existing thread.

Carl has created new UI for various right-click menus that shows up as a drawer when using NeoChat on a mobile device.

🔗Fractal (website)

Matrix messaging app for GNOME written in Rust.

Kévin Commaille announces

🎶 Vive le vent ! Vive le vent ! Vive le vent d’hiver ! 🌲 And vive Fractal 10.beta! While everyone is resting for the holidays, we thought you could use a new release. It focuses on improvements and bug fixes, including:

• Videos were often not playing after loading in the room history, this was fixed, and we also show properly when an error occurred.
• Computing the size of media messages was slightly wrong, which meant that sometimes a grey line would appear below them. We rebooted the code and that problem is gone!
• Our CSS file was a bit too big for our taste, so we decided to make use of SASS and split it.
• We were downloading too many different sizes for avatar images, which would fill the media cache needlessly. We now only download a couple of sizes. This has the extra benefit of fixing blurry or missing thumbnails in notifications.

As usual, this release includes other improvements, fixes and new translations thanks to all our contributors, and our upstream projects.

It is available to install via Flathub Beta, see the instructions in our README.

As the version implies, there might be a slight risk of regressions, but it should be mostly stable. If all goes well the next step is the release candidate!

If you have a little bit of time on your hands, you can try to fix one of our newcomers issues. Anyone can make Fractal better!

🔗Dept of SDKs and Frameworks 🧰

🔗libQuotient (website)

A Qt5 library to write cross-platform clients for Matrix

kitsune announces

🔗libQuotient 0.9.2

While working on the next Quaternion beta (sorry to those waiting - the holiday present is not coming this year), the number of improvements in libQuotient reached a point where it's worth making a new maintenance release - so here it is. Aside from, also long awaited, initial threads support in the library (thanks to NeoChat's nvrwhere) it's fixes and cleanup over the place. The notes and the Git tag are at the usual place. Happy New Year everyone!

🔗Dept of Events and Talks 🗣️

🔗Matrix Salon Podcast: Fabian about Alertrix (German episode)

Christian Paul (jaller94) announces

Meet Fabian, who develops Alertrix. This customised chat is going to help firefighters coordinate their emergency responses. It's currently funded by the German Prototype Fund and Fabian gave a presentation at the Matrix Conference where we also recorded this episode. You can find the community room at https://matrix.to/#/#community:alertrix.net.

• RSS feed: https://anchor.fm/s/cdb34188/podcast/rss
• Episode on Spotify: https://open.spotify.com/episode/7GI3ek9chZr3VYhMCC0TIs?si=JUoNg1XjRbCB3SFeLdgmdg
• Mastodon post: https://mastodontech.de/@jaller94/113726065155521630

This marks the 20th episode of the podcast and the end of the current backlog. 🥳 Message me your suggestions for which community members you'd like to see featured in 2025.

🔗38C3

HarHarLinks announces

Dear TWIM, I'm writing you from the train back home after having visited 38C3 in Hamburg, the 38th edition of Chaos Communication Congress by the German Chaos Computer Club. Like yesteryear, #community-events:matrix.org organised the matrix community assembly there; you can imagine it as a kind of crossover of the Matrix #fosdem-2025-barcamp:matrix.org booth and a workshop area. We offered some "office hours" for people but many also dropped by around the clock with their questions, to get some of the official Matrix.org hoodies or T-shirts we could offer (thanks Thib for making this possible!), or simply to celebrate and socialise. We had a small assembly project driven by Nico who brought the materials to build an LED cube which once set up visitors could control through Matrix chat commands. As a small game, we hid small plastic rabbits around the whole congress center, which attendees could find and bring back to us to receive our wonderful assembly badge designed by Nadine. We also offered 2 workshops, one being another instance of Tune Your Chat, a project to collect all the neat small tips and tricks to tweak your Matrix experience, and for the other we were joined for a discussion by the creators of the "Standardised Messenger Audit – Frontend" catalog from the office of the German Federal Commissioner for Data Protection and Freedom of Information, published earlier this year. And of course we also took another group photo! If you are interested in joining us next time or for one of the many events we visit in the meantime, you can join #chaosevents:matrix.org specifically for appearances at CCC events or #community-events:matrix.org for even more.

Happy new year and see you at #fosdem-2025-barcamp:matrix.org!

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

🔗#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	codestorm.net	229.5
2	ncat.cafe	301
3	littlevortex.net	444.5
4	girlboss.ceo	452.5
5	beeper.com	463
6	matrix.org	493
7	melthecat.dev	532
8	transgender.ing	538.5
9	eyer.life	597.5
10	tomfos.tr	637

🔗That's all I know

See you next week, and be sure to stop by #twim:matrix.org with your updates!

To learn more about how to prepare an entry for TWIM check out the TWIM guide.

Hi all,

Once again we celebrate the end of another year with the traditional Matrix Holiday Special! (see also 2023, 2022, 2021, 2020, 2019, 2018, 2017, 2016 and 2015 just in case you missed them).

This year, it is an incredible relief to be able to sit down and write an update which is overwhelmingly positive - in stark contrast to the rather mixed bags of 2022 and 2023. This is not to say that things are perfect: most notably, The Matrix.org Foundation has not yet hit its funding goals, and urgently needs more organisations who depend on Matrix to join as members in order to be financially sustainable. However, in terms of progress of Matrix towards outperforming the centralised alternatives; growth of the ecosystem; the success of the first ever Matrix Conference; we couldn’t be happier - and hopefully the more Matrix matures, the more folks will want to join the Foundation to help fund it.

So, precisely why are we feeling so happy right now?

🔗Matrix 2.0

Matrix 2.0 is the project to ensure that Matrix can be used to build apps which outcompete the incumbent legacy mainstream communication apps. Since announcing the project at FOSDEM 2023, we’ve been hard at work iterating on:

• Sliding Sync, providing instant sync, instant login and instant launch.
• Next Generation Auth via OIDC, to support instant login by QR code and consistent secure auth no matter the client.
• Native Multiparty VoIP via MatrixRTC, to provide consistent end-to-end-encrypted calling conferencing within Matrix using Matrix’s encryption and security model.
• Invisible Cryptography, to ensure that encryption in Matrix is seamless and no longer confuses users with unable-to-decrypt errors, scary shields and warnings, or other avoidable UX fails.

All of these projects are big, and we’ve been taking the time to iterate and get things right rather than cut corners – the whole name of the game has been to take Matrix from 1.0 (it works) to 2.0 (it works fast and delightfully, and outperforms the others). However, in September at the Matrix Conference we got to the point of shipping working implementations of all of the Matrix 2.0 MSCs, with the expectation of using these implementations to prove the viability of the MSCs and so propose them for merging into the spec proper.

Sliding Sync ended up evolving into MSC4186: Simplified Sliding Sync, and is now natively integrated into Synapse (no more need to run a sliding sync proxy!) and deployed on matrix.org, and implemented in matrix-rust-sdk and matrix-js-sdk. MatrixRTC is MSC4143 and dependents and is also deployed on matrix.org and call.element.io. Invisible Cryptography is a mix of MSCs: MSC4161 (Crypto terminology for non-technical users), MSC4153 (Exclude non-cross-signed devices), MSC3834 (Opportunistic user key pinning (TOFU)), and is mostly now implemented in matrix-rust-sdk - and Unable To Decrypt problems have been radically reduced (see Kegan’s excellent Matrix Conference talk for details). Finally, Next Gen Auth is MSC3861 and is planned to be deployed on matrix.org via matrix-authentication-service in Feb 2025.

It’s been controversial to ship Matrix 2.0 implementations prior to the MSCs being fully finalised and merged, but given the MSCs are backwards compatible with Matrix 1.0, and there’s unquestionable benefit to the ecosystem in getting these step-changes in the hands of users ASAP, we believe the aggressive roll-out is justified. Meanwhile, now the implementations are out and post-launch teething issues have largely been resolved, the MSCs will progress forwards.

One of the things we somehow failed to provide when announcing the implementations at the Matrix Conference was a playground for folks to experiment with Matrix 2.0 themselves. There’s now one based on Element’s stack of Synapse + matrix-authentication-service + Element Web + Element Call available at element-docker-demo in case you want to do a quick docker compose up to see what all the fuss is about! Meanwhile, matrix.org should support all the new MSCs in February – which might even coincide with the MSCs being finalised, you never know!

Rather than going through Matrix 2.0 in detail again, best bet is to check out the launch talk from The Matrix Conference…

Today's Matrix Live: https://youtube.com/watch?v=ZiRYdqkzjDU

…and in terms of seeing a Matrix 2.0 client in action, the Element X launch talk shows what you can do with it!

Today's Matrix Live: https://youtube.com/watch?v=gHyHO3xPfQU

Honestly, it is insanely exciting to see Matrix having evolved from the “good enough for enthusiastic geeks” to the “wow, this feels better than Signal” phase that we’re entering now. Meanwhile, matrix-rust-sdk is tracking all the latest Matrix 2.0 work, so any client built on matrix-rust-sdk (Fractal, Element X, iamb, etc) can benefit from it immediately. There’s also some really exciting matrix-rust-sdk improvements on the near horizon in the form of the long-awaited persistent event cache, which will accelerate all event operations enormously by avoiding needless server requests, as well as providing full offline support.

🔗The Matrix Conference

Talking of The Matrix Conference - this was by far the highlight of the year; not just due to being an excellent excuse to get Matrix 2.0 implementations launched, but because it really showed the breadth and maturity of the wider Matrix ecosystem.

One of the most interesting dynamics was that by far the busiest track was the Public Sector talk track (sponsored by Element) – standing room only, with folks queuing outside or watching the livefeed, whether this was Gematik talking about Matrix powering communications for the German healthcare industry, SwissPost showing off their nationwide Matrix deployment for Switzerland, DINUM showing off Tchap for France, NATO explaining NI²CE (their Matrix messenger), Försäkringskassan showing off Matrix for Sweden with SAFOS, Tele2 showcasing Tele2 Samarbete (Matrix based collaboration from one of Sweden’s main telcos), FITKO explaining how to do Government-to-Citizen communication with Matrix in Germany, ZenDiS using Matrix for secure communication in the German sovereign workspace openDesk project, or IBM showing off their Matrix healthcare deployments.

This felt really surprising: not only are we in an era where Matrix appears to be completely dominating secure communication and collaboration in the public sector – but it’s not just GovTech folks interested, but the wider Matrix community too.

I think it’s fair to say that when we created Matrix, we didn’t entirely anticipate this super-strong interest from government deployments – although in retrospect it makes perfect sense, given that more than anyone, nations wish to control their own infrastructure and run it securely without being operationally dependent on centralised solutions run out of other countries. A particular eye-opener recently has been seeing US Senators Ron Wyden (D) and Eric Schmitt (R) campaigning for the US Government to deploy Matrix in a way similar to France, Germany, Sweden and others. If this comes to pass, then it will surely create a whole new level of Matrix momentum!

It’s worth noting that while many Matrix vendors like Element, Nordeck, Famedly, connect2x and others have ended up mainly focusing commercially on public sector business (given that’s empirically where the money is right now) – the goal for Matrix itself continues to be mainstream uptake.

Matrix’s goal has always been to be the missing communication layer of the web for everyone, providing a worthy modern open replacement to both centralised messaging silos as well as outdated communication networks like email and the PSTN. It would be a sore failure of Matrix’s potential if it “only” ended up being successful for public sector communication! As it happens, our FOSDEM 2025 mainstage talk was just accepted, and happens to be named “The Road To Mainstream Matrix.” So watch this space to find out in February how all the Matrix 2.0 work might support mainstream Matrix uptake in the long-run, and how we plan to ensure Matrix expands beyond GovTech!

🔗The Governing Board

Another transformative aspect of 2024 was the formation of The Matrix.org Foundation Governing Board. Over to Josh with the details…

The election of our first ever Governing Board this year has gone a long way to ensuring we can truly call Matrix a public good, as something that is not only shared under an open source license and developed in the open, but also openly governed by elected representatives from across the ecosystem.

It took forming the Spec Core Team and the Foundation, both critical milestones on a journey of openness and independence, to pave the way. And with the Governing Board, we have a greater diversity of perspectives and backgrounds looking after Matrix than ever before!

The Governing Board is in the process of establishing its norms and processes and just last week published the first Governing Board report. Soon it’ll have elected committee chairs and vice chairs, and it appears to be on track to introduce our first working groups – official bodies to work together on initiatives in support of Matrix – at FOSDEM. Working groups will be another massive step forward, as they enable us to harmonize work across the ecosystem, such as on Trust & Safety and community events.

One last note on this, I want to shout out Greg Sutcliffe and Kim Brose, our first duly elected Chair and Vice Chair of the Governing Board, who have been doing great work to keep things in motion.

🔗Growing Membership

A key part of building the Governing Board has been recruiting to our membership program, which brings together organizations, communities, and individuals who are invested in Matrix. Our members illustrate the breadth of the ecosystem, and many of them are funders who help sustain our mission.

The Foundation has gone from being completely subsidized by Element in 2022, to having nearly half of its annual budget covered by its 11 funding members.

Of course, only being able to sustain half our annual budget is not nearly good enough, and it means that we live hand-to-mouth, extending our financial runway a bit at a time. It’s a nail biter of a ride for the hardworking staff who labor under this uncertainty, but we savor every win and all the progress we’ve made.

I’d like to take this opportunity to thank our funding members, including Element, our Gold Members, Automattic and Futurewei Technologies, our Silver Members, ERCOM, Fairkom, Famedly, Fractal Networks, Gematik, IndieHosters, Verji Tech, and XWiki.

We look forward to welcoming two new funding members in the coming weeks!

Our community-side members also play an important role, and we’re grateful for their work and participation. This includes our Associate Members, Eclipse Foundation, GNOME Foundation, and KDE, and our Ecosystem Members: Cinny, Community Moderation Effort, Conduit, Draupnir, Elm SDK, FluffyChat, Fractal, Matrix Community Events, NeoChat, Nheko-Reborn, Polychat, Rory&::LibMatrix, Thunderbird, and Trixnity.

If you’d like to see Matrix continue its momentum and the Foundation to further its work in ensuring Matrix is an independently and collectively governed protocol, please join the Foundation today. We need your help!

Back to you, Matthew!

🔗Focus

In 2023, we went through the nightmarishly painful process of ruthlessly focusing the core team exclusively on stabilising and polishing the foundations of Matrix – shelving all our next-generation showcases and projects and instead focusing purely on refining and evolving today’s Matrix core use cases for chat and VoIP.

In 2024, I’m proud to say that we’ve kept that focus – and indeed improved on it (for instance, we’ve stepped back on DMA work for much of the year in order to focus instead on the Trust & Safety work which has gone into Matrix 1.11, 1.12, and 1.13). As a result, despite a smaller team, we’ve made huge progress with Matrix 2.0, and the results speak for themselves. Anecdotally, I now wince whenever I have to use another messaging system – not because of loyalty to Matrix, but because the experience is going to be worse: WhatsApp has more "Waiting for message, this may take a while" errors (aka Unable To Decrypts or UTDs) than Matrix does, takes longer to launch and sync and has no threads; iMessage’s multidevice support can literally take hours to sync up; Signal just feels clunky and my message history is fragmented all over the place. It feels so good to be in that place, at last.

Meanwhile, it seems that Element’s move to switch development of Synapse and other projects to AGPL may have been for the best – it’s helped concretely address the issue of lack of commercial support from downstream projects, and Element is now in a much better position to continue funding Synapse and other core Matrix work. It’s also reassuring to see that 3rd party contributions to Synapse are as active as ever, and all the post-AGPL work on Synapse such as native sliding sync shows Element’s commitment to improving Synapse. Finally, while Dendrite dev is currently slow, the project is not abandoned, and critical fixes should keep coming – and if/when funding is available P2P Matrix & Dendrite work should resume as before. It wouldn’t be the first time Dendrite has come back from stasis!

🔗The Future

Beyond locking down Matrix 2.0 in the spec and getting folks using it, there are two big new projects on the horizon: MLS and State Res v3.

MLS is Messaging Layer Security (RFC 9420), the IETF standard for group end-to-end-encryption, and we’ve been experimenting with it for years now, starting around 2019, to evaluate it for use in Matrix alongside or instead of our current Double Ratchet implementation (Olm/Megolm). The complication on MLS is that it requires a logically centralised function to coordinate changes to the membership of the MLS group – whereas Matrix is of course fully decentralised; there’s never a central coordination point for a given conversation. As a result, we’ve been through several iterations of how to decentralise MLS to make it play nice with Matrix – essentially letting each server maintain its own MLS group, and then defining merge operations to merge those groups together. You can see the historical work over at https://arewemlsyet.com.

However, the resulting dialect of MLS (DMLS) has quite different properties to vanilla RFC 9420 MLS – for instance, you have to keep around some historical key data in case it’s needed to recover from a network partition, which undermines forward secrecy to some extent. Also, by design, Matrix network partitions can last forever, which means that the existing formal verification work that has been done around MLS’s encryption may not apply, and would need to be redone for DMLS.

Meanwhile, we’ve been participating in MIMI (More Instant Messaging Interoperability), an IETF working group focused on building a new messaging protocol to pair with MLS’s encryption. A hard requirement for MIMI is to utilise MLS for E2EE, and we went through quite a journey to see if Matrix could be used for MIMI, and understand how Matrix could be used with pure MLS (e.g. by having a centralised Matrix dialect like Linearized Matrix). Right now, MIMI is heading off in its own direction, but we’re keeping an eye on it and haven’t given up on converging somehow with it in future. And if nothing else, the exercise taught us a lot about marrying up Matrix and MLS!

Over the last few months there has been more and more interest in using MLS in Matrix, and at The Matrix Conference we gave an update on the latest MLS thinking, following a workshop at the conference with Franziskus from Cryspen (local MLS formal-verification experts in Berlin). Specifically, the idea is that it might be possible to come up with a dialect of Matrix which used pure RFC 9420 MLS rather than DMLS, potentially using normal Matrix rather than Linearized Matrix… albeit with MLS group changes mediated by a single ‘hub’ server in the conversation. The good news is that Cryspen proposed a mechanism where in the event of a network partition, both sides of the partition could elect a new hub and then merge the groups back together if the partition healed (handling history-sharing as an out-of-band problem, similar to the problem of sharing E2EE history when you join a new room in Matrix today). This would then significantly reduce the disadvantages of rooms having to have a centralised hub, given if the hub broke you could seamlessly continue the conversation on a new one.

So, we’ve now had a chance to sketch this out as MSC4244 - RFC 9420 MLS for Matrix, with two dependent MSCs (MSC4245 - Immutable encryption, and MSC4246 - Sending to-device messages as/to a server) and it’s looking rather exciting. This is essentially the protocol that Travis & I would have proposed to MIMI had the WG not dismissed decentralisation and dismissed Matrix interop - showing how it’s possible to use MLS for cryptographic group membership of the devices in a conversation, while still using Matrix for the user membership and access control around the room (complete with decentralisation). Best of all, it should also provide a solution to the longstanding problem of “Homeserver Control of Room Membership” highlighted by Albrecht & co from RHUL in 2022, by using MLS to prove that room membership changes are initiated by clients rather than malicious servers.

Now, we’re deliberately releasing this as a fairly early draft from the Spec Core Team in order to try to ensure that MLS spec work is done in the open, and to give everyone interested the opportunity to collaborate openly and avoid fragmentation. In the end, the SCT has to sign off on MSCs which are merged into Matrix, and we are responsible for ensuring Matrix has a coherent and secure architecture at the protocol layer – and for something as critical as encryption, the SCT’s role in coordinating the work is doubly important. So: if you’re interested in this space, we’d explicitly welcome collaboration and feedback on these MSCs in order to get the best possible outcome for Matrix – working together in the open, as per the Foundation’s values of ‘collaboration rather than competition’, and ‘transparency rather than stealth’.

Meanwhile, the other big new project on the horizon is State Resolution v3. Old-timers may remember that when we launched Matrix 1.0, one of the big changes was the arrival of State Resolution v2 (MSC1442), which fixed various nasty issues in the original merge conflict resolution algorithm Matrix uses to keep servers in sync with each other. Now, State Res v2 has subsequently served us relatively well (especially relative to State Res v1), but there have still been a few situations where rooms have state reset unexpectedly – and we’re currently in the process of chasing them down and proposing some refinements to the algorithm. There’s nothing to see yet, although part of the work here has been to dust off TARDIS, our trusty Time Agnostic Room DAG Inspection Service, to help visualise different scenarios and compare different resolution algorithms. So watch this space for some very pretty explanations once v3 lands!

🔗Happy New Year!

Matrix feels like it entered a whole new era in 2024 – with the Foundation properly spreading its wings, hosting The Matrix Conference, operationalising the Governing Board, and Matrix uptake exploding across the public sector of 20+ countries. Funding continues to be an existential risk, but as Matrix continues to accelerate we’re hopeful that more organisations who depend on Matrix will lean in to support the Foundation and ensure Matrix continues to prosper.

Meanwhile, 2025 is shaping up to be really exciting. It feels like we’ve come out of the darkness of the last few years with a 2.0 which is better than we could have possibly hoped, and I can’t wait to see where it goes from here!

Thanks to everyone for supporting the project - especially if you are a member of the Foundation (and if not, please join here!). We hope you have a fantastic end of the year; see you on the other side, and thanks for flying Matrix :)

Hi all,

It’s been 6 months since the first ever Matrix Governing Board (GB) was formally elected & announced, and it has recently had its first official meeting. As such, we felt it was time that you, our constituents, had a report on how things are going and what we’ve been doing. We appreciate that the work of the GB is often in the background, and we want to be as transparent as we can.

🔗What’s been happening?

Since our election in June, the GB has mainly been focussed on internal structure. We began with the most basic part of this - getting to know each other! We have quite a large group, and we all needed time to understand what each of us would like to achieve, and to assist with. We also needed to get to know the Foundation better, and time spent with Josh has been extremely valuable too.

The other, even bigger, topic to tackle has been structure. We are a new board, and as such we need to lay down the processes and hierarchy that will govern our work in the near-to-medium future. There is ample inspiration around us in the many other communities we are part of, but we do have to write down our versions of these.

🔗What about the recent Governing Board meeting?

The GB had its first official meeting on Nov 15th, and the topic of structure took up all of our time - this is key since that structure is blocking the work we want to do in various topic areas (which we’re calling Committees). There are detailed minutes available here but here is a high level summary - you’ll note that these all relate to the structure and norms of the GB:

• We elected our first Chair and ViceChair - Greg Sutcliffe (gwmngilfen) and Kim Brose (HarHarLinks) respectively
• We discussed some of the core elements of the GB - voting processes, quorum, timescales, etc
• We discussed the organisation layout, Committees, and Working Groups - more detail on that below
• We talked a lot about norms as well - how we expect members of the GB to behave.

The last point is actually really important - while it sounds quite simple, it’s critical for setting expectations for us and also helps set overall policy when an explicit rule or process doesn’t exist. The culture that we set out with this first board will likely set the tone for the future, and we should get it right.

🔗Committees and Working Groups

Probably the decision with the biggest impact (thought we agreed it fairly quickly) was around the hierarchy of the GB, so let’s expand on that a bit.

As we reported in TWIM at the time, we have convened 4 initial Committees (Governance, Trust & Safety, Community, and Finance & Fundraising), and these are board-level subgroups with a focus on that specific area. Each Committee will have one or more Working Groups (WG) that focus on something related to that topic, and WGs must have a board member involved - but can (and probably should) involve more people from the community who wish to be involved in that effort.

Drawing on my own background in operating systems, this is somewhere between the CentOS model (which just has Special Interest Groups under the CentOS Board) and Fedora (which has a detailed & complex org chart). As an example, we’ll (probably) have a Website WG under the Community Committee.

Each Committee and WG will need a charter - this can be pretty short, but sets out the remit of that group. Committees will also need a Chair (and probably a Vice Chair, just in case) so that we can ensure things keep ticking along. Those positions are open for voting within the GB at the moment!

For the community, you can expect regular reports from the committees once they’ve formed, and we’ll bring those to you as we can - how we do reporting with transparency is also a topic we're discussing. You can also expect a process for people to propose new Working Groups - that is also under discussion!

🔗Reports?

Yes! So, as said above, the Committees will have an obligation to report on their activity. Since most have only existed for 3 weeks so far, there’s not yet much to say, but I hope that in the next few weeks we’ll be able to announce the Committees are up-and-running, and that we have a proposal system for new WGs.

We also have a report from the Spec Core Team which they’ve asked us to share with you - you can read that SCT report here.

🔗What’s next?

Right now, elections are in progress for the people who will run the Committees, and we want to finalise the norms and processes - these have had significant discussion already, and once we’ve tidied up the last points we can vote them in. Then comes the serious work of setting up WGs, and all that entails.

We know that this seems a very slow process, especially in today’s world of fast moving technology - but the work of discussion, negotiation, and consensus can’t be rushed. It’ll be worth it.

If you want to chat with us, we are always happy to chat! You can find us in the Office of the Governing Board room, but many of the GB will also be present at FOSDEM as well as being at the Friday Matrix event - please talk to us, bring us your thoughts, tell us your worries. We’ll do what we can to help.

Until next time!

Greg (on behalf of the Governing Board)

Hey all,

Another 9 MSCs have been released today in Matrix 1.13! It’s just over 2 months since Matrix 1.12 went out, and the last scheduled release for 2024 - the next release is planned for around FOSDEM 2025. Today’s release contains more T&S features and a number of clarifications and improvements. The full changelog is at the end of this post, per usual :)

🔗Account suspension

Last release brought Account Locking to the spec, and this release brings Account Suspension - a highly related but semantically different feature. Locking prevents the user from accessing their account, typically as a consequence of security reasons or restrictions, while suspension aims to disrupt while retaining a (mostly) readonly experience for the user. Both actions are reversible, and available to safety and security teams to help manage their servers with alternatives to deactivation (a destructive, irreversible, action).

Clients should continue calling /sync to detect when a lock/suspension is lifted (or converted to deactivation). MSC3939 and MSC3823 both have suggestions on what a UI could look like for the different states.

🔗Reporting rooms

Event reporting has been in the spec since the very early days of Matrix, allowing users to send concerns about particular content to their homeserver administrators for review. A notable gap in this functionality is being able to report whole rooms from the public room directory or out of band in general - this has been addressed in Matrix 1.13 with the new report room endpoint.

The T&S team continues to work on designing a possible replacement to reporting in general, considering functionality like appeals, report-to-moderators, classification, and other quality of life improvements.

🔗Up next in Matrix 1.14 and 2025

Mentioned earlier in this post, Matrix 1.14 is expected to be released around FOSDEM 2025 in early February. Many of the Matrix 2.0 features, like OIDC and Simplified Sliding Sync, are getting ever-closer to the needed proposed-FCP state to become part of the spec. We currently expect that the Matrix 2.0 features will land in either Matrix 1.14 or Matrix 1.15, converting the applicable release to Matrix 2.0 as a specification version. This is highly dependent on the MSCs progressing through FCP though, and may get pushed out as needed.

As always, if there’s an MSC ready for FCP, let us know in the SCT Office room! We’re currently on an administrative break until January 8th, 2025, but we’re still around and prioritizing features as we see them.

🔗The full changelog

The full changelog for Matrix 1.13 is:

🔗Client-Server API

New Endpoints

• Add POST /_matrix/client/v3/rooms/{roomId}/report, as per MSC4151. (#1938, #2028)

Backwards Compatible Changes

• Add error codes to requestToken endpoints, as per MSC4178. (#1944)
• Remove reply fallbacks, as per MSC2781. (#1994)
• Clarify the allowed HTTP methods in CORS responses, as per MSC4138. (#1995, #2011)
• Add new M_USER_SUSPENDED error code behaviour, as per MSC3823. (#2014)

Spec Clarifications

• The reason parameter in POST /_matrix/client/v3/rooms/{roomId}/report/{eventId} can be omitted instead of left blank, as per MSC2414. (#1938)
• Correct OpenAPI specification for query parameters to GET /_matrix/client/v3/thirdparty/location/{protocol} endpoint. (#1947)
• Sort VoIP events semantically. (#1967)
• Clarify that servers must forward custom keys in PusherData when sending notifications to the push gateway. (#1973)
• Clarify formats of string types. (#1978, #1979, #1980)
• Clarify that the async upload endpoint will return 404 in some cases. (#1983)
• Remove distinction between StateFilter and RoomEventFilter. (#2015)
• Add hyperlinks throughout the specification. (#2016)
• Use json instead of json5 for syntax highlighting. (#2017)
• Specify order that one-time keys are issued by /keys/claim, as per MSC4225. (#2029)

🔗Server-Server API

Backwards Compatible Changes

• Make ACLs apply to EDUs, as per MSC4163. (#2004)

Spec Clarifications

• Add 403 error response to /_matrix/federation/v1/state_ids/{roomId}. (#1926)

🔗Application Service API

Backwards Compatible Changes

• Allow sending ephemeral data to application services, as per MSC2409. (#2018)

🔗Identity Service API

No significant changes.

🔗Push Gateway API

Spec Clarifications

• Document the schema of PusherData. (#1968)
• The path of HTTP pusher URLs is fixed to /_matrix/push/v1/notify. (#1974)

🔗Room Versions

Spec Clarifications

• Clarify rule 4.3.1 of the auth rules in room version 11 to state which event's sender the state_key needs to match. (#2024)

🔗Appendices

Spec Clarifications

• Remove note about reference implementations. (#1966)

🔗Internal Changes/Tooling

Spec Clarifications

• Add x-weight property for sorting events rendered with the event-group shortcode. (#1967)
• Enforce consistent vertical spacing between paragraphs in endpoint definitions. (#1969, #2005)
• Remove boxes/added-in-paragraph shortcode. (#1970)
• Remove withVersioning parameter of rver-fragment shortcode. (#1971)
• Remove span element from added-in and changed-in shortcodes. (#1972)
• Fix formatting of added-in and changed-in shortcodes by using % delimiter. (#1975)
• Remove CSS workaround for scroll-anchoring. (#1976)
• Rename custom-formats.yaml to string-formats.yaml and update its docs. (#1977)
• Fix relative URLs when serving the specification with a custom baseURL. (#1984, #1997)
• Rename .htmltest.yaml to .htmltest.yml. (#1985)
• Improve the JS script to highlight the current ToC entry. (#1991, #2002)
• Upgrade docsy to 0.11.0 and hugo to 0.139.0. (#1996, #2007)
• Improve the quality of the rendered diagrams (#1999)
• Update the Inter font and allow the browser to render the page before it is loaded (#2000)
• Use a proper Matrix favicon (#2001)
• Clean up unused CSS classes in openapi/render-operation partial. (#2003)
• Fix changed-in partial when used with multiple paragraphs. (#2006)
• Optimize generated CSS by removing unused selectors. (#2008)
• Remove trailing slash on void HTML elements. (#2009)
• Remove type and language attributes of script element. (#2021)
• Change the accessible role of info boxes to note. (#2022)

🔗Matrix Live

Today's Matrix Live: https://youtube.com/watch?v=GQATaQpuUUQ

🔗Dept of Status of Matrix 🌡️

Matthew reports

Last week US Senators Wyden (D) and Schmitt (R) wrote an open letter to the US Department of Defense encouraging them to adopt Matrix more widely, rather than wasting money on unencrypted, centralised or closed systems. The letter also reveals a whole bunch of info at the end about the US Navy's Matrix deployments. This feels like a huge step change forwards - not only is the FBI encouraging citizens to use end-to-end-encryption in the wake of realisations that the public telephone network is insecure, but US Senate is pushing for Matrix adoption (without any lobbying from us, I hasten to add). You can read more about it at the Element blog (Element provides the deployments for the US Navy).

P.S. it really is bleakly amusing that we've been constantly pointing out that legislation like EU's ChatControl and the UK's Online Safety Act are catastrophically flawed because the surveillance backdoors they propose will be exploited and abused by attackers. And here we are, with the lawful intercept backdoors in the US public phone system being compromised by attackers, causing the FBI to recommend non-backdoored E2EE instead. We live in a very strange timeline.

🔗Dept of Spec 📜

Andrew Morgan (anoa) {he/him} reports

Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.

🔗MSC Status

New MSCs:

• MSC4239: Room version 11 as the default room version
• MSC4238: Pinned events read marker

MSCs in Final Comment Period:

• No MSCs are in FCP.

Accepted MSCs:

• MSC4225: Specification of an order in which one-time-keys should be issued
• MSC4147: Including device keys with Olm-encrypted events

Closed MSCs:

• No MSCs were closed/rejected this week.

🔗Random MSC of the Week

The random MSC of the week is... MSC3006: Bot Interactions!

We haven't had one of these in a while, so I figured, why not!

This MSC talks about "bot interactions", which are additional ways that users can interact with bots other than text - namely client-rendered buttons. Ironically, the rise of LLMs in the years since this MSC was published have brought human-computer text interaction to the forefront, but buttons still have their place!

A bot can define their interactions as a state event and send it into the room. Then clients that see that state event can populate user menus with the actions that bots support! Clicking on a button will send a message into the room that a bot would parse as per usual (so really this is just a shortcut to typing commands out manually). The benefit is users don't need to remember commands (and don't need to !help all the time - cough cough mjolnir), and can quickly issue a potentially lengthy command without typing.

This seems like a cool feature to me. If any bot or client devs feel the same, consider reaching out on the MSC and offering your feedback!

🔗Dept of Servers 🏢

🔗Synapse (website)

Synapse is a Matrix homeserver implementation developed by Element

Till reports

This week we released Synapse 1.121.0 (and 1.121.1).

1.121.1 is just a patch release to fix an issue building release docker images in our CI. As such, there is only a docker image for 1.121.1, not 1.121.0. 1.121.1 is otherwise functionally identical to 1.121.0.

1.121.0 introduces experimental support for a number of MSCs (MSC4190: Device management for application services, MSC4076: Let E2EE clients calculate app badge counts themselves (disable_badge_count)), as well as stabilises support for locking accounts. It also has bug fixes and limited initial support for returning information about suspended users via the Admin API.

Grab it while it's hot! 🔥

🔗Dept of Clients 📱

🔗Extera

OfficialDakari reports

Recently, Extera got saved messages feature. To save a message, open it's menu and click Save. This feature can be changed at any time and is unstable. Also, now, users of extera.xyz can get an email on our domain. DM @mail:extera.xyz and say !m help.

🔗SchildiChat (website)

SchildiChat is a fork of Element for Android and Desktop, that used to focus on UI changes such as message bubbles and a unified chat list, but now also provides some additional tweaks and community-driven features that may not be on the roadmap for the upstream clients.

SpiritCroc says

While releases of SchildiChat Next (our fork of Element X for Android) have always been available on my own F-Droid repository, we finally made it into the main F-Droid repository too! These F-Droid releases are reproducible builds checked against my repo, so you know if it lands on the F-Droid repository that it matches what I built before. Compared to reproducible builds from Element X, F-Droid even builds our forks of the Matrix Rust SDK and the Rich Text Editor from source rather than using prebuilts to include as dependencies.

On the feature side, one of the main points that made me switch back to the old SchildiChat app was the ability to manage rooms in spaces. Accordingly, I added a long-press action to the room list that allows you to select a room's parent spaces to add to or remove from. At the time of writing this change is still only included in beta builds behind a feature flag, but will probably arrive in a release build in the next few days.

🔗Element X iOS (website)

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

Mauro Romito says

• We are doing great progress with message knocking and media gallery
• We are also experimenting with the event cache, which will make the app even faster
• Some design improvements are being made in the room details screen and the join room screen

🔗Element X Android (website)

Android Matrix messenger application using the Matrix Rust SDK and Jetpack Compose.

benoit reports

• Pretty similar to what's happening on Element X iOS:
• We are doing progress with room knocking
• We are making progress on the media gallery and are integrating an audio player to play voice message and message with audio attachment
• We are also experimenting with the event cache, which will make the app even faster. There is still work to do SDK side to make it usable so it's behind a disabled feature flag for now.

🔗Dept of SDKs and Frameworks 🧰

🔗Trixnity (website)

Multiplatform Kotlin SDK for developing Clients, Bots, Appservices and Servers

Benedict says

The latest release of Trixnity introduces support for decrypted temporary files across all platforms! 🎉 This feature is crucial for handling media like video playback and PDF rendering that require secure but temporary access to decrypted content. Trixnity ensures to providing seamless and secure handling of such files, while maintaining compatibility with the old API.

For more information about this update, or to check out Trixnity, visit the project repository: https://gitlab.com/trixnity/trixnity.

We welcome feedback and discussions in the #trixnity:imbitbu.de room.

🔗Dept of Services 🚀

🔗Synapse Admin Updates

Aine [don't DM] says

A while back, we at etke.cc announced our Synapse-Admin fork. This week, we’re excited to introduce more new features and quality-of-life improvements!

Media Tab for Rooms

Previously, media management was limited to individual users (i.e., media uploaded by a specific user). Now, you can manage media at the room level!

⚠️ While the new media tab offers options to view and remove media per room, it’s worth noting that the Admin API endpoint for room media is more limited compared to the user media endpoint. Despite this, we hope this feature will assist with Matrix server moderation.

Account Suspension (MSC3823)

Account suspension is here! This feature enables you to place users in a "read-only account" state as an alternative to locking accounts.

💡 Note: Not all Admin API endpoints fully support the suspension flag yet, but support is expected to improve in future updates.

E.164-Based Matrix IDs (MSC4009)

Support for E.164-based Matrix IDs is finally here!

Matrix IDs in the format +123456:example.com (with a + sign) have been valid since Matrix v1.8. However, Synapse Admin previously lacked support for these IDs - oops! This has now been addressed.

🔗Spread the Word!

We at etke.cc are incredibly proud of what we’ve accomplished with our Synapse Admin fork. Over the last three months, we’ve released an impressive 34 versions, each packed with updates to make Synapse Admin the go-to admin dashboard for Synapse.

While we haven’t yet covered 100% of the API endpoints, and there’s still work to be done, the overall experience has improved dramatically.

If you’ve appreciated the progress we’ve made, we’d love your help in spreading the word about github.com/etkecc/synapse-admin! Share it with homeserver owners and administrators you know, and let them discover the features we’ve worked so hard to deliver.

Explore the source code or try the admin.etke.cc (CDN version). Don’t forget to join the discussion in #synapse-admin:etke.cc

Kim was flabbergasted by Aine's productivity and shared

🔗Dept of Bots 🤖

🔗I Don't Have Spotify Maubot

HarHarLinks says

Do people sometimes share links to music with you on Matrix? They do for me. Often, people use Spotify as their music streaming service, but I don't have Spotify.

Therefore about month ago, I shared a maubot plugin on TWIM, which uses the REST API of sjdonado's I don't have Spotify webapp, which itself is also selfhostable open source software.

As it turns out, people sometimes also share links to other streaming services not just with me but also with you!

So after a bit more tinkering, I have released v1.1.0 of my plugin https://github.com/HarHarLinks/maubot-idonthavespotify. It can now also be configured to check for any combination of spotify, apple, deezer, soundcloud, tidal, and youtube, which are all supported by idonthavespotify to different extent. Your mileage may vary depending on what you search, but that's up to the upstream project, since the plugin just connects whatever it does to matrix.

Let me know of any feedback you have at #maubot-idonthavespotify:matrix.org!

Here is what it can look like in action:

🔗Dept of Events and Talks 🗣️

🔗Matrix Stammtisch Dresden

@mcnesium:matrix.org announces

After being founded live during the recording of a recent "Reboot Politics" podcast show, the newly spawned regional community meetup "Matrix Stammtisch Dresden" will have their second get-together next Wednesday the 18th December at 19:00 in the bistro/restaurant "Neue Sachlichkeit" at Kraftwerk Mitte, Dresden, DE – all creatures welcome!

🔗FOSDEM

Thib (m.org) says

The Matrix.org Foundation & Community Devroom @ FOSDEM has a schedule!

The DevRoom will start at 13:00 and end at 17:00 CET, on Sunday, February 2. We received more talks than we could accept, compressed some longer talks into shorter ones to accept as many high quality talks as possible, but we had to make some tough choices!

We will hold a Fringe Event before FOSDEM and invite everyone who didn't make it to the schedule to give it another try there! We already have 2 generous sponsors to keep the community refreshed and fed, and we're open to more sponsorship opportunities. Reach out if you want to talk about how you can help us secure recordings for Fringe event speakers who opt-in, or more.

As for the devroom itself, the schedule is the following:

• 13:00 Matrix State of the Union
• 13:30 Getting the Rust SDK running on WebAssembly
• 14:00 Demystifying Federation in Matrix
• 14:30 State of Synapse
• 15:00 Building the World's First Server-to-Server Matrix Federation Bridge
• 15:30 How Ubuntu Entered the Matrix
• 16:00 Robrix: a pure multi-platform Matrix Client and more
• 16:30 MatrixRTC: Building Real-Time Applications on Matrix

🔗Matrix Salon Podcast: Tom Lant

Christian Paul (jaller94) says

Back in August, I had the honour of interviewing Tom about Matrix, Element, open source work and the community.

Here are links to the episode with Tom, RSS feed of the Matrix Salon Podcast and the Mastodon post about Tom's episode.

You may also look forward to two more German episodes which are planned to be released before the end of the year (aka. on the upcoming two Fridays). 🥁

🔗Dept of Interesting Projects 🛰️

Kegan reports

TARDIS has had a facelift! Matthew spent a weekend devising a custom layout algorithm and renderer which has now replaced d3-dag.

This is not only clearer for complex DAGs but also faster than the layout algorithm we previously used. We're currently using TARDIS to experiment with state resolution improvements.

🔗Christian's NeoBoard Advent Calendar

Christian Paul (jaller94) reports

More backgrounds, more games, more templates for your retrospectives. My NeoBoard Advent Calendar offers free whiteboard templates every day.

• NeoBoard Advent Calendar
• NeoBoard Adventskalender (German / Deutsch)

Check out some highlights from the past days:

• Door 7: Pairs game (generator)
• Door 11: Memorise the scene (Christmas)
• Door 13: Ocean background

Do you also wonder what will be behind tomorrow's door? 😏

NeoBoard is a whiteboard widget for Element, allowing you and your team to collaborate during meetings, presentations and group projects. You can export and import whiteboard files to reuse them as templates or migrate between rooms.

🔗Dept of Built on Matrix 🏗️

🔗Acter (website)

Your social organizing app build on matrix: A secure space to gather, engage and grow your community!

ben says

We have been working on deep-linking support in Acter for a while now. As per our usual process, progrress on that happens iteratively over the weekly releases. In the last few releases, we have added support for matrix.to and matrix:-URI-schemes on Mobile as well as started experimenting with our own acter:-scheme to support linking to specific items like Pins and Task-Lists. The current release already featuers support for that via a new QR-code you can scan from within the app to directly jump to specific items. As part of that effort, you can also link calendar-events and pins in boosts and you can easily do that from the newly designed share-screen from the object itself. It's glorious.

On the other side, work on the Chat NG - the total rewrite of the chat UI infrastructure - is also progressing very well with support for bubbles and grouping of messages already in, and further message types being rendered properly now. It is still quite a bit from production ready but the improvement in architecture can already be felt very nicely in terms of UX speed and reactive-ness when you switch it on in your Labs.

Last but not least, we have started with "spring cleaning"-sessions where larger parts of the team get together and walk through the app and discuss minor bugs and annoyances in a synchronised sessions and then try to fix them there and then - so we can speed up the process on these - or write them up as proper bugs if we can't fix them yet. A first sessions of this kind was done recently and fixed a bunch of minor annoyances. As usual the Github release page's Changelog has all the details.

Additionally, we'd like to mention that we are looking for a DevOps Person helping us run our Matrix Infrastructure to extend the Acter Team. If that sounds interesting to you, please apply :) .

🔗Matrix Federation Stats

Aine [don't DM] reports

collected by MatrixRooms.info - an MRS instance by etke.cc

As of today, 10386 Matrix federateable servers have been discovered by matrixrooms.info, 3148 (30.3%) of them are publishing their rooms directory over federation. The published directories contain 20778 rooms.

Stats timeline is available on MatrixRooms.info/stats

How to add your server | How to remove your server

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

🔗#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	codestorm.net	242
2	nerdhouse.io	303.5
3	wi11.co.uk	307
4	girlboss.ceo	311.5
5	envs.net	407.5
6	catvibers.me	437
7	ncat.cafe	491
8	larsl.net	683
9	melthecat.dev	1161
10	xiny.li	1200

🔗That's all I know

See you next week, and be sure to stop by #twim:matrix.org with your updates!

To learn more about how to prepare an entry for TWIM check out the TWIM guide.

The Matrix.org Foundation has been made aware that an international investigative operation took down a service called MATRIX which was used by a cybercriminal network, which has no relationship with the Matrix.org Foundation or the Matrix protocol itself.

The takedown site has a Matrix-the-movie branding, which is a probable source of confusion. The app showcased doesn’t look like any of the Matrix clients we’re aware of.

In a statement to the Matrix.org Foundation, Europol confirmed that the MATRIX cybercriminal network and the Matrix protocol are entirely unrelated. Europol states:

The Matrix protocol (matrix.org) is by no means connected to the Matrix secured communication service that was targeted in OTF Continental.

A statement from the Dutch police confirms that this is unrelated: "Matrix is ​​also the name of a company and communications protocol of the same name, which has nothing to do with the crypto communications service Matrix."

The Matrix.org Foundation and community are very happy to announce that this year, they will be in full force at FOSDEM, with a community event right before the conference, a booth to welcome everyone during the conference, and a dev room to explore topics in depth!

🔗Jan 31 - Matrix Community Event

We organize an event before FOSDEM for the community to meet and talk about Matrix without fear of missing out on all the great talks at FOSDEM. The event will take place on January 31 at 1 pm CET at HSBXL and last the whole afternoon. Please note that HSBXL moved since last year.

It's an unconference/barcamp: come and bring your ideas, share them at the beginning of the event, and small groups will form spontaneously.

Please note that the Matrix Community Event has the same Health & Safety Policy as the Matrix Conference. Extremely briefly: You will need to wear a mask while indoors, except while eating and drinking.

As last year, attending the event is free, and we're looking for sponsors to show their commitment to the ecosystem by refreshing our community with drinks and feeding it with pizzas! Of course, you will be credited in our event wrap-up post on matrix.org. We're open to additional ideas to get you the recognition you deserve.

Join the FOSDEM Barcamp room if you're interested in the event, and reach out to events-wg@foundation.matrix.org to sponsor!

• 🕐️ Friday 31, 13:00 - 21:00 CET (local time)
• 🏢 HSBXL

🔗Feb 1&2 - Booth

This year again, we are happy to have a booth for the duration of the event. This is our opportunity to talk with the broader open-source community, share our latest updates, and listen to people's feedback. We can also help the broader community spread the word with cool stickers and T-shirts!

We're looking for volunteers to run the booth with us. This includes talking to the community, sharing project news, and selling merch. Don't worry if it's your first time: We have a booth handbook ready for volunteers and want to limit the time commitment to 2 hours per day.

Reach out to events-wg@foundation.matrix.org if you're interested in staffing the booth with us! We will work out together which slot works best for you. People who sign up before December 15 are entitled to a special edition T-shirt!

• 🕐️ Saturday 1 to Sunday 2, 09:00 - 18:00 CET (local time)
• 🏢 Desk K.2.B4

🔗Feb 2 - Main Track Talk

Matthew's "The Road to Mainstream Matrix" talk got accepted on the main track. It will happen right before the Devroom, fortunately in the same building!

• 🕐️ Sunday 2, 12:00 - 12:50 CET (local time)
• 🏢 Room K.1.105 (La Fontaine)

🔗Feb 2 - DevRoom

Some topics are too complex to be discussed at a booth. Fortunately, we have a DevRoom on Sunday 2 afternoon to talk about topics in greater depth. Be it a technical talk about state resolution or a success story about how Matrix got deployed in your organization, we want to hear about it all!

The Call for Proposals is now closed.

• 🕐️ Sunday 2, 13:00 - 17:00 CET (local time)
• 🏢 Room K.4.201
• 🗒️ The schedule is here

The whole team is looking forward to meeting you at FOSDEM!

🔗Dept of Status of Matrix 🌡️

🔗Sunsetting the Sliding Sync Proxy: Moving to Native Support

Will L announces

Work on Sliding Sync – which provides a significantly faster and more scalable sync experience in Matrix clients – has moved to focus on native support, and away from the proxy.

The Sliding Sync Proxy on the Matrix.org homeserver will be decommissioned on November 21st, and client support in Element X will be removed on January 17th.

More details for users as well as server and client developers in Matrix.org's latest blog post

🔗First Official Governing Board Meeting

HarHarLinks says

It is Friday TWIMday the 15th of November, and the Governing Board just came out of their first official meeting after the informal one at the Matrix Conference back in September. The focus of this meeting was to define the structure of the Governing Board, so we expect the results will not have an immediate tangible effect outside the Governing Board, but it gives the Governing Board the basic process to enable taking more perceptible decisions.

This includes discussion about how we want to communicate with each other, but we also defined how we vote on actual decisions and some other basic rules for the Governing Board. As a part of that we elected a chair and vice chair for the Governing Board, who are going to help the Governing Board with facilitation tasks. Greg "Gwmngilfen" (chair) and Kim "HarHarLinks" (vice) were elected and are happy to share this post as one of our first actions in this role today. 😁 We also started some subcommittees of the Governing Board, to enable us to work efficiently in smaller groups focussed on specific topics. The rough topics for the initial four committees are Governance, Trust & Safety, Community, and Finances. What their exact scopes are going to be is left as a first task to the respective committees to define along with other bootstrapping, such as electing committee chairs and vice chairs. The set of initial committees is intentionally kept small to remain flexible and open the door for refining them later when we have more experience with how our day to day operations look like. We also discussed defining initial working groups, which would be structured as groups below the committees to fulfil more specific roles and would be the primary way for the Governing Board to include the community. However, we decided to defer that to the committees for now. We got through all the big parts on our agenda but ran out of time before having a formal vote on what communication tools we want to use. We have a great proposal which we are going to vote on asynchronously.

In general we had quite a productive meeting and reached agreements on many topics with clear next steps in other areas. The Governing Board might not have tackled yet the topics you would have prioritised, but it now has an asynchronous voting process and should be able to progress in other areas using the committees.

See you soon with more news from the Governing Board!

🔗Dept of Spec 📜

Andrew Morgan (anoa) {he/him} [back Nov 5] announces

Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.

🔗MSC Status

New MSCs:

• MSC4227: Audio based quick login
• MSC4226: Reports as rooms

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.

🔗Spec Update

Once again there has been a flurry of activity on the spec repo itself, with Kévin Commaille continuing to fix up various aspects of the spec and the technical underpinnings of the website itself. They are also writing up spec PRs for recently accepted MSCs, such as MSC2781: Remove the reply fallbacks from the specification and MSC4138: Update allowed HTTP methods in CORS responses.

Many kudos for their continued efforts on advancing the spec!

🔗Homeserver Deployment 📥️

🔗Element Docker Demo

Matthew says

Last week I teased https://github.com/element-hq/element-docker-demo on Matrix Live - a two-liner for standing up a Matrix 2.0 stack for experimentation: ./setup.sh; docker compose up.

This week I published a proper walkthrough showing how you can use it for both a local setup with mkcert as well as a federated server setup with letsencrypt, complete with QR login and federated MatrixRTC calling with Element Call. The point is to show just how simple it can be to play with Matrix 2.0 and let folks experiment with the implementations (and help ensure any issues are flushed out before it gets baked into the spec for good!)

Today's Matrix Live: https://youtube.com/watch?v=6iMi5BiQcoI

🔗Dept of Clients 📱

🔗Element X iOS (website)

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

Mauro Romito reports

• Knocking work is still going on, some other UIs have been implemented.
• Local echoes for media work has made good progress and will be enable in Nightly and development builds
• Share extension work is now also available in Nightly! Be sure to try it out!
• Finnish has been added to the available languages
• The app is now fully supporting XCode 16.1

🔗Dept of VoIP 🤙

🔗Element Call (website)

Native Decentralised End-to-end Encrypted Group Calls in Matrix, as a standalone web app

spaetz announces

Given the installation of an element call is still tricky (although there is a demo docker image now, rectifying this), here are my notes on how I installed element call (or rather its backend) on a Debian box using a mix of local services and a docker image: https://sspaeth.de/2024/11/sfu/

🔗Dept of SDKs and Frameworks 🧰

🔗Trixnity (website)

Multiplatform Kotlin SDK for developing Clients, Bots, Appservices and Servers

Benedict announces

I released a new version of Trixnity. It now supports Ktor 3 including an up to 90% performance boost for IO operations.

🔗Dept of Services 🚀

🔗etke.cc (website)

Your matrix server on your conditions

Aine [don't DM] reports

🔗Synapse Admin Updates

A while back, we at etke.cc announced our Synapse-Admin fork, and this week we're excited to share more new features and QoL changes!

Prevent accidental user overwrites

The Synapse Admin API endpoint for creating new users and updating existing ones is actually a single Create or modify endpoint, that means you could accidentally overwrite an existing user when you don't mean to. This change adds a username availability check to the user create/edit form that will warn you if you're trying to "create" a user with a username that's already taken. If you accidentally ignore this inline warning message, you will see a modal window upon saving which will ask if you really intend to overwrite the existing user or not.

Why not just disable overwriting completely and only allow editing via the proper "edit user" UI? Because overwriting an existing user is the only user-friendly way to reclaim an erased user / MXID, so completely removing this feature is not a good idea!

Allow providing login form details via GET params

This is a small QoL change - now you could bookmark Synapse Admin URL with prefilled username and homeserver, e.g. https://admin.etke.cc/?username=matrixadmin&homeserver=matrix.example.com. Not a big deal, but nice to have.

Automatically check for updates

The Synapse Admin will do the same thing as Element Web by asking for static files in the background (every hour). If the index page is changed, it will show a notification with a button to reload the page - yep, another small quality-of-life improvement

Source code, admin.etke.cc (CDN version), say hi in the #synapse-admin:etke.cc

🔗Dept of Events and Talks 🗣️

🔗Fedora launch with Matrix Automation

Adrian says

This week, (basically right now) Fedora is running a Virtual event to commemorate the release of Fedora 41.

This year we're continuing to use Matrix as the chat platform for the event and my Pretix invite bot (https://github.com/fedora-infra/maubot-pretix-invite) has been slowly gaining improvements and has been fairly useful in bulk inviting people from this registration form to the Matrix rooms.

If you're able to sign up before noon Eastern, U.S. time, here is the link: https://rsvp.fedoraproject.org/releases/f41-latam-na/

If not, you can join the live stream on Fedora's YouTube channel or wait for the recordings to come out after the event.

Happy F41!

🔗Matrix in a Podcast

@mcnesium:matrix.org says

Last week a friend and I were invited to join this podcast show to talk about Matrix and what makes it different from XMPP. The show is a rather casual chat and in German, but HarHarLinks suggested to announce it here anyway.

🔗FOSDEM Fringe

HarHarLinks announces

Last TWIM we announced the Matrix Devroom at FOSDEM 2025. Two years ago, the Matrix community started a FOSDEM fringe event: The Matrix Foundation and Community Meetup and BarCamp (what a mouthful!). We are happy to announce to be continuing this series!

Like the last times, the fringe event will take place at the local hackerspace HSBXL hackerspace - but if you were there last time, ⚠️ be aware that they moved to a new location! ⚠️ You can find everything about it at https://hsbxl.be/enter/.

The event will start around noon and run until the evening. The last two times we were incredibly happy to find amazing sponsors that enabled us to provide free drinks and pizza for attendees, and we would like to stick to that tradition! If you are interested in sponsoring the fringe event, be it for pizza, drinks or another idea you have, please approach us on Matrix through the Community Events room, the Foundation Office room or by email at mailto:events-wg@foundation.matrix.org.

Beyond that, watch this space for more FOSDEM news to be announced!

🔗Dept of Interesting Projects 🛰️

🔗TARDIS - Time Agnostic Room DAG Inspection Service

Kegan reports

tl;dr - there's a new room DAG visualiser called TARDIS that can do real state resolution.

I've always struggled to properly understand how the state resolution algorithm works. I find it hard to understand the specification, and various blog posts didn't really make things click for me.

With that in mind, I recently spent some time working on a visualisation tool based on a project Matthew first wrote back in 2020 called TARDIS - Time Agnostic Room DAG Inspection Service. The backronym is surprisingly accurate. With this tool, you can step through "debugger-style" events in a room, seeing the shape of the DAG change. Originally this was all it could do, but I knew it could be so much more, so I set about prototyping the improvements I would make to it.

The main thing I wanted to add was the ability to actually perform state resolution on the DAG as it appeared at that point in time. Being able to do this would unlock a number of possibilities:

• Teaching: example DAGs could be loaded to explain how state resolution really works.
• Debugging: developers can load existing rooms into TARDIS to debug incorrect room state calculations.
• Testing: drop the UI and DAGs could be automatically loaded, resolved and asserted that the state at each event is correct, effectively making a server agnostic state resolution test suite.
• Performance: complex graphs can be repeatedly resolved, and the architecture would allow us to calculate and visualise how the algorithm is walking the DAG to see how efficient it is.
• Experimentation: any state resolution or DAG changes to the protocol could be visualised.

I wasn't given a lot of time to work on this, but I did manage to achieve the teaching/debugging aims. I didn't manage to add all of the teaching scenarios, so for now there's only ones explaining the various sort orders used in the state res algorithm.

What's more, this is all hosted so you can try it out without needing to install anything.

🔗How it works

TARDIS gets its data from JSON5 files. These files are intended to be hand-crafted, which is why they aren't pure JSON files. It includes a set of preloaded files to explain parts of state resolution. Each file contains a single "Scenario" which includes:

• The events in the room, already sorted in processing order.
• Annotations for when TARDIS steps into a given event, if any.
• Precalculated state at a given event, if any.

The scenario is then processed and rendered using d3-dag, just like Matthew's original prototype. To perform state resolution at the current event, TARDIS extracts the state sets for the event and makes a WebSockets connection to a "shim server". It is the shim server's job to perform state resolution. TARDIS comes with a Synapse shim, which imports the internal packages required to do state resolution, so it is using the same code paths as a real Synapse server. You can independently run a shim server locally, either in a virtualenv or as a docker container.

The magic happens when you press the "Resolve State" button which:

• Makes a WS connection to the shim server,
• Sends the state sets for the currently selected event,
• The shim server asks TARDIS for the event JSON for certain event IDs (this is why it uses WebSockets and not HTTP),
• The resolved state is returned to TARDIS,
• The resolved state is shown as green nodes on the graph.

State resolution relies heavily on event IDs, and event IDs are calculated fields. The JSON5 file format allows placeholder fake event IDs e.g $JOIN which are preprocessed into real event IDs. Rather than reimplementing canonical JSON, redaction algorithms, and room version handling in TARDIS, it uses gomatrixserverlib as a WASM package to handle this.

🔗What's next?

Unlocking the ability to automatically test state resolution would be a huge milestone, and complement (pun intended) other server-agnostic test suites I have developed in the past (Complement and Complement-Crypto). The test suite would read a JSON5 file to pull out the test DAG, which would have an additional key which has the assertions for that DAG, automatically talk the WS protocol to the shim server to get the resolved state for each event, and check it matches the assertions in the file. This would make it significantly easier for people to reimplement the state resolution algorithm correctly in non-Synapse homeservers.

Performance wise, the shim server is asking TARDIS for event JSON mid-algorithm. This provides a unique insight into the workings of the algorithm. Whilst the original drawings had the idea of "flashing" the nodes as they are requested, a more useful goal would be to just tally up how many times the shim server asks TARDIS for an event. This would allow TARDIS to visualise algorithmic complexity. We could then have a representative set of "realistic" DAGs and test changes to the algorithm for speed e.g given a DAG of n events, Algorithm 1 requests n and Algorithm 2 requests 2n therefore Algorithm 1 is faster.

🔗Matrix Federation Stats

Aine [don't DM] reports

collected by MatrixRooms.info - an MRS instance by etke.cc

As of today, 10361 Matrix federateable servers have been discovered by matrixrooms.info, 3181 (30.7%) of them are publishing their rooms directory over federation. The published directories contain 21664 rooms.

Stats timeline is available on MatrixRooms.info/stats

How to add your server | How to remove your server

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

🔗#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	girlboss.ceo	210
2	puppygock.gay	234
3	bark.arf.wf	251
4	awawawawawawawawawawawawawawawawawawawawawawawawawawawawawawaw.gay	254
5	transgender.ing	261
6	ncat.cafe	324
7	nexy7574.uk	345.5
8	constellatory.net	383
9	pissing.dev	563
10	nexy7574.co.uk	633

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.

🔗The Timeline

1. Now: EX Apps support migrating from the proxy server to native Sliding Sync. The apps automatically detect when the homeserver supports native Sliding Sync and offers the option to migrate. If users choose to migrate, they will be prompted to log in again. This migration is optional, as the apps continue to support both native Sliding Sync and the proxy.
2. November 21st: Service decommissioning. We plan to decommission the proxy service on Matrix.org and archive its codebase.
3. January 17th: Element X stops supporting MSC3575. EX apps (and matrix-rust-sdk) will remove proxy support, fully shifting to native SS. The migration on EX apps will be forced. Users will get logged out so that they can log in again using native Sliding Sync. We encourage server developers to implement Sliding Sync natively by this point.

🔗What This Means for Users

To continue enjoying the speed of Sliding Sync your homeserver and client must support the native Sliding Sync implementation (MSC4186).

At the time of writing, the latest versions of Synapse support native Sliding Sync, as do the Element X clients. There may be other server / client implementations that also have or are in the process of adding support. If you do use Element X apps, native Sliding Sync is used for every new login. For those currently using Element X through the proxy service, the app will prompt you to log out to switch to native Sliding Sync. While this migration is optional for now, it will become mandatory on the 21st of November for those on Matrix.org, when the proxy will be decommissioned. Element X will discontinue support for the previous Sliding Sync implementation (MSC3575) entirely by January 17th.

🔗Guidance for Server & Client Developers

Server & Client developers are encouraged to implement MSC4186 for native sliding sync. Server developers should be aware that by the 17th of January Element clients will drop support for MSC3575, marking a transition to the native system.

We appreciate your understanding as we take this step forward for the Matrix ecosystem.

🔗Matrix Live

Today's Matrix Live: https://youtube.com/watch?v=HmoVN1x4kO8

🔗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

🔗Governing Board Meeting

Nico says

Next Friday (November 15th) the governing board will have its first official meeting! Topics include the governing structure (how do we decide stuff), forming committees (how do we work on topics and who participates where), selecting a chair and vice chair for the board (to steer meetings) and define how we want to communicate. Some of those topics are still in flux and will be defined further throughout this week. If you are interested, your representatives might be able to tell you more and answer your questions!

We are looking forward to having our first official meeting as the board and hopefully we will have productive results to share with you all soon!

🔗Ecosystem Governing Board Members Office Hours

HarHarLinks reports

Earlier this year, the members of the Matrix Foundation voted for members from their own constituency to represent them at the Governing Board. Nico, Bram and myself were elected to represent the Ecosystem.

While we are usually approachable and responsive in all kinds of ways, there are some topics or situations better to discuss synchronously. We therefore starting today Wednesday 6th November start with weekly office hours every Wednesday at 17:00 German time (CET = UTC+1 during winter). 🐸 We will be responsive to chat in the Ecosystem Public Forum room and will also share a link to a (video) call there.

Please find more detail in the announcement post over here.

Update: Our first office hours went great! We covered quite a lot of topics both between us representatives and the community members who joined - so much so that we overran our time slot by 50% 😅 There is going to be one more office hour next week before the first official governing board meeting, so join the office hour (or write us async) if there is any topic you want us to bring up with the governing board. We would also like to emphasise that we are offering this way of communication for you, the community, so please give us feedback over at the Ecosystem Public Forum in regard of the choice of time slot, etc.

🔗Dept of Spec 📜

Andrew Morgan (anoa) {he/him} [back Nov 5] reports

Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.

🔗MSC Status

New MSCs:

• MSC4225: Specification of an order in which one-time-keys should be issued
• MSC4224: CBOR Serialization

MSCs in Final Comment Period:

• No MSCs are in FCP.

Accepted MSCs:

• MSC2781: Remove the reply fallbacks from the specification 🎉

Closed MSCs:

• No MSCs were closed/rejected this week.

🔗Spec Updates

There was a flurry of PRs to the spec website itself this week. In addition to the myriad of fixes and clarifications, the underlying technology got an update!

https://spec.matrix.org is a static site generated with Hugo, and we use the docsy Hugo theme. Matrix.org has their own fork, with minor changes to self-host all third-party JS/CSS assets instead of downloading them from CDNs.

This fork had gotten a bit outdated however, mostly because updating it and re-downloading the CDN assets was a bit of a pain. This week Kévin Commaille both automated this task and subsequently updated our docsy fork to the latest and greatest. Thank you!

We'd also like to call out @Johennes, @bnjbvr, @AllMightLegend, @uhoreg and @dkasak for their contributions to the spec this week. Thanks all!

🔗Dept of Servers 🏢

🔗Synapse (website)

Synapse is a Matrix homeserver implementation developed by Element

Devon Dmytro says

There was no new release this week, but we have been working hard on getting a few specific things ready to go for the release. You can expect the v1.119.0rc1 release to be out early next week.

Alongside the usual allotment of new features and bug fixes, we have been working hard on:

• Lifting the minimum supported Python version to 3.9
• Updating Synapse test infrastructure in order to pull in the latest version of Twisted (24.10.0)

Thank you to all our contributors for helping to make Synapse the best it can be. As always, feel free to stop by #synapse:matrix.org to join in on the discussion and if you encounter a bug make sure to report it here.

🔗Dept of Bridges 🌉

🔗Parsee

LDA announces

Oyé, oyé, nouvelle alpha sur le plus petit pont ! I just released the Parsee v0.2 alpha today. I've not being able to work as much on it as before, but I did get quite some bugsquashing features, and plain dumb experiments like getting it to build and start on an (emulated) DEC Alphaserver with some minor changes to Cytoplasm, more commands to make admins' lives easier, and reworked Matrix->XMPP formatting in order to make it more pleasant.

I've also dabbled in some MbedTLS support, but it is still unstable(and slow), done slightly more work with avatars, and fixed some known bugs that would make handling Parsee annoying.

As of next(v0.3 will probably be out by 2025), I am mostly working on optional Janet extension support, to make Parsee even more powerful and extensible.

We're still available over at Matrix and XMPP(xmpp:marsee@conference.monocles.eu) if you want to try it out.

🔗Dept of Clients 📱

Benedict says

We released a new version of Tammy including some UI fixes for older Android devices. For those who are hearing about Tammy for the first time: Tammy is a new multiplatform Matrix messenger powered by Trixnity Messenger.

🔗Quaternion (website)

A Qt5-based IM client for Matrix

kitsune says

This is the first 0.0.97 pre-release primarily focused on migration to libQuotient 0.9. Not much to talk about aside from this. The release notes and some prebuit binaries can be found at the usual place.

🔗Element X iOS (website)

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

Mauro Romito says

• A new RC for EX iOS will soon be released 1.9.5
• In the new RC EX iOS will be capable of also receiving verifications requests through the SAS protocol (while before was only able to send them)
• We also added a toggle to enable media optimisation that will process media files, to save up data and memory space by compressing them. The option is on by default but can be turned off
• The work for implementing sending, receiving and accepting/declining knocks on rooms is progressing
• Alongside knocking we are also implementing management of room aliases

🔗Dept of Services 🚀

🔗Synapse Admin Updates

Aine [don't DM] reports

A while back, we at etke.cc announced our Synapse-Admin fork, and this week we're excited to share more new features, QoL changes and bug fixes!

We'll begin by discussing technical and under-the-hood updates before moving on to UI features.

SYNAPSE_ADMIN_VERSION env variable

Starting from the least interesting - if you want to build Synapse Admin yourself in an environment where git is unavailable, you can now use SYNAPSE_ADMIN_VERSION env var to set version, instead of relying on git tags.

Logout that actually does the job

Earlier, the logout did send a request to the Matrix logout API endpoint, but didn't clean up things like local storage that is used as a state/session store. Well, now it does 🤷

Proper restrictBaseUrl despite its type

Previously, you could limit Synapse Admin instance to work with specific homeserver(-s) using the restrictBaseUrl config var that accepted both string (like "restrictBaseUrl": "https://example.com") and slice (like "restrictBaseUrl": ["https://example.com", "https://example.net"]). Such an approach has proven to be problematic in multiple cases, but today the last inconvenience with it has been solved - now single-item slices will be treated the same way as the string does (and yes, they are treated differently in the UI), using the only value of the slice.

Configuration in /.well-known/matrix/client

We found out that people tend to use Synapse Admin instances hosted outside their actual servers, and even use a single Synapse Admin instance to manage multiple servers. Unfortunately, such a setup means you can't rely on the config.json file that comes with Synapse Admin instance because it won't contain server-specific configuration… So, here is the solution - just add configuration to your /.well-known/matrix/client file under cc.etke.synapse-admin key, here is an example of how to mark mautrix-telegram puppets as appservice-managed users:

{
  "cc.etke.synapse-admin": {
    "asManagedUsers": ["^@telegram_[a-zA-Z0-9]+:example\\.com$"]
  }
}

works for any config option

Generate random passwords with ease

when creating or updating users. With this change, a new button has been added to the user's create/update form where you can generate a random password in 1 click.

Experimental Features and Rate Limits controls are here!

Now you can enable specific Experimental Features per user, and adjust user's rate limit overrides on the user's page.

Source code, admin.etke.cc (CDN version), say hi in the #synapse-admin:etke.cc

🔗Matrix Federation Stats

Aine [don't DM] announces

collected by MatrixRooms.info - an MRS instance by etke.cc

As of today, 10391 Matrix federateable servers have been discovered by matrixrooms.info, 3184 (30.6%) of them are publishing their rooms directory over federation. The published directories contain 22281 rooms.

Stats timeline is available on MatrixRooms.info/stats

How to add your server | How to remove your server

🔗That's all I know

See you next week, and be sure to stop by #twim:matrix.org with your updates!

To learn more about how to prepare an entry for TWIM check out the TWIM guide.

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.

🔗Key dates

• Conference dates: 1st and 2nd February, 2025
• Devroom date: 2nd February, 2025
• Submission deadline: Sunday, 1st December, 2024
• Announcement of selected talks: Friday, 15th December, 2024

You must be available in person in Brussels to present your talk.

🔗Talk Details

The talks can follow 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

We strongly encourage you to prepare a demo when it makes sense, so people can actually see what your work looks like in practice.

Of course, the proposal must respect the FOSDEM terms as well:

The conference language is English. All content must relate to Free and Open Source Software. By participating in the event you agree to the publication of your recordings, slides and other content provided under the same licence as all FOSDEM content (CC-BY).

🔗Code of Conduct

All speakers and attendees agree that all of the presentations and discussions in our devroom are held under the guidelines set in the FOSDEM Code of Conduct. We expect attendees, speakers, and volunteers to follow the CoC at all times.

If you have any questions about the CoC or wish to have one of the devroom organisers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you.

🔗Submitting a Proposal

Proposals must be submitted on FOSDEM's conference management system: https://pretalx.fosdem.org/. Heads up that last year FOSDEM shelved the good old Pentabarf in favour of Pretalx. All submissions must go through Pretalx: https://pretalx.fosdem.org/fosdem-2025/cfp. When submitting a proposal, make sure to select the Matrix.org Foundation & Community track.

We expect to receive more requests than we have slots available. The devroom organisers will be reviewing the proposals and accepting them based on the potential positive impact the project has on Matrix, as defined in the Mission section of https://matrix.org/foundation.

If a project proposal has been turned down, it doesn't mean we don't believe it has good potential. Maintainers are invited to join the #twim:matrix.org Matrix room to give it some visibility.

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

Between these, we believe that Matrix can now be used to build apps which genuinely outperform the mainstream alternatives - and what’s more, these MSCs now all have implementations you can use today. The MSCs themselves are not all finalised and ready for merge (but are getting close), and when they pass FCP (Final Comment Period) to merge into the spec, we will formally bump the spec release to version 2.0.

We actually declared Matrix 2.0 as ready for action back at The Matrix Conference last month, and now that the videos have been published you can watch the launch right here:

Today's Matrix Live: https://youtube.com/watch?v=ZiRYdqkzjDU

Since the conference talk things have already moved on a bit, though, and we’ve landed a bunch of tweaks to address teething issues - and so here’s the current state of action:

🔗1. Simplified Sliding Sync

Simplified Sliding Sync is the final version of Sliding Sync - the API which provides instant login, launch & sync in Matrix 2.0. To say that the API has been through a lot of iterations is an understatement, but we’re finally there with MSC4186, which simplifies the original Sliding Sync API (MSC3575) by removing the concept of a server-determined room list ordering entirely, and instead lets the client sort the roomlist as needed (while letting the client paginate in the roomlist incrementally, to ensure instant responsivity, no matter how large your room list is).

Simplified Sliding Sync is now implemented natively in Synapse as of 1.114, and so there is no longer any need to run a Sliding Sync Proxy in order to use the API. In fact, the Sliding Sync Proxy is being deprecated and the old Sliding Sync code will be removed from matrix-rust-sdk in the nearish future. Unfortunately we don’t have bandwidth to maintain both the native implementation Synapse as well as the proxy shim - and the proxy inevitably has suffered from a lot of limitations (e.g. having to do a full v2 initial sync for new logins, slowing them down to v2 performance - as well as duplicating storage between Synapse and the proxy). There’ll be a dedicated deprecation blog post for the proxy and pre-simplified Sliding Sync shortly. Meanwhile, work is well underway for native Sliding Sync support in conduit, conduwuit and grapevine - conduwuit guesses “next few weeks” for native Simplified Sync Support to land. Dendrite is unfortunately still not funded, so will happen on a best effort basis.

In terms of performance, native Simplified Sliding Sync in Synapse is spectacular - outperforming the proxy throughout, and making the old sync v2 API look positively prehistoric. Gone are the days of waiting for your app to sync, even if you’ve been offline for weeks/months; gone are the days of waiting minutes to login, and gone are the days of staring at a spinner as your app launches. It really is a new era - and having been hyping it since the first demo at FOSDEM 2023, I promise we won’t bang on about sliding sync any more after this; it’s finally here and landed and we can move on and enjoy it! For more details, see Ivan’s talk from The Matrix Conference:

Today's Matrix Live: https://youtube.com/watch?v=kI2lSCVEunw

🔗2. Next Generation Auth

Next Generation Auth is what we’re calling the migration to using industry standard OpenID Connect as the authentication API in Matrix 2.0, moving on from the custom auth API that Matrix has historically used. We’re calling this Next Gen Auth because we were seeing a lot of folks incorrectly assuming that adopting OpenID Connect for auth meant we would somehow be encouraging 3rd party social login or single-sign-on - which is not the case.

Next Gen Auth is simply swapping out Matrix’s old custom auth APIs with equivalents which are defined by the OpenID Foundation; after all, Matrix is a communication protocol, not an authentication protocol. In return, we get much more mature and secure authentication APIs - and access to the whole OpenID Identity Provider ecosystem, including support for Two Factor Auth and Multi-Factor Auth, hardware authentication tokens, passkeys, and device-based login flows (aka QR Login). We also stop both Matrix clients and servers having to implement the sprawling legacy Matrix authentication API surface - ensuring that users only ever hand their account password to their auth server, rather than having to trust their clients to handle it securely, which in turn plays much nicer with password managers (who only have to remember how to auth with your auth server, rather than a myriad different clients). It also lets you share authentication between apps if you want; gives us access_token refresh (at last!) to avoid long-lived access_tokens hanging around; and in future will also support OIDC scopes so you can limit the access particular clients get to your account.

In short, Next Gen Auth is transformative, and the initial implementation at matrix-authentication-service (MAS) is ready for admins to deploy and use (and in future will be available embedded in Synapse too). Unfortunately it is not yet live on matrix.org (given we have to migrate tens of millions of accounts, complete with all the social login complexities) but we’re hoping to get it there in the coming months.

Probably one of the clearest immediate benefits of Next Gen Auth is the ability to do a full login including setting up all your end-to-end-encryption simply by scanning a QR code on an existing client, courtesy of MSC4108 and OAuth 2.0 Device Authorization Grants. In other words, you don’t have to specify a server, or your username, or account password, or your recovery key - you just scan a QR code and you’re in. The very latest Element X releases on iOS & Android have this implemented and enabled by default, and so if you’re on a server which has deployed MAS, you can go to “link new device” in Element Web/Desktop to show a QR code to instantly log in.

For more info on all things Next Gen Auth, see Quentin’s talk from The Matrix Conference:

Today's Matrix Live: https://youtube.com/watch?v=wOW8keNafdE

🔗3. Native Matrix Group VoIP/Video: MatrixRTC

Next we have MatrixRTC: end-to-end-encrypted group voice and video conferencing over Matrix. Historically, group VoIP in Matrix has relied on third party conferencing systems (Jitsi, and before that FreeSWITCH) - providing no support for Matrix’s end-to-end encryption, or indeed Matrix’s user identities, decentralisation or decentralised access control.

With MatrixRTC this changes: we now have a standard way to establish large-scale end-to-end-encrypted group video calls via Matrix, leveraging all the benefits of Matrix’s end-to-end-encryption infrastructure, user identity, room permissions, etc. It also supports different media stacks to actually handle the media conferencing - today, the main implementation uses the LiveKit SFU, but there’s also an experimental full-mesh WebRTC implementation.

Element Call has been the driving app behind MatrixRTC, and as of today is now enabled in the release versions of both Element Web/Desktop and Element X to provide native MatrixRTC calling embedded in the apps: if you hit the video call button you will now have the option to spin up a MatrixRTC call via Element Call rather than via Jitsi or Legacy 1:1 calling, and if the room is end-to-end-encrypted, all the conference will be too.

Meanwhile - MatrixRTC isn’t just Element Call: Famedly showed off experimental interop with FluffyChat at FOSDEM back in Feb, and Element showed off experimental interop with BigBlueButton in August. Given more and more conferencing tools are converging on LiveKit as a best-in-class SFU, it’s an amazing opportunity to use Matrix and MatrixRTC to power the end-to-end-encryption and decentralisation and get standardised voip/video interop from the outset.

For more info, see Timo’s talk from The Matrix Conference:

Today's Matrix Live: https://youtube.com/watch?v=OXPuYbfiXDQ

That said, there are a few caveats right now:

• We do not have interoperability between legacy Matrix 1:1 voice/video calling and MatrixRTC (and it’s not clear if/when we will get to it) - but Matrix 2.0 clients like Element X exclusively use MatrixRTC for VoIP/video, including for 1:1 calls. This is in order to only maintain one VoIP stack, and so that you get multidevice and multiuser support for free, even in 1:1s. As a result, we’re in the process of figuring out how to warn legacy callers that MatrixRTC-only clients won’t be able to answer their calls (e.g. MSC4220) - this hasn’t shipped yet.
• iOS 18 broke CallKit + WebRTC, so Element X iOS has had to disable fancy OS-natively-integrated MatrixRTC calling; and has a support issue open with Apple to try to solve this.
• We’ve had some fun teething issues thanks to the volume of signalling in MatrixRTC exposing some sync bugs - these are almost solved, but probably mean MatrixRTC should still be considered beta for a few more days until the fixes land.

🔗4. Invisible Encryption

The final pillar of Matrix 2.0 is Invisible Encryption - making Matrix’s end-to-end encryption as seamless and invisible as the centralised alternatives (Signal, WhatsApp, iMessage and friends). This does not mean reducing security in any way - just the opposite, in fact. It means:

1. Ensuring that Unable To Decrypt (UTD) bugs never happen. Huge amounts of work has gone into this over the course of the year, especially via complement-crypto as a comprehensive end-to-end-test suite for both matrix-rust-sdk and matrix-js-sdk based Matrix clients. We are finally at the point where UTDs are so rare that most people simply never see them, and any reports get jumped on (and complement-crypto tests get written) whenever they emerge. Anecdotally, I now get way more “waiting for message…” errors on WhatsApp than I do on Matrix, these days! For more details on the Hunt For UTDs, see Kegan’s talk from The Matrix Conference:

Today's Matrix Live: https://youtube.com/watch?v=FHzh2Y7BABQ

2. We are excluding non-cross-signed devices from Matrix (MSC4153). The fact that Matrix ever supported the idea of users enabling encryption on a device without proving that they are the valid owner by signing it (by verifying it with another device, or providing their recovery key/passphrase) is a nasty hangover from back before we introduced cross-signing. Nowadays, the fact that non-cross-signed devices exist acts to reduce security and complicate UX and implementations with big scary red warnings whenever an unverified device joins a conversation. Instead, once MSC4153 lands, we’re going to simply exclude unverified devices entirely - not encrypt to them, and not decrypt from them. We can then get rid of all the confusing warnings associated with them.

3. We’re also solving the confusing “grey shield” warnings: “the authenticity of this message cannot be confirmed on this device” and similar. These are avoidable warnings caused by message keys which can no longer be tracked back to the original sender - e.g. if they’re restored from backup, or if the original sending device has been deleted. We’re fixing these with authenticated backup (MSC4048) and including device keys on Olm events (MSC4147) respectively.

4. Finally, we’re moving to Trust On First Use (TOFU). This means that even if you didn’t explicitly verify another user, you still get warned if their identity changes (unlike previously, when it was ignored). An initial implementation just landed in matrix-rust-sdk a few weeks ago, and so appropriate warnings at the application level should arrive shortly - matching the equivalent Signal or WhatsApp “this user’s identity has changed” warnings, albeit not yet synced between devices.

As you can probably tell, Invisible Encryption is something of a moving target; for instance, the scope could extend to cover all scenarios where users might expect messages to be decryptable (e.g. Dehydrated Devices: the ability to decrypt messages sent to you when you are not logged in anywhere - or Sharing Keys when new users join a room/space). However, the 4 points above are the main ones, and they are in the process of landing right now.

The end result is already an immeasurable improvement in the reliability and robustness of Matrix’s encryption - and once the remaining pieces land, the user experience of a Matrix client should be that the encryption is almost entirely invisible to the user - unless something bad is happening; much like TLS.

Valere & Patrick’s talk on Invisible Crypto from The Matrix Conference would get embedded here, but unfortunately the audio was mangled - we’ll rerecord it and publish it shortly. In the meantime, you can find their slides here.

🔗What’s next?

Well, first of all we’re going to stop announcing Matrix 2.0 - it’s finally here (modulo the spec release)!

There’s obviously a bit of follow-up still to be done though:

• Getting MAS live on matrix.org
• Gracefully handling the lack of interop between legacy Matrix calls and MatrixRTC
• Landing the various remaining components of Invisible Crypto
• Broadening the implementation base for these APIs, and rolling it out across the ecosystem

Beyond Matrix 2.0, though, there’s a large pile of other areas which need attention:

• Improving state resolution. We’re currently investigating a set of issues where the merge resolution algorithm has misbehaved, and are planning a new room version to address it - watch this space for updates.
• Trust and Safety. Abuse is increasing concern, and moderation and trust & safety tooling work has ended up fragmented and balkanised. The Governing Board is putting together a cross-ecosystem working group to try to address this - again, watch this space for updates.
• All the business-as-usual MSCs which have stacked up - Custom Emoji, Extensible Profiles, Custom Presence, etc.
• It’d also be good to finally realise the full performance advantages of faster room joins…

And then, in the longer term - what might Matrix 3.0 bring? Honestly, at this point, it’s an open question. Could it be landing major Trust & Safety changes in order to radically empower users to avoid and mitigate abuse? Could it be switching to MLS (or Decentralised MLS) for encryption? Could it be the glorious return of P2P Matrix (if it was funded)? Could it even be figuring out if/how to converge with (or layer on top of) MIMI or other federation protocols? Answers on a postcard to #sct-office:matrix.org please!

🔗Conclusion

If ever there was a time to exhort your friends to give Matrix another go - this is it.

Matrix 2.0 has been a long time coming, and we need to get the word out that the step change forwards has finally arrived, and that apps built on Matrix 2.0 can seriously outperform the mainstream alternatives. Ideally, this could be Matrix’s “Firefox moment” - when from the ashes of old open source code, a new generation appears which can punch its weight against the proprietary incumbents.

Right now the only Matrix 2.0 client is Element X (and Element Web/Desktop if you enable the experimental Simplified Sliding Sync implementation in labs on develop/nightly builds) - see element.io/blog for full details - but we expect to see at least matrix-rust-sdk and matrix-js-sdk based clients using the new APIs as a matter of course in the coming months, and then hopefully everyone else too.

So: if you run a Matrix server, please consider deploying MAS to enable next-gen auth (Sebastien Spaeth’s blog also has a good indie tutorial) - and add Element Call to give MatrixRTC a try. Over the coming months we should see more support in more Matrix distributions, until hopefully we will all be living in a Matrix 2.0 world!

Huge thanks are due to everyone who has helped design, build, and iterate on Matrix 2.0, and to everyone who has kept the faith as we’ve put it all together. A special thanks also to BWI who helped fund much of Element’s work on this for the benefit of Matrix as a whole.

Finally, if you want Matrix to prevail - please join the Foundation and support the project financially. We urgently need organisational members, especially after the costs of running The Matrix Conference, and particularly if your organisation is commercially dependent on Matrix, you simply must become a member. While it’s very flattering that Matrix gets treated as a commons these days, without financial support the underlying Matrix project will die and your project will fail. Whereas if everyone building on Matrix supported us, we would be moving way faster and with fewer constraints - so please get involved at matrix.org/support and help.

Thanks for flying Matrix!

Matthew

🔗Matrix Live

Today's Matrix Live: https://youtube.com/watch?v=5q3njjtlaVU

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

🔗Dept of Servers 🏢

🔗Synapse (website)

Synapse is a Matrix homeserver implementation developed by Element

Andrew Morgan (anoa) {he/him} says

This week we released Synapse v1.118.0rc1. The major thing to be aware of is that Python 3.8 is now end-of-life. As per our Deprecation Policy for Platform Dependencies, Synapse will be dropping support for Python 3.8 in the next release; Synapse 1.119.0.

Otherwise, Synapse 1.118.0 is the first release to support Python 3.13! PostgreSQL 17 is also supported as of this release.

Other highlights in this release include an experimental implementation of MSC4210: Remove legacy mentions, and the ability to set one's display name upon registering via JWT. In addition, there's the usual round of bugfixes and internal changes. See the release changelog for the full details!

🔗Dept of Clients 📱

🔗Extera

OfficialDakari says

Some improvements for Extera are made. Here is what I've changed:

• Reaction styles. I've completely redesigned reactions in messages.
• Perfect browser back button handler. Primarily it's made for mobile. Now you can close modal dialogs with back button, and it works.
• Custom CSS themes! Now you can add Custom CSS Themes to Extera.

Also, here are upcoming things:

• Custom JS plugins. You will be able to inject JavaScript into Extera, like themes.
• Custom AI bots with persona (on extera.xyz homeserver). I will announce in Extera's chat when AI platform for Matrix will be out. Users will be able to create AI bots with GPT-4o + custom system prompt and more.

Best regards, Extera team developer

🔗Element X iOS (website)

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

Doug reports

• Element X iOS 1.9.3 is in TestFlight and will be available next week. It adds support for rendering media captions in the timeline, showing verification badges when looking at a room member’s details and fixes a bug with media upload where we sometimes included an incorrect image size.
• Work on support for Knocking continues and we’re currently updating the Reaction Picker to include a Frequently Used section so you don’t have to hunt for your favourite emoji all the time.
• Version 1.9.3 is the last version of Element X iOS that will support iOS 16. The next version we will release will require iOS 17 or 18 as we prepare the way to fix some longstanding bugs that should be addressed by using newer SwiftUI components.

🔗Dept of Widgets 🧩

🔗Matrix Widget Toolkit

Kim Brose (Nordeck) reports

It's been a bit over a month since we updated our Matrix Widget Toolkit to the newest MUI, React, Redux, and Matrix versions just before the Matrix Conference, so we are happy to share the newest update with you today.

While the list isn't long, it is quite significant. We migrated away from Facebook's Create React App (CRA) framework in favour of the new and actively maintained Vite framework (mind the French pronunciation 😉). This allows us to update some dependencies with known issues that were kept back behind CRA. Along with that, we also swapped out our testing framework from Jest to the Vite-native Vitest. If you're consuming the toolkit, you might already be using our @matrix-widget-toolkit/testing package, which conveniently exposes a helper to mock the widget API. These breaking changes caused us to release a new major version of the testing package.

With that, up-to-date package versions of the toolkit components are now:

• @matrix-widget-toolkit/testing@3.0.1, based on vitest
• @matrix-widget-toolkit/api@3.4.2, @matrix-widget-toolkit/mui@2.0.6, @matrix-widget-toolkit/react@2.0.3, all now tested using vitest
• @matrix-widget-toolkit/widget-server@1.0.6, with a slightly newer nginx as its base

All the packages can be found in the releases section of our repo.

You can see a demo of what the toolkit can do using our demo widget.

If you have any questions or feedback, please reach out to us using our public room #nordeck:matrix.org.

🔗Dept of SDKs and Frameworks 🧰

🔗Trixnity (website)

Multiplatform Kotlin SDK for developing Clients, Bots, Appservices and Servers

Benedict says

A new release of Trixnity is out. It supports files larger than 2.1GB now, has some API improvements and there are some new helpers regarding file handling. Additionally a few bugs has been fixed. Matrix 1.12 support is also implemented, but will be part of the next release.

🔗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

bnjbvr says

Hello everyone! Here's for the first Matrix Rust SDK update for a long time, for updates which happened this week, as generated by our new release process helper! More news about a new Matrix SDK release coming Soon™.

🔗SDK

• Support for preallocated media content URI has been added in Media::create_content_uri(), and uploading the content for such a preallocated URI is possible with Media::upload_preallocated().
• Uploaded medias can now be cached in multiple attachment-related methods like Room::send_attachment.
• When SendAttachment::store_in_cache() is set, the thumbnail is also cached with a sensible default media request (not animated, scaled, same dimensions as the uploaded thumbnail).
• RoomListService::subscribe_to_rooms no longer has a settings argument.
• Room list service: Add m.room.topic and m.room.pinned_events in all_rooms.
• Room list service: Add the m.call.member state event in the required state.
• (internal) Event cache: Dropping a LinkedChunk UpdatesSubscriber release the reader token for the GC.

🔗Crypto

• We now persist the error that caused an event to fail to send. The error QueueWedgeError contains info that client can use to try to resolve the problem when the error is not automatically retry-able. Some breaking changes occurred in the FFI layer for timeline::EventSendState, SendingFailed now directly contains the wedge reason enum; use it in place of the removed variant of EventSendState.
• Add more reason codes to UtdCause.
• matrix_sdk_crypto::type::events::UtdCause::Membership has been renamed to ...::SentBeforeWeJoined.
• Don't warn about verified users when subscribing to identity updates.

🔗Matrix Dart SDK (website)

Matrix SDK written in pure Dart.

🔗Matrix Dart SDK (website)

td says

meep quick major version release twim announcement -

🔗v0.34.0

• Powerlevel updates are no longer local echo'd, we wait for the update to come down sync.
• Fix a ton of edgecases parsing message bodies
• We also added v1.12 endpoints support.
• Auto-generated objects now also have proper equality and hashcode overrides so you can just compare 2 objects now.

That's it for now, see you soon bye byee

🔗libQuotient (website)

A Qt5 library to write cross-platform clients for Matrix

kitsune announces

🔗libQuotient 0.9.0

After a few release candidates, the new stable branch and the new version of libQuotient are officially released! Matrix 1.12 under the hood, cross-signing support (finally in stable), lots of refactoring and cleanup after transition to Qt6-only code and a flurry of smaller features and fixes. The release notes are where you would expect them.

🔗Elm SDK (website)

A more consistent alternative to the matrix-js-sdk, written in Elm.

Bram says

🔗Elm SDK beta 3.6.0

Despite being a minor update, the number of new features is major! The beta 3.6.0 Elm SDK update adds the following features:

• Added Matrix.Room.getState to explore a room's state
• Added Matrix.leave to leave rooms
• Added Matrix.Invite module
• Added Matrix.Event.redact and Matrix.Room.redact to redact events
• Added Matrix.Room.name, Matrix.Room.topic & Matrix.Room.pinned_events to quickly access the most commonly used state events

Additionally, using backwards compatibility, the Elm SDK now supports ALL official spec versions! (Including historical ones.) This means that you can safely update the Elm SDK without needing to wait for your homeserver to update. You can now view the supported versions document for an in-depth table.

🔗Dept of Ops 🛠

🔗matrix-docker-ansible-deploy (website)

Matrix server setup using Ansible and Docker

Slavi reports

matrix-docker-ansible-deploy now supports installing and configuring Matrix Authentication Service (MAS).

Huge thanks to Quentin Gliech from the Element / Matrix Authentication Service team for answering our numerous questions about MAS.

Our Setting up Matrix Authentication Service documentation page has more details about this new service, what you might expect from the switch and how you can migrate your existing (Synapse) homeserver setup to it.

🔗Dept of Services 🚀

🔗Synapse-Admin

Aine [don't DM] reports

A while back, we at etke.cc announced our Synapse-Admin fork, and we're excited to share more QoL changes and a new feature

• Separate login button for access token auth - that doesn't depend on the login mechanisms advertised by homeservers
• Better footer implementation - no more content overlapping, no more unnecessary scrollbar
• Fixed room state events display, including displaying of external users - the content (and sender) are visible now
• User profile in the top menu - now you will see your avatar and displayname instead of a placeholder in the top menu
• Enable visual customization - adjust the display of various tables to your liking, e.g. hide unnecessary columns in the user list
• Custom menu items - evolution of the previously implemented Contact support button, now you can set your own custom menu items using menu key in config.json

Apart from that, the #synapse-admin:etke.cc room has been created - do not hesitate to say hi!

Source code, admin.etke.cc (CDN version)

🔗Dept of Bots 🤖

🔗Draupnir (website)

Gnuxie 💜🐝 reports

Draupnir, a moderation bot, has released v2.0.0-beta.8. This release includes improvements to safe mode, we now show which persistent configuration properties have caused Draupnir to enter safe mode. We also have made a few changes to Draupnir's logging to give system admins feedback on how Draupnir is configured. For all the details, check the release notes.

I've also written a blog update about what I have been working on over the last month or so and I also talk through an update to the Draupnir roadmap.

https://marewolf.me/posts/draupnir/2406.html

Please note that in this release the minimum node.js version required to run Draupnir has been updated from Node 18 to Node 20. If you are using Debian, please follow our documentation for using Debian and node source here, which was kindly contributed by Sky.

If you have any questions or need help with anything related to Draupnir, please find us in our support room at #draupnir:matrix.org.

🔗Matrix Federation Stats

Aine [don't DM] reports

collected by MatrixRooms.info - an MRS instance by etke.cc

As of today, 10274 Matrix federateable servers have been discovered by matrixrooms.info, 3145 (30.6%) of them are publishing their rooms directory over federation. The published directories contain 22149 rooms.

Stats timeline is available on MatrixRooms.info/stats

How to add your server | How to remove your server

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

🔗#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	conduwu.it	151
2	transgender.ing	185
3	envs.net	192.5
4	tomfos.tr	197
5	awawawawawawawawawawawawawawawawawawawawawawawawawawawawawawaw.gay	203
6	pissing.dev	208
7	constellatory.net	233.5
8	girlboss.ceo	251.5
9	nerdhouse.io	256
10	synapse.rntpts.de	292.5

🔗That's all I know

See you next week, and be sure to stop by #twim:matrix.org with your updates!

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

Today's Matrix Live: https://youtube.com/watch?v=b1jJlT2ENT8

Dept of Clients 📱

Extera

OfficialDakari reports

Hello, everyone!

During this week, a few things happened in Extera. Here is what changed:

• Animations. Now, Extera has some animations in it. Member drawer opening/closing animation or navigating animation.
• More material design. We made emoji&sticker pack settings use Material Design too.
• A lot better threads! Threads are now really nearly usable. They now have different routes too.
• Message menu in material design. Deleting and reporting messages form has Material Design too.

Our server got some changes too:

• Federation is now happening through Cloudflare WARP.
• We've got Git instance!

Also, we've started actively working on Extera Music (name is subject to change) - our alternative front-end for YouTube with playlists and a lot of cool things.

Nheko (website)

Desktop client for Matrix using Qt and C++17.

Nico announces

Nothing much interesting to say currently, but one thing might be interesting to Nheko users:

We noticed that http/3 increases the CPU usage of Nheko a lot (by 10-20x!) and makes the connection in general unstable. We use libcurl in the backend and depending on your distribution http/3 might get enabled by default. In my case this meant even when idle Nheko was using 10% or more CPU. The next release will disable http/3 by default for this reason. In my case this brings down CPU usage to 0.5% again, which is a noticeable improvement to battery life.

Why the CPU usage increases this much with http/3 has a multitude of reasons (and isn't libcurl's fault, but more related to how http/3 works as well as some crypto library shenanigans). I won't go into the details there, but feel free to discuss this in #nheko:nheko.im. Specifically we were hoping for http/3 to improve the reconnection logic and make roaming between IPs a better experience. So far the opposite seems to be the case, but if you have any suggestions on what we could improve, they are very welcome!

Dept of Widgets 🧩

NeoBoard Widget v1.20.0 (website)

milton announces

Version 1.20.0 of NeoBoard is a small incremental update following 1.19.1 after a short month with a presentation at The Matrix Conference. This version brings the following updates:

Disable Grid During Presentation

We made the Presentation Mode easier to use by disabling the grid automatically when starting to present, and restoring it after presenting. Of course if you need it, you can still toggle it back on during presentation.

Small Screen Improvements

We also tweaked the bottom toolbars a bit: Some of the less important buttons are now hidden automatically so NeoBoard remains usable even when the available screen space is narrow. Enlarge the window, and they will reappear. 🪄

While we were at it, we also fixed an alignment issue in Safari, so we have the same experience on all platforms.

You can get the full release notes here and here's a reminder that you can always try it now: just add NeoBoard as a widget to one of your rooms by following these instructions.

We invite you to try all of this and would love to get some feedback at #nordeck:matrix.org.

Dept of SDKs and Frameworks 🧰

Elm SDK (website)

A more consistent alternative to the matrix-js-sdk, written in Elm.

Bram announces

Zoooom! 🏎️ The Elm SDK now supports all spec versions, including the new version 1.12!

With this patch update, support now includes version 1.12 - but don't worry, old (even deprecated!) spec versions remain supported. The Elm SDK adapts its communication to whatever your homeserver supports, so you can safely update your Elm library without needing to wait for your homeserver to update. This design makes the SDK nearly trivial to update to the latest spec version - and hence very fast. Zoooom!

Dept of Ops 🛠

etke.cc (website)

Your matrix server on your conditions

Aine [don't DM] says

Synapse-Admin: Bugfixes & Improvements

A while ago, we at etke.cc announced our Synapse-Admin fork, and this week we are here with the fork news again.

No significant changes were made this week (however, MAS users will like the-next-big-thing, even tho it's a workaround), this is more maintenance release with small QoL improvements:

• Better handling of restricted homeservers config
• Better federation page UI - now with icons!
• Fix avatar sorting - apparently, the avatar field's sorting in the user's list was broken after the React-Admin upgrade

Source code

Dept of Bots 🤖

communitybot plugin for maubot (website)

wreck announces

quick reminder for the uninitiated: the communitybot plugin is a maubot plugin to aid administrators of communities on matrix! it supports community management controls to make it easy to add new rooms to your Space, track inactive users, redact files or offensive messages in some or all of your rooms, and keep out the ne'er-do-wells.

with the latest update for the communitybot plugin for maubot, you can now have your bot subscribe to public ban lists by having your bot join their room (like the CME banlist, included in the config by default!). when subscribed, the bot will automatically ban malicious/spam accounts when they join any of your rooms. this is read-only functionality, so if you're interested in publishing or defining your own policy lists, you will still be better served by a project like Draupnir.

which begs the question: who should use this? the answer, as well as suggested community structure, are now in the readme. feel free to join #dev:mssj.me to discuss further or get help!

Matrix Federation Stats

collected by MatrixRooms.info - an MRS instance by etke.cc

Aine [don't DM] reports

As of today, 10152 Matrix federateable servers have been discovered by matrixrooms.info, 3118 (30.7%) of them are publishing their rooms directory over federation. The published directories contain 22188 rooms.

Stats timeline is available on MatrixRooms.info/stats

How to add your server | How to remove your server

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.

#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	bark.arf.wf	174
2	conduwu.it	218
3	tomfos.tr	225
4	saneke.eu	269
5	constellatory.net	301
6	maunium.net	307.5
7	ncat.cafe	307.5
8	uwu.zemos.net	315
9	bi-vibes.com	319
10	transgender.ing	428

That's all I know

See you next week, and be sure to stop by #twim:matrix.org with your updates!

Hey all,

Welcome to the Matrix 1.12! It’s been just over 3 months since Matrix 1.11 introduced authenticated media, and today we’re bringing more Trust & Safety features to the ecosystem, alongside the normal clarifications and general improvements to the protocol. This release is also technically a few days late on the quarter, but it’s for good reason! Folks from across the ecosystem got together in Berlin for the Matrix Conference, and after things wrapped up we were busy following up on ideas started on site. We can’t wait to see all of these ideas materialize as MSCs, but in the meantime, back to the honorary Q3 release of the spec:

Matrix 1.12 marks the recommended date for all servers to enable their media freeze, similar to matrix.org’s back in early September 2024. Servers which haven’t yet enabled their media freeze are strongly encouraged to do so, if it makes sense for their users. Matrix 1.12 also brings some improvements and clarifications to authenticated media, and a total of 9 MSCs covering a wide range of features.

Read on for a few highlights, and the full changelog at the end of this post.

Account locking

Prior to Matrix 1.12, the available account states for a user were “active” and “deactivated”, with no options for in-between or less destructive states. MSC3939 adds a new state, “locked”, to the mix which preserves the user’s account, but logs them out and doesn’t let them back in until the lock is removed. This new state could be used to prevent an attacker from brute forcing an account, handling out of band verification, or be a reaction to a moderation/terms of service decision. The server admin can then later reverse the lock with no impact on the user’s rooms, messages, or account information, unlike with deactivation.

When paired with MSC3823-style suspension, server admins have more non-destructive options to stop a user’s pattern of behaviour. They can completely kick the user out of their account with locking, or allow them to continue using the account in “read only” mode. MSC3823 is pending some implementation checks at the moment, but is expected to land in the next couple of releases.

Clients looking to implement locking or suspension will need to look at error codes, and continue calling /sync to determine when the account state changes (either back to active, or deactivated). MSC3939 and MSC3823 both have suggestions for what the UI might look like for a client as well.

Marking rooms as unread

Finally, it’s possible to mark a room as “unread” after reading it. The existing read receipts structure makes this a uniquely difficult task to do traditionally, but MSC2867 found a way to get the same effect using account data instead. This approach doesn’t always maintain the unread message count, if it can even be calculated, but does offer users an ability to mark a room as something to come back to.

Client implementation can be a bit tricky when interacting with the overall notification system, but some may find it easy to add support for. In future it may be possible to mark individual messages as unread, or have the server calculate unread-ness over Simplified Sliding Sync, for example.

Up next in Matrix 1.13 and beyond

Matrix 1.13 is expected to be released between late November and early December 2024. Many of the Matrix 2.0 features are undergoing finishing touches, particularly on the MSC side, and may also be ready for inclusion in the spec release. Meanwhile, we’re keeping an eye on MSCs proposed for Final Comment Period, and taking suggestions for MSCs which may be ready for the next stage in the process: if there’s something you think is ready for FCP, let us know in the SCT Office room!

The full changelog

The full changelog for Matrix 1.12 is:

Client-Server API

Deprecations

• Deprecate the server_name query parameter on POST /_matrix/client/v3/join/{roomIdOrAlias} and POST /_matrix/client/v3/knock/{roomIdOrAlias}, as per MSC4156. (#1933)

Removed Endpoints

• Remove references to device-specific push rules. (#1842)
• Remove the deprecated name attribute on HTML anchor elements, as per MSC4159. (#1870)

Backwards Compatible Changes

• Add 403 responses on GET /_matrix/client/v3/profile/{userId}/avatar_url and GET /_matrix/client/v3/profile/{userId}/displayname, as per MSC4170. (#1867)
• Add support for marking rooms as unread, as per MSC2867. (#1895, #1941)
• Add via query parameter on POST /_matrix/client/v3/join/{roomIdOrAlias} and POST /_matrix/client/v3/knock/{roomIdOrAlias}, as per MSC4156. (#1933)
• Add account locking, as per MSC3939. (#1934)
• Guest accounts can now download/thumbnail media from the new authenticated endpoints, as per MSC4189. (#1959)

Spec Clarifications

• Rename and sort the modules in the feature profiles table for easier skimming. (#1855)
• Clarify that room avatars cannot be encrypted. (#1871)
• Document the acronyms and alternate names for the "Secrets" section. (#1875)
• Improve recommendation for how to form transaction IDs. (#1888)
• Clarify that the deprecated dont_notify and coalesce push rule actions MUST be ignored, not rejected. (#1890)
• Fix various typos throughout the specification. (#1892)
• Add missing references to m.set_displayname, m.set_avatar_url, and m.3pid_changes in capabilities table. (#1897)
• Clarify that the fallback login page calls window.matrixLogin.onLogin instead of window.onLogin. (#1899)
• Remove confusing description of restricted rooms with no valid conditions. (#1903)
• Clarify that window.matrixLogin.onLogin is called with the response body of POST /_matrix/client/v3/login. (#1905)
• Document the m.get_login_token capability, as per MSC3882. (#1908)
• Clarify that the User identifier object in POST /_matrix/client/v3/login contains additional properties that depend on the identification type. (#1909)
• Don't mention that GET /_matrix/client/v3/profile/{userId} can return additional properties because this is true for almost every endpoint. (#1910)
• Improve wording of the unauthenticated media deprecation box. Contributed by @HarHarLinks. (#1916)
• Additional properties in GET /.well-known/matrix/client don't have to be objects. (#1920)
• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)
• Specify Content-Type and Content-Disposition usage in the media repo, as per MSC2701 and MSC2702. (#1935)
• Additional keys in GET /_matrix/client/v3/capabilities don't have to be objects. (#1945)

Server-Server API

Backwards Compatible Changes

• Add 403 response on GET /_matrix/federation/v1/query/profile, as per MSC4170. (#1867)

Spec Clarifications

• Remove origin field from PDU example because it doesn't exist in the schema anymore. (#1918)
• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)
• Fix required fields in GET /_matrix/key/v2/server response schema. (#1930)
• Use "server name" instead of "DNS name" to avoid confusion with the "DNS name" component of "server names" as defined in the appendices. (#1946)

Application Service API

Spec Clarifications

• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)

Identity Service API

Spec Clarifications

• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)

Push Gateway API

Spec Clarifications

• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)

Room Versions

Spec Clarifications

• Fix a formatting issue in state resolution v2. (#1896)
• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)

Appendices

Spec Clarifications

• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)

Internal Changes/Tooling

Spec Clarifications

• The Matrix.org Foundation no longer requires "real" or "legally identifiable" names in order to contribute to projects. (#1886, #1914)
• Document the removal changelog category. (#1907)
• Use dedicated fonts for better support of mathematical symbols. (#1919)
• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)
• Provide markdown checklists for changelogs under /changelog/$VERSION/checklist.md. (#1937, #1954)
• Add the deprecated field to properties of OpenAPI definitions and JSON Schemas. (#1940)
• Use relative permalink to redirect to latest changelog. (#1956)

Matrix Live

Today's Matrix Live: https://youtube.com/watch?v=VZTvpGuo9aA

Dept of Spec 📜

The weekly spec update

Andrew Morgan (anoa) {he/him} announces

Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.

MSC Status

New MSCs:

• MSC4210: Remove legacy mentions
• MSC4209: Updating endpoints in-place
• MSC4208: Adding User-Defined Custom Fields to User Global Profiles
• MSC4207: Media identifier moderation policy
• MSC4206: Moderation policy auditing and context
• MSC4205: Hashed moderation policy entities
• MSC4204: m.takedown moderation policy recommendation
• MSC4203: Sending to-device events to appservices
• MSC4202: Reporting User Profiles
• MSC4201: Profiles as Rooms v2
• MSC4198: Usage of OIDC login_hint
• MSC4197: Copy Paste Hints

MSCs in Final Comment Period:

• MSC4170: 403 error responses for profile APIs (merge)

Accepted MSCs:

• MSC4189: Allowing guests to access uploaded media

Closed MSCs:

• No MSCs were closed/rejected this week.

Spec Update

Lots of interesting MSCs came in this week! Note that last week's are also listed as the spec update was skipped.

A swath are looking to improve moderation in Matrix, while others aiming to improve the story around notifications and end-to-end encrypted bridges. There's also been lots of discussion on the hot MSC4133: Extending User Profile API with Key:Value pairs, which can be built upon with spec'd profile fields such as m.timezone (MSC4175).

MSC4208 is the result of splitting out the custom fields portion of that MSC, as it was determined that that portion of MSC4133 needed further discussion before merging.

Finally, MSC4189: Allowing guests to access uploaded media being merged closes one of the final gaps with the authenticated media epic.

Dept of Servers 🏢

Synapse (website)

Synapse is a Matrix homeserver implementation developed by Element

Andrew Morgan (anoa) {he/him} says

This week we released v1.116.0. The highlights haven't changed since our announcement of v1.116.0rc2 last week. See the changelog for the full details.

Thank you to all our contributors for helping to make Synapse the best it can be. As always, feel free to stop by #synapse:matrix.org to join in on the discussion and if you encounter a bug make sure to report it on our issue tracker.

Dept of Clients 📱

Element-Web

tulir announces

My PR for rendering media captions was just merged into element web :3 https://github.com/element-hq/matrix-react-sdk/pull/43

This allows for a caption to be shown next to the media filename by adding support for the changes from MSC2530

Extera Material Design

OfficialDakari says

Last 5 days I was working on Material UI redesign as usual. Here is what changed:

• Speed dial button
• Profile edit window
• Room and space settings
• floating buttons in room timeline

Also I've brought back sound effects and Project Sekai related auth background. They are now stored locally (P.S.: Hardcoding Matrix Media URLs was the worst idea)

Element X iOS (website)

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

Doug announces

This week have have been working on "Identity Pinning Violation Notifications" (TOFU via the Rust SDK), the ability to hide images in the timeline for Trust & Safety purposes and we’ve started exploring what Knocking could look like in the app.

Dept of SDKs and Frameworks 🧰

Rory&::MatrixUtils - General utility suite for Matrix

Emma [it/its] reports

Tiny updates this week :)

A short list of major changes:

• You can now add sessions with an access token, this opens up usage of RMU to users of homeservers without password login. No more messing with localstorage!
• Fixed a bug with the policy list editor, that caused state keys to be double URL-encoded. You can now successfully edit and remove policies again!

The "first party" instance is available at https://mru.rory.gay, and is a clientside-only web app! If RMU has provided value in your daily routines or as a one time thing, please do consider donating over at Liberapay!

And, as with all of the other projects:

• The code is available at cgit.rory.gay!
  • All contributions are more than welcome, be it documentation, code, layout/UI/UX improvements, anything!
• Discussion, suggestions and ideas are welcome in #mru:rory.gay

Rory&::LibMatrix (website)

.NET 8 matrix bot/client library/SDK

Emma [it/its] says

A few bugfixes and bodges left and right :)

Changes

• Bots can now load their access tokens from a file! You're welcome, systemd users! 🔒
• Fixed and improved interoperation with tools like Draupnir. (Breaking: don't URL encode your state keys anymore!)
• Minor work towards packaging & potentially publishing to NuGet! Maybe LibMatrix in your local package repo soon? 🦊 👉👈
• Breaking: Room predecessor support has been removed. Thanks, #foundation-office:matrix.org!
• Rooms where a name had been set before but subsequently removed, should now correctly pick an alternative name to display. No more "< small void where text is supposed to be >".
• Made it easier to use custom types when reading events.
• You can finally add mentions and newlines to messages.

If you want to help out on these topics, please feel free to reach out at #libmatrix:rory.gay! (N.B. Sorry, matrix.org users, the room is currently inaccessible. We hope to have this resolved soon!)

And, as always:

• The code is available at cgit.rory.gay!
  • All contributions are more than welcome, be it documentation, code, anything! Perhaps, example usecases, bots, ...?
• Discussion, suggestions and ideas are welcome in #libmatrix:rory.gay (Space: #mru-space:rory.gay)
• Got a cool project that you're working on and want to share, using LibMatrix? Be sure to let us know, we'd love to hear all about it!

Dept of Services 🚀

etke.cc (website)

Your matrix server on your conditions

Synapse-Admin Updates

Aine [don't DM] reports

A while back, we at etke.cc announced our Synapse-Admin fork, and this week we're excited to share two major updates (yep, again):

• Authenticated Media support
• Options to remove media and redact events on user removal

The former one brings Matrix 1.11 Authenticated Media support to Synapse-Admin

The latter one adds 2 toggles to the user erasure confirmation dialog:

• Remove media uploaded by the user
• Redact all user's messages

Apart from major changes, a bunch of small changes were made as well:

• Unify media icons in the sidebar and on user's view page
• Add proper previews for uploaded images and a download button for non-image uploads
• Do not block rooms from joining on delete by default (to avoid accidental blocks)

Source code

Dept of Bots 🤖

Draupnir (website)

Gnuxie 💜🐝 reports

Draupnir v2.0.0-beta.7 has been released. Ever been told to open /devtools to fix your bot's corrupted or invalid account data? In this release, we are gathering feedback for a new feature called "Safe Mode". If Draupnir fails to start from a recoverable error, Draupnir will start with limited capabilities and prompt you to select a recovery option. You can then use a command to restart the bot.

We'll be iterating "Safe Mode" over the next two weeks and focussing on assisting system admins with diagnosing setup issues. So don't forget to join us in our support room #draupnir:matrix.org and tell us what you think.

baibot (website)

Slavi reports

Since the official announcement of baibot, we've had a few releases (see the changelog) that bring important improvements like:

• being able to involve the bot on-demand in arbitrary conversation threads and reply chains

• support for OpenAI's o1 models and prompt caching

• support for prompt variables to make models more aware of their context

Rory&::MatrixContentFilter - An extensible, proactive moderation bot

Emma [it/its] announces

Here's a new project we've been working on for a bit now :)

Primary features:

• Granular access controls
  • Per room configuration
  • Bot-wide or per-room user ignore lists, including per filter configuration
• Ability to interface with the bot externally (assuming you have an access token for the bot user) - Configuration is hot-reloadable over account data
• Planned filters:
  • Disallow uploading images (mostly implemented, missing configuration handling)
  • Disallow uploading videos (missing)
  • Disallow posting links (missing)
  • Limit user mentions (missing)
  • Limit message rate (missing)
  • Anything else you may be able to think of! (missing)

As always, to ensure we can keep developing and maintaining these tools, consider donating over at Liberapay!

And, as with all of the other projects:

• The code is available at cgit.rory.gay!
  • All contributions are more than welcome, be it documentation, code, UX improvements, anything!
• Discussion, suggestions and ideas are welcome in #mcf:rory.gay (Space: #mcf-space:rory.gay)

Dept of Non Chat Clients 🎛️

Matrix Rooms Search News (website)

Aine [don't DM] reports

It's been a while since we posted MRS updates, so let's start with...

What is MRS?

Matrix Rooms Search (MRS) is a standalone search engine and Matrix Directory server that indexes Matrix servers with enabled federation and published room directory (over federation), after that you can search rooms across whole Matrix Federation either directly from your matrix client app (details), or by using simple REST API of the MRS itself.

What's new?

Authenticated Media is here - now when you browse MRS using REST API (e.g. by using the demo server on matrixrooms.info), room avatars will be fetched by the new Matrix v1.11 Authenticated Media endpoints (old unauthenticated media endpoint is still used as well, so there is a fallback).

And another update - MRS now by default uses both exact match and fuzzy queries, so that should help will searching!

Source code, MatrixRooms.info, and don't forget to say hi in #mrs:etke.cc

Matrix Federation Stats

collected by MatrixRooms.info - an MRS instance by etke.cc

Aine [don't DM] announces

As of today, 10116 Matrix federateable servers have been discovered by matrixrooms.info, 3104 (30.7%) of them are publishing their rooms directory over federation. The published directories contain 21185 rooms.

Stats timeline is available on MatrixRooms.info/stats

How to add your server | How to remove your server

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.

#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	conduwu.it	222.5
2	itzzen.net	241
3	tomfos.tr	246
4	ipv6.girlcock.systems	270
5	awawawawawawawawawawawawawawawawawawawawawawawawawawawawawawaw.gay	277.5
6	bark.arf.wf	282
7	saneke.eu	295
8	maunium.net	296
9	puppygock.gay	305
10	transgender.ing	307

#ping-no-synapse

tulir reports

The no-synapse ping room which only allowed echo bots on non-synapse servers has been shut down. It often confused people because pings were still allowed from synapses, only the pongs were non-synapse. The general #ping:maunium.net room remains active.

That's all I know

See you next week, and be sure to stop by #twim:matrix.org with your updates!