Synapse 1.57 released

19.04.2022 16:28 — Releases Brendan Abolivier

Hey everyone! Guess what? Synapse 1.57 has just been released! Let's see what's new in this version!

Application services

Application services are piece of software that have privileged access to some of the homeserver's features. For example, they can create and manage multiple users at the same time, which is especially useful for bridges.

This release of Synapse changes the way Synapse manually manages transaction identifiers when talking to application services (a transaction being a group of events the application service should know about). While this doesn't have much impact on the everyday life of a server administrator (besides fixing a bug and paving the way for future performance improvements), this change means server admins should take extra care when updating Synapse.

More specifically, if you are running a dedicated Synapse worker for handling traffic related to application services, this worker must be stopped when upgrading the main Synapse process to ensure the update is performed safely. See the upgrade notes for more information about this change, and instructions on recovering from an incorrect upgrade.

This release of Synapse also continues work on bringing end-to-end capabilities to application services, which I was already telling you about in the Synapse 1.50 release blog post. More specifically, Synapse now supports sending device list updates to applications services, as part of implementing MSC3202. This is still very experimental and definitely not production ready, but also very exciting!

Improvements to the module system

Modules allow third-party developers to expand Synapse with extra features that wouldn't necessarily fit into the Matrix specification and/or ecosystem. In the past release of Synapse, we have been improving this system to add more functionality to it, and this one is no exception!

Synapse modules can now implement new callbacks to react to account data updates, as well as to react to new 3PID (email address, phone number) associations. On the latter, note that this callback will only be called after a 3PID has been validated on the homeserver, and does not trigger when the validation happens on an identity server (e.g. when publishing a 3PID so that other users can look it up).

The ModuleApi (which is the Python class enabling modules to interact with Synapse) has also been updated to allow module to read and write global account data. This can be done by using the new AccountDataManager class, which can be accessed as api.account_data_manager (where api is an instance of ModuleApi).

The module API has also been updated with a new method, to allow modules to promote an existing user to server administrator (or demote a server administrator to a normal user). This follows up on an improvement introduced in Synapse 1.56 allowing modules to promote users to server administrators when registering them.

Everything else

This release also includes a performance improvement for workers handling /sync requests. While this change makes starting this kind of workers slightly more heavy performance-wise, it aims at improving the load associated with the first /sync requests hitting it right after starting. See this comment for more details.

Synapse 1.57 also now includes bundled aggregations in message search results by default, as MSC3666 has been accepted and has finished its final comment period.

See the full changelog for a complete list of changes in this release. Also please have a look at the upgrade notes for this version.

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Beeper, Dirk Klimpel, Famedly and Jorge Florian.

This Week in Matrix 2022-04-14

14.04.2022 19:16 — This Week in Matrix Ben Parsons
Last update: 14.04.2022 19:10

Dept of Servers 🏢

Conduit (website)

cel says

  • Gained v9 room support on next branch:
    • Binaries available here:
    • v9 rooms enable private rooms to allow access to members of a Space or other room without a separate invite.

Synapse (website)

Synapse is a Matrix homeserver implementation developed by the core team

dmr reports

Hello everyone. This week the Synapse team cut a release candidate for Synapse 1.57. It contains:

As ever, our warmest thanks to to our contributors for sharing their time, effort and expertise with the project. We look forward to seeing your work in the wild, come the 1.57 release proper on Tuesday the 19th of April.

On develop, we have been powering through a number of different tasks:

Speaking personally, my efforts to manage Synapse's dependencies using poetry are coming to a close. As I write this, I've just submitted my last (planned!) PR for this project. It's been several months in progress now, and there were many moving parts; some unexpected bugs in poetry and even one in pip; plus a heck of a lot of CI config to change and understand. My sincere thanks to the broader Synapse team for their help in getting the last batch of changes made, reviewed and merged. Once this is all said and done I hope we'll all reap the benefits of

Dept of Bridges 🌉

matrix-hookshot 1.5.0 (website)

A multi purpose multi platform bridge, formerly known as matrix-github

Half-Shot reports

Hey webhook-consuming-people! The hookshot webhook bridge 1.5.0 update has now been released. This release is a bit softer than 1.4.0, containing some smaller features and bugfixes. Thanks to everyone who contributed!. The highlights are:

  • Allow specifying msgtype for generic webhook transformations. (#282)
  • Add new GitHubRepo config optionnewIssue.labels which allows admins to automatically set labels on new issues. (#292)
  • Allow priority ordering of connection command handling by setting apriority: number key in the state event content. (#293)
  • Support GitLabpush webhook events (#306)

The matrix-docker-ansible-deploy playbooks have also been updated to be 1.5.0 compatible :)

matrix-appservice-kakaotalk (website)

A Matrix-KakaoTalk puppeting bridge.

Fair reports:

A Matrix-KakaoTalk puppeting bridge.

This week brings many new features:

  • KT<-> Matrix message deletion/redaction
    • Note that KT doesn't allow deleting a message if it's too old, so Matrix->KT redactions will fail for old messages.
  • KT->Matrix user name/avatar live updates
    • As opposed to only being updated on backfill / manual sync
  • KT<->Matrix read receipts
    • Caveat: KT->Matrix read receipts are only updated live, not on backfill / manual sync
  • KT->Matrix member join/leave
    • Only joins were tested so far, but leaves should work too
  • KT<->Matrix admin status / power levels
  • KT->Matrix channel name, description, and cover photo
  • General stability & usability improvements
  • systemd setup instructions

I've also launched an instance of the bridge & opened a public portal room for testing purposes:

Logging in to my bridge instance is restricted, but Matrix users can still join the room thanks to the magic of relaying!

At this point, I'd say the bridge is now fairly usable. Please try self-hosting if interested!

Discussion: Issue page:

Dept of Clients 📱

Matthew reports

A new GTK4 matrix client called gotktrix surfaced on HN, written in Go with a bespoke matrix client SDK implementation. Looks impressive!

Nheko (website)

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

Nico reports

After a long and arduous journey, LorenDB's dbus interface for Nheko got finally merged. Currently this allows you to list rooms as well as switch between them. In the future we might add simple messaging support, so that you can automatically send messages into specific rooms using scripts. The API is disabled by default, since it is not authenticated. Enable it at your own risk!

Another long standing PR, that finally got merged, was MTRNord (they/them)'s support for pretty power level formatting. Nheko can now tell you what changed in a power level instead of just telling you that it changed. This should make them much more accessible to users, that don't like looking at the raw event source all the time (weird, eh?).

The image viewer should also be more reliable now and notification counts should be correct after a restart.

We have also been playing around with qt6 support. At this point we have a working Qt6 branch, with a few functional regressions:

  • No voip (gstreamer has no Qt6 support yet)
  • No drop shadows on buttons
  • No switchable color schemes

So far Qt6 looks pretty great and seems to fix a lot of the minor annoyances.

We are also still looking for some student or interested individuum to take part in the Google Summer of Code and improve the call support in Nheko! Deadline is drawing close, so if you intend to apply, better work on your proposal quickly! If you need any feedback for your proposal, feel free to DM me and ask me to review it/questions. I'm looking forward to someone applying! <3

Anyway, merry christmas everyone or whatever you are celebrating this weekend!

Element Web/Desktop (website)

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

kittykat announces

  • Threads Beta is live, find it in Labs!
    • As always, check it out and let us know what you think.
  • We’re aligning on a style guide and a new module system (links will be shared once both are finalised)
  • Added our first Cypress test - this will improve how we create and run e2e (end to end) tests. The tests will continue to be run by CI.
  • In labs (you can enable labs in settings on or on Nightly)
    • Continuing to get a native lobby screen for video rooms together

Element iOS (website)

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

Manu announces

  • We will inform users in the next release that we will no longer support iOS12 and 13. It will be effective the release after, i.e. April 25th.
  • We had a big drop on UTDs (Unable to Decrypt errors) since 1.8.8.
  • We are setting up the ElementX-iOS project to rewrite the Element-iOS app. It will be based on SwiftUI and the Matrix Rust SDK. The roadmap is available here.

Element Android (website)

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

kittykat says

  • Element 1.4.11 is available on the PlayStore and on F-Droid. Release notes:
  • We may experience some delays in shipping the app through the Android PlayStore as we are in discussions about whether not decrypted messages should be reportable
  • Cleanup to the SDK API has landed on develop - this will help with generating API documentation and migrating to the Rust SDK
  • Roadmap for migration to the Rust SDK

Element (website)

Everything related to Element but not strictly bound to a client

kittykat announces

Threaded Messaging

  • Exciting news this week; the Threads Beta is live on all platforms! If you haven’t seen Threads yet, head to Settings > Labs and check it out.
    • Please note; If your homeserver doesn’t yet support threads functionality you may not see the beta, or your experience will be degraded. If this applies to you, you’ll see a warning message before you activate Threads.
  • The team is continuing to squash bugs and improve performance, we’ve also started working on the next improvements…
  • Notifications and badges are top of mind for us next. We need to ensure accuracy of badge counters and consistency between platforms (if you use more than one). We’re looking at this now so keep your eyes peeled for our upcoming MSCs.

Community testing sessions

  • We are restarting our testing sessions! Join to take part
  • We are trying out a new asynchronous format with office hours for discussion to enable more people to be involved

Dept of Encryption 🔐


uhoreg reports:

libolm 3.2.11 has been released. This release mainly features improvements to the Objective-C and Java bindings, but also fixes building of the documentation, which was broken for quite a while. For more details, see the release notes.

Dept of SDKs and Frameworks 🧰

Ruma (website)

A set of Rust library crates for working with the Matrix protocol. Ruma’s approach to Matrix emphasizes correctness, security, stability and performance.

Jonas Platte says

Over the last two weeks, we have been busy working towards the 0.6.0 release of Ruma. If things go to plan, it should be published in the coming weeks (but no promises). That means mostly finishing some large refactorings, but we also got some bug fixes in, as well as a number of convenience functions for working with certain events:

Dept of Internet of Things 💡

HASSkbot - Home-Assistant ask bot

Oleg reports

HASSkbot can be used to control an action in Home-Assistant via Matrix reactions.

It's an Opsdroid bot, which reacts to a home-assistant entity state change (like person leaving a zone) and asks for confirmation in Matrix if it should run additional home-assistant automation. Matrix reactions are used for confirming or canceling an action.

Dept of Bots 🤖

Arya K reports

Merseklo is now out of beta it is a moderation bot for matrix written in pure bash with the only deps being jq and curl

Honoroit (website)

A Matrix helpdesk bot

Aine reports

benpa is back in town and I can't keep silence: here is a small update on Honoroit - v0.9.6 comes with "stable spaces" support that will work with new versions of element (yes, even on Element Android from F-Droid).

Go check the source code and say hi in the

Dept of Events and Talks 🗣️

DWeb Camp

cel reports

DWeb Camp 2022 website and registration launched:

  • August 22-24 BUILD; August 24-28 CAMP; Aug 28-29 TAKE DOWN.
  • Camp Navarro, CA, USA
  • Announcement:!$
  • Volunteer:
  • Apply for fellowship:
  • Sponsor: PDF

DWeb Camp is a gathering hosted by Internet Archive and volunteers dedicated to Decentralized/Distributed web projects. Previously it happened in 2019, and Matrix had some presence there. Maybe people from Matrix projects and/or will be there this year?

That's all I know 🏁

Come back next week for a much restored TWIM! With Matrix Live, Spec updates, Dept of Ping and so on. :D

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

This Week in Matrix 2022-04-08

08.04.2022 19:27 — This Week in Matrix Ben Parsons

Matrix Live 🎙

Dept of Status of Matrix 🌡️

Matthew announces is finally here as a tracker for our progress on P2P Matrix

Dept of Spec 📜

TravisR says

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

MSC Status

Merged MSCs:

  • No MSCs were merged this week.

MSCs in Final Comment Period:

New MSCs:

Spec Core Team

In terms of Spec Core Team MSC focus for this week, we've been largely looking at proposals which are at or near FCP in an effort to get them through the last stages of the process. We're also thinking about what the next release (v1.3) looks like and when we'll end up putting it out into the world. If you have MSCs which you'd like included, please stop by the on Matrix with your suggestions - if they're near enough, we'll try to get them in.

Random MSC of the week

The script has elected MSC3391: Removing account data as the random MSC this week. It's a small but interesting MSC which helps clean up account data on the server when it's no longer needed, though how this sort of removal gets represented to clients can be a challenge. It's currently missing an implementation if someone is looking for a medium complexity contribution this weekend 😉

The Chart

So many MSCs are in the open state, which is why we're continually looking at merging MSCs which are ready to go.

Dept of Servers 🏢

Synapse (website)

Synapse is a Matrix homeserver implementation developed by the core team

Brendan Abolivier reports

This week, we've released Synapse 1.56! It includes only a couple of new features but quite a few bug fixes and internal improvements. One of the main changes included in this version is that Synapse will now refuse to start if configured with open registration with no verification (e.g. email, recaptcha, etc). This is an attempt at reducing the likelihood of spam across the federation, as most cases of abuse we've observed over time usually involves the attacker(s) finding homeservers with open registration and automatically creating a lot of accounts on them in order to evade sanctions.

This version of Synapse also deprecates the groups/communities feature of Matrix. This is a feature we introduced back in 2017, and was the predecessor of Matrix spaces. But now that it has been mostly replaced by spaces, we have decided to retire this feature, which we thank dearly for its 4 years of good and loyal service to the federation.

Read all about this, and more, in the release announcement on the blog! 🙂

Dendrite / gomatrixserverlib (website)

Second generation Matrix homeserver

neilalexander announces

This week we released Dendrite 0.8.0, which is primarily a feature release, and then Dendrite 0.8.1 which fixes an emergency bug. It's also a recommended upgrade if you are running a Dendrite deployment. It includes:

  • Support for presence has been added

    • Presence is not enabled by default
    • The global.presence.enable_inbound and global.presence.enable_outbound configuration options allow configuring inbound and outbound presence separately
  • Support for room upgrades via the /room/{roomID}/upgrade endpoint has been added (contributed by DavidSpenler, alexkursell)

  • Support for ignoring users has been added

  • Joined and invite user counts are now sent in the /sync room summaries

  • Queued federation and stale device list updates will now be staggered at startup over an up-to 2 minute warm-up period, rather than happening all at once

  • Memory pressure created by the sync notifier has been reduced

  • The EDU server component has now been removed, with the work being moved to more relevant components

  • It is now possible to set the power_level_content_override when creating a room to include power levels over 100

  • /send_join and /state responses will now not unmarshal the JSON twice

  • The stream event consumer for push notifications will no longer request membership events that are irrelevant

  • Appservices will no longer incorrectly receive state events twice

Our sytest compliance numbers are now:

  • Client-server APIs: 83%
  • Server-server APIs: 95%

As always, join us in for more news and discussion.

Dept of Bridges 🌉

matrix-hookshot (website)

A multi purpose multi platform bridge, formerly known as matrix-github

Half-Shot says

Matrix-Hookshot: The one with the widgets release

Hello webhook fans! As teased last week, configuration widgets have landed in hookshot! 1.4.0 now contains all you need to setup your very own webhooks without having to leave the comfort of your GUI. The plan is for widgets to be greatly expanded over the new few releases to support more services. Eventually, this work is going to propagate out to other bridgey projects 🌉.

The full feature list for this release looks a bit like:

  • Add support for configuring generic webhooks via widgets. (#140)
  • Show the closing comments on closed GitHub PRs. (#262)
  • Webhooks created via !hookshot webhook now have their secret URLs sent to the admin room with the user, rather than posted in the bridged room. (#265)
  • Automatically link GitHub issues and pull requests when an issue number is mentioned (by default, using the # prefix). (#277)
  • Support GitLab release webhook events. (#278)

Update away, and let me know how you get on.

matrix-appservice-kakaotalk (website)

A Matrix-KakaoTalk puppeting bridge.

Fair reports:

A Matrix-KakaoTalk puppeting bridge.

Many updates this week! New features include:

  • Mentions & replies, both incoming & outgoing
    • Small exception: Matrix->KT replies don't yet work in KT "open channels" yet.
  • Ability to create a portal by inviting a KT puppet to a DM
    • Note that this currently only works for KT direct chat channels that already exist & have been active recently.
  • Connection resilience between the Python and Node components of the bridge
    • i.e. If the Node component ever exits & restarts, the Python component will reconnect to it automatically. This helps both with deployment (since it allows the components to be started in any order) and crash tolerance (since a Node crash & restart no longer requires a manual restart of the Python component)
  • Clear warnings when receiving a KT message that the bridge doesn't yet support

At this point, the bridge should be fairly usable now. Very soon I'll open a Matrix-bridged KT channel to act as a public stress-test!

Discussion: Issue page:

Heisenbridge (website)

Heisenbridge is a bouncer-style Matrix IRC bridge.

hifi reports

Heisenbridge roundup!

Heisenbridge is a bouncer-style Matrix IRC bridge.

Release v1.11.0 🥳

  • Fixed retry behavior on startup to wait for HS startup
  • Ignore TAGMSG messages from IRC server
  • Fixed HTML messages not working as commands
  • Fixed room aliases in messages dropping the message completely
  • Upgrade to Mautrix 0.15

Just your typical bug fix release but this release also breaks support for homeservers not supporting the "v3" API path so if you run Synapse 1.47 or older the bridge will not start. Sorry.

Go and get some spring cleaning from GitHub, PyPI or matrix-docker-ansible-deploy!


Dept of Clients 📱


freaktechnik reports

Thunderbird is a free open-source email, calendar & chat app.

The latest Thunderbird beta finally has Matrix support enabled by default. Get Thunderbird beta now to try it out. There have been many improvements to the Matrix implementation since the last update, including:

  • Almost complete end-to-end encryption support
  • Support for displaying formatted messages
  • .well-known home server discovery
  • Message redactions
  • Now all room invites let you respond
  • Lazy loading room members

Element Web/Desktop

kittykat reports

  • We removed skinning! It won’t be in the release this week, but will land in 2 weeks (roughly). If you notice bugs, please report them!
  • Threads Beta went into the RC!
  • Looking at a module system for extending functionality - if you have modules we haven’t talked about, come by to let us know.
  • In labs (you can enable labs in settings on or on Nightly)
    • Work on video rooms continues, and we’re exploring how we can make them feel more native.

Syphon (website)

Chat with your privacy and freedom intact

0x1a8510f2 says

Syphon is a Matrix client with heavy emphasis on privacy and ease of use; currently in open alpha.

Hi all 👋.

We released 0.2.13 this week mainly fixing an annoying bug that could cause messages sent while a configured proxy server was down to be re-sent multiple times once the proxy came back online. If you use a proxy with Syphon, this update is highly recommended!

In addition, this release will only show the option to use hidden read receipts if the feature is supported by your server.

Finally, a range of translation updates and improvements are included in this release.

More changes are coming soon, including a (currently work-in-progress) implementation of MSC2228 (self destructing events). As far as we know, we're on track to be the first user-facing implementation of this MSC, putting Syphon on the bleeding edge of Matrix!

Nheko (website)

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

Nico reports

Thanks to the awesome polyjuice client, Nheko now supports MSC3700, which slightly improves privacy in encrypted rooms. It also lead to us fixing issues with the secure symmetric secret storage, where some clients use a different base64 encoding than recommended in the spec, which could make unlocking the secrets with a recovery key or passphrase fail. And we also improved the key queries on initial login, which would sometimes fail to_device messages with a warning, that the device is unknown.

As a small feature, you can now close the currently open room using Ctrl-W, spaces are not treated as DMs under some circumstances anymore, you should get a less confusing error message than 500 when entering an invalid alias now and lots of fixes to the translations.

Thank you, LorenDB, Apurv and Mikaela for the contributions!

Hydrogen (website)

Hydrogen is a lightweight matrix client with legacy and mobile browser support

Bruno reports

Have released the SDK, v0.0.10 with custom tiles support. Calls and theming are getting closer, the latter we were planning to release this week but hit a blocker for theming support in develop mode, so we'll have to postpone to next week.

Element iOS (website)

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

Manu announces

  • Considering dropping support for iOS12 - this will impact 0.9% of sessions. Requiring iOS 13 or newer will allow us to use SwiftUI libraries.
  • You will be able to opt in to threads in the next release (currently in testing), alongside updates to room preview on long press in room list, ability to share any location and support for more languages

Element Android (website)

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

benoit reports

  • Release candidate 1.4.11 is currently available on the PlayStore if you are a tester. Should be pushed to production next Monday! F-Droid publication is in progress too. Learn more about the full release content here:
  • Add banner to timeline when location sharing is running. Live Location Sharing (a.k.a. LLS) is still a work in progress and not available in the Element app yet.
  • Improved unit test coverage (especially around login with MXID)
  • Improved how threads look in the main timeline
  • Add notification for users to opt in to threads
  • Polishing around spaces to bring them into line with latest designs
  • Hotfix for leaving all rooms in a space without leaving the DMs. The hotfix is included in the release candidate 1.4.11.
  • We are considering modifying our rules to format source code. We will try to limit the impact on forks, but it will not be easy.

Dept of Non Chat Clients 🎛️

Populus Viewer (website)

A Social Annotation Tool Powered by Matrix

gleachkr reports

Since last time, we've made a lot of small quality-of-life improvements, but a few changes that stand out are:

  1. We've improved support for offline PWA usage.
  2. We've improved caching of space contents, reducing the number of times that we need to hit the spaceHierarchy endpoint and improving performance.
  3. We've moved to a more in-the-spirit-of-the-spec way of handling hidden annotations: these are now represented by rooms with an event, and no correpsponding event in the resource-space.
  4. We've added a modal for viewing image messages at full-size.

Number 4 works nicely with my teaching-assistant-bot (built with matrix-bot-sdk, mathjs, and chartjs), which helps me visualize information about student activity.

MSC3752 - Markup Locations for Text, has also filled out quite a bit! Implementation coming soon hopefully.

As always, if you'd like to learn more, or talk about the future of social annotation at matrix, come join us at!

Matrix Highlight (website)

A decentralized and federated way of annotating the web based on Matrix.

Daniel announces

Matrix highlight saw some "under the hood" changes this week, in particular a refactor to rely less on the Chrome/Firefox extension API. This should make it possible (in theory, and with some more work) to run Matrix Highlight on pages without installing anything! Aside from the obvious, I think that there are additional use cases opened up by this change; one such case I have in mind is as a commenting system on a site (a la cactus comments, but with the ability to highlight page snippets!).

In the process of all of this, I've spent some time running Matrix Highlight in Firefox. I've encountered no issues during this time, so it seems like the tool is usable from FF, too.

Dept of SDKs and Frameworks 🧰

Trixnity (website)

Multiplatform Kotlin SDK for Matrix

Benedict reports

Trixnity 2.0.0-RC1 has been released. This release candidate contains many breaking changes due to a large refactoring, which allows us to share a lot code between server and client implementations of the Matrix APIs. Yes, that means Trixnity can be used to implement a matrix server! We also made some progress to make the client module (with all the high level logic) multiplaform. This is the only module, which does not support Kotlin/Native and Kotlin/JS yet. There are many other features (like client-side notifications!), which has been added. See the changelog for more details:


  • clientserverapi-server: new module for server-side REST endpoints of the Client-Server-API (Server-Server-API will follow soon)
  • olm: libolm is bundled into trixnity-olm jars
  • client: push notification support (push rules are evaluated)
  • client: introduce helpers to get complete timeline as flow (no more complicated loops to get the timeline)
  • client: allow subscribing to all timeline events -> really helpful for bots with e2e support
  • client: allow to sync once (e. g. for push notifications)
  • client: content field of TimelineEvent gets also set for unencrypted events
  • client: public access to keys
  • clientserverapi-model: allow custom field in pusher data
  • core: introduce BaseEventContentSerializerMappings


  • client: remove direct room, when other user leaves room
  • client: change varchar length to support MariaDB
  • clientserverapi-client: first sync after pause without timeout

simplematrixbotlib (website)

simplematrixbotlib is an easy to use bot library for the Matrix ecosystem written in Python and based on matrix-nio.

krazykirby99999 says:

An easy to use bot library for the Matrix ecosystem written in Python.

Version v2.6.3 Released!

2022-04-06 5f54f69

  • The command matcher now has support for case-insensitive matches.
  • Add case insensitive option to command matcher
  • Update Pillow Dependency to version 9.0.1
  • None
  • None

Polyjuice (website)

Elixir libraries related to the Matrix communications protocol.

uhoreg announces

Polyjuice Client Test is a testing tool for Matrix clients. Since the last TWIM update,

  • two new tests have been added: key history sharing (MSC3061) and no plaintext sender key (MSC3700).
  • more clients endpoints have been implemented or stubbed. This has improved compatibility with some Matrix clients, and reduced noise in the logs.
  • the deployment at now automatically runs the latest version from git. This Matrix-based continuous deployment is powered by another personal side-project, which will be revealed in the future.
  • the UI is now significant less ugly (unless you hate purple, in which case you may find it more ugly).
  • now exists for discussing anything related to the Polyjuice project

Dept of Ping 🏓

Dept of Ping will return!

That's all I know 🏁

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

Synapse 1.56 released

05.04.2022 00:00 — Releases Brendan Abolivier

Happy release day everyone! Synapse 1.56 is out! Let's have a look at what's new in this release.

Additional restrictions around registration

One common abuse scenario we have seen on Matrix over the years is attackers making use of public homeservers with open registration to automatically create multiple accounts in order to evade sanctions. Sometimes, this can lead to these public homeservers being banned across multiple public rooms despite their administrator(s) not being directly at fault.

In order to mitigate this, starting from this release, Synapse will refuse to start by default if it is configured with open registration with no additional verification. This means users wishing to register on these homeservers will need to authenticate themselves, either via email, recaptcha or registration tokens.

Please see the upgrade notes for more information.

So long groups, and thanks for all the fish

Long-time users of Matrix might remember when, way back in 2017, we introduced groups (also known as communities in some clients). Groups would let users define a curated set of users and rooms to represent a given community that others could refer to. We even used to have which was the official group for the Matrix team and community.

If this sounds a bit familiar to you (and remind you of a certain other feature of Matrix), that's no coincidence. Some time ago, we had already identified a good amount of shortcomings with groups, and decided to redesign the feature entirely and release it under the name "spaces". If you're curious about this, then you may wish to read the spaces announcement blogpost we released at the time.

Now that spaces have been out of beta for some time, and have shown to be a very useful feature to the ecosystem, we decided it was time to retire support for groups from Synapse, after more than 4 years of good and loyal service. This release of Synapse deprecates the feature, with a plan to disable it by default in Synapse 1.58 (which is expected to be released next month).

Everything else

As of this version, Synapse will also refuse to start the if the Postgres database it is running against has a non-C locale, in order to prevent accidental database corruption. See the upgrade notes for more information.

This release also includes the ability for modules to register server administrators through the register_user method, as well as a new method to allow modules to store external 3PID associations into Synapse's database.

See the full changelog for a complete list of changes in this release. Also please have a look at the upgrade notes for this version.

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Dirk Klimpel, Beeper, Famedly, IronTooch and villepeh.

This Week in Matrix 2022-04-01

01.04.2022 19:05 — This Week in Matrix Thib

Matrix Live 🎙

Dept of Spec 📜

Andrew Morgan (anoa) reports

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

MSC Status

New MSCs:

MSCs in Final Comment Period:

  • No MSCs are in FCP.

MSCs with Proposed Final Comment Period:

  • No MSCs had FCP proposed this week.

Merged MSCs:

Spec Updates

There's been lots of new MSCs this week! Three of them - those regarding state restrictions and subkeys - are related to the ongoing live location sharing work that Element is currently working on. See MSC3672 for the current state of the spec work for that feature.

Otherwise the spec core team has been reviewing a flurry of MSCs this week. This includes MSC3383 (Include destination in X-Matrix Auth Header), MSC3700 (Deprecate plaintext sender key) and MSC2246 (Asynchronous media uploads). Exciting things in the pipeline!

Random MSC of the Week

The random MSC of the week is... MSC2815: Proposal to allow room moderators to view redacted event content!

Another MSC in the sphere of moderation, and one that aims to put moderation control more in the hands of room admins rather than homeserver admins. A similar MSC in this realm is MSC3215 (Aristotle), which aims to send event reports to room admins, rather than homeserver admins that may not even have control over the malicious user.

Dept of Servers 🏢

Synapse (website)

Synapse is a Matrix homeserver implementation developed by the core team

Brendan Abolivier announces

Happy Friday everyone!

In case you missed it, we've released the first release candidate for Synapse 1.56 on Tuesday. This one includes a couple new module-related features, but also quite a few bugfixes and internal improvements. I'll talk about this in more details next week when Synapse 1.56 gets properly released, but the key points of this release is that Synapse will now refuse to start if it's configured with unsafe registration settings (i.e. open registration without any form of verification) as well as if it's running against a PostgreSQL database with the wrong locale values. Have a look at the upgrade notes for more information about this.

Apart from that, the team still continuing work on the two main topics I've been mentioning in previous weeks: fast room joins and integrating poetry. The latter is getting reeeally close to the finish line now, as the pull request has recently entered the review stage. So watch this space for more exciting news on this topic!

That's all for this week, catch you all next time 🙂

matrix-media-repo (website)

Matrix media repository with multi-domain in mind.

TravisR reports

MMR v1.2.12 is out now with a bunch of added features, removal of in-memory cache (per last release's deprecation notice), and some bug fixes.

Most notable are some added/improved support for JPEG XL, HEIF, and HEIC thumbnails, content ranges support (allowing the ability to skip to a part of a video), and a way to make the logs a bit quieter.

Give it a go and report issues to the issue tracker 🙂

Dept of Bridges 🌉

matrix-hookshot (website)

A multi purpose multi platform bridge, formerly known as matrix-github

Half-Shot announces

It feels like one of these comes out nearly every month, which probably means we're doing something right! This release takes a step back and fixes quite a few of our more longstanding bugs and fixes many nits here and there. Please read the change notes carefully as some APIs have moved around and your load balancers / config may need adjusting. One final note is that this release drops support for Node 12, making the minimum version Node 14.

Once again, thanks to the wider Matrix community for filing bugs and submitting PRs, it's very much appreciated!

matrix-appservice-bridge 4.0.0

Half-Shot says

More updates! This week the bridge library itself gets a major update. We've made a few breaking changes, notably we now expect target homeservers to at least be Matrix v1.2 compatible. Also, this release brings the new "Provisioning and Widgets API" which allows developers to start creating HTTP APIs for their bridges which work for both provisioning mode (shared secret tokens) and widget API style (authenticating via Matrix OpenID token sharing). This stuff is still a little experimental, but it's starting to power our new experiments in the bridge world.

You can check out the release here

matrix-appservice-kakaotalk (website)

A Matrix-KakaoTalk puppeting bridge.

Fair announces

Media messages, both from or to KakaoTalk, are now supported! The biggest exceptions are inbound files & stickers. The latter may be a hard sell to get working, due to how KT manages stickers, but I'll look into it some more before giving a concrete answer.

The bridge is also now responsive to disconnects, like when you log in from another KakaoTalk desktop client (since the bridge mimics the desktop client, and KT only allows one desktop client to be logged in at a time!). Luckily, not all KakaoTalk APIs rely on the same connection that chatting does, meaning that some functionality can continue to work even when "disconnected". The bridge now takes advantage of this, meaning that profile-management commands (currently just the list-friends command) will work even if you get disconnected from chats for whatever reason.

The bridge is drawing ever closer to "good enough" status... Please give it a try if curious!

Discussion: Issue page:

matrix-appservice-irc (website)

Node.js IRC bridge for Matrix

Half-Shot reports

Heyo, we released a hotfix release for the IRC bridge this week. This fixed a rather nasty regression where the bridge would kick everyone from the Matrix side when a Matrix ban list is updated. People who aren't using the new ban lists feature don't need to upgrade.

Please check out for more details

Dept of Clients 📱

Michael says

The team has created their own Android client, a promotional fork of the popular Element Android client!

For more details checkout:

Nheko (website)

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

Nico announces

1.0 is a big number and a step not taken lightly. But Nheko has been in development for half a decade and we think it is time to take a step forward! As such we worked hard to fix readability issues in the app. Your messages should now be readable on any theme, because we send the first half as white text and the second half as black text (thank you, rrogalski for the contribution). For accessibility reasons this is enabled by default. We also added an improved typing indicator. Sometimes it is hard to notice when a message is too long, as such we gradually adjust the background color the longer the message gets. It also helps a lot, if you have a bad theme and can't read the text against the background color. Just enter a few characters and the background will change, so the messages should become readable. But that is not all! We all know some people have a harder time seeing colors than others. So for accessibility we also slowly rotate the screen, so that even if your display is monochrome, you don't miss out. Please see the attached video for a demo or check out our release candidates here and here.

Before this month we also rewrote the room creation dialogs to be less confusing. We now have separate dialogs for direct chats and group chats, which should cut down confusion between the options by a lot. You can also now edit the topic and name of a room inline and Malte added a jump to bottom button. On mobile you can also now drag to the sides to reply. Last but not least, you can now knock on rooms from Nheko using /knock or if an invite failed because you were not allowed to join a room and you can add a reason to room joins, leaves, invites, knocks and everything. Some of those features require the server to support Matrix v1.1, so make sure you update your servers to use them.

Nico announces

Excuse the blurry picture, but Bubu just sent me this and I just had to share it!

Neochat (website)

A client for matrix, the decentralized communication protocol

Tobias Fella says

NeoChat now has a KRunner plugin thanks to work done by Nico (not the one from Nheko 🙂). This allows plasma users to search for and open matrix rooms directly from their desktop. You will be able to enable it from the KRunner settings after the next release.

Snehit changed the room preview to no longer show markdown characters, fixing a few situations where this would be unexpected.

On the end-to-end encryption side, we're currently working on implementing device verification.

Fractal (website)

Matrix messaging app for GNOME written in Rust.

Julian Sparber reports

This week I have something really exciting to report. We moved Fractal-next to the main development branch. This means that we now have nightly flatpak builds[1], so users can already try out the new version of Fractal without having to build it from source. This will also give use much more feedback and many more bug reports, hopefully not too many :) Note that this isn't a release and the software should still be considered unstable.


Element (website)

Everything related to Element but not strictly bound to a client

Danielle announces

It’s April Fool’s day but there will be no tricks here; We’re far too excited to share all our good work with you 😉

Message Threading

  • Exciting news for Threads; Next week we’re releasing a public beta!

    • It’ll be opt-in, so don’t forget to head to Settings and join in if you haven’t already.
  • We’re still working on perfecting notifications, so none of your messages are missed.

  • The team is also working hard at improving the stability of Threads, ahead of the release next week.

  • As always, please let us know your thoughts and feedback!

Element Web/Desktop (website)

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

Kegan says

Coming soon to an Element-Web near you...

Danielle announces

In labs (you can enable labs in settings on or on Nightly)

  • Voice rooms are now known as video rooms! We’ve landed some new designs to help make the experience more coherent, and bring them out of ‘prototype’ status.
  • Threads! From next week you’ll be able to turn on threads in all versions of Element but for a sneak preview you can head to Labs in Develop or Nightly and access Message Threading from there.
  • We’re continuing to work on our updated search experience: we are going to be merging the people and room search dialogs into the new search experience and adding filtering. Expecting work to start early next week.
  • Along with some feature work in Labs, the team is hard at work closing issues and clearing pesky bugs.

Element iOS (website)

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

Manu reports

  • Our latest release is a hotfix (1.8.10) resolving a crash that occurred when uploading a photo via the camera in the timeline.
  • Following a team discussion and input from all areas we’ve decided to change how we launch new languages in Element. We’ll soon be moving to an automatic rollout model meaning, if there’s any amount of a language available, and it’s set as your preference, you’ll see it in the app.
    • Previously we’d wait until hitting the 80% mark and then manually push the translation. This leaves too much room for us to forget, or restricts access to those languages hanging around the 70% mark…
  • Other things we’ve been working on this week include; improving the new user experience, and starting to prototype with the layout for the app.
  • We released spaces on iOS this week! Where you could only view spaces before, you can now create and manage them from your phone. We have more improvements planned for the next release.

Element Android (website)

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

Danielle announces

  • The Android team has been determined over the past weeks to improve our internal process, increasing efficiency and quality of building and deploying. With that in mind, we’ve recently published a guide for PRs on our Android Repo. It’s still a draft right now but if you want to know more about our approach, read it here.
  • In terms of building we’re continuing on our path of improving the quality of the app by focussing on bugs and UI issues.
  • We’re also working on improving our new user experience to make it easier for newbies to get up and running on Element Android!

Dept of Non Chat Clients 🎛️

matrix-streamchat (website)

Matrix powered stream overlay for OBS, to integrate live chat in your favorite (selfhosted) streaming setups.

f0x announces

matrix-streamchat got it's first proper release, after some battletesting by another streamer :D hosted instance is also available at

Matrix Highlight (website)

A decentralized and federated way of annotating the web based on Matrix.

Daniel announces

Matrix Highlight got an update this week. I've switched the highlighting widget to use a shadow DOM, which means styles from the page don't affect styles from the extension itself. This used to affect quite a lot of pages, but shouldn't be much of a problem anymore!

Dept of SDKs and Frameworks 🧰

Ruma (website)

A set of Rust library crates for working with the Matrix protocol. Ruma’s approach to Matrix emphasizes correctness, security, stability and performance.

Jonas Platte says

This week, we

matrix-rust-sdk (website)

Matrix Client-Server SDK for Rust

Jonas Platte announces

In the last two weeks,

  • Support for vodozemac as an alternative to libolm has been merged, and enabled by default 🎉
  • A bug around invitations to previously-left rooms was fixed

There was also a decent amount of internal cleanup / developer experience work, so if you previously tried to contribute but ran into weird IDE bugs or code inconsistencies, make sure to check back. The same goes for sliding sync, which has been making decent progress – stay tuned!

Dept of Events and Talks 🗣️

andybalaam reports

I'm doing a talk about Matrix at the ACCU Conference on Saturday 9th April. Recordings of talks will be available soon after the conference, and tickets are still available to be there live in person or online! Here's the talk summary:

The Matrix network provides messaging (like WhatsApp or Slack) that offers all the features you expect, but without centralised control: it's an open standard, and anyone can run a server. The servers link together, so you can talk to other people even if they use a different server (kind of like email).

In the first half of this session, we will explore the basics of the protocol: making simple HTTP requests to send and receive messages, and discuss some of the interesting distributed-systems issues that make writing a server exciting.

In the second half we will explore the fact that messaging is only one potential use of this network, and look into some examples of other real-time use cases that are in active development, taking note of how these use cases benefit from the real-time and distributed nature of the network.

Dept of Interesting Projects 🛰️

matrix-art (website)

An image gallery for Matrix

MTRNord (they/them) reports

There was some silence lately on this, but activity is picking back up.

Mainly, the project is getting rewritten. Why? Well, I learned from the issues and ran into issues with the framework used. There are going to be various changes to the architecture (like no more SSR, no nextjs, pwa support and more).

Feel free to follow for progress.

Another big thing that's going to change is that I am working on a complete redesign. While I am still fairly early in the iterations, I wanted to share the first art direction Matrix Art is going to go. The main changes are that I try to have an art language which distinguishes it from the other proprietary players, as well as compensating for the fact that Matrix Art has a much lower volume of images on it's feed. Please be aware that this is way before the first round of polish. :)

If you want to connect with matrix-art please join the room: or follow/star the github project :)

Dept of Ping 🏓

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

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

RankHostnameMedian MS

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

RankHostnameMedian MS

That's all I know 🏁

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

Technical FAQ on the Digital Markets Act

30.03.2022 14:13 — General Matthew Hodgson

Hi all,

We've been flooded with questions about the DMA since it was announced last week, and have spotted some of the gatekeepers jumping to the wrong conclusions about what it might entail. Just in case you don't want to wade through yesterday's sprawling blog post, we've put together a quick FAQ to cover the most important points based on our understanding.

What does DMA mean for the gatekeepers?

The gatekeepers will have to open and document their existing APIs, so that alternative clients and/or bridges can connect to their service. The DMA requires that the APIs must expose the same level of privacy for remote users as for local users. So, if their service is end-to-end-encrypted (E2EE), the APIs must expose the same E2EE semantics (e.g. so that an alternative client connecting would have to implement E2EE too). For E2EE-capable APIs to work, the gatekeeper will likely have to model remote users as if they were local in their system. In the short term (one year horizon) this applies only to 1:1 chats and file transfers. In the long term (three year horizon) this applies to group chats and voip calls/conferences too.

Who counts as a “gatekeeper”?

The DMA defines any tech company worth over €75B or with over €7.5B of turnover as a gatekeeper, who must open their communication APIs. This means only the tech giants are in scope (e.g. as of today that includes Meta, Apple, Google, Microsoft, Salesforce/Slack - not Signal, Telegram, Discord, Twitter).

Does this mean the gatekeepers are being forced to implement an open standard such as Matrix or XMPP?

No. They can keep their existing implementations and APIs. For interoperability with other service providers, they will need to use a bridge (which could bridge via a common language such as Matrix or XMPP).

Are bridges secure?

If the service lacks end-to-end-encryption (Slack, Teams, Google Chat, non-secret chats on Facebook Messenger, Instagram, Google Messages etc) then the bridge does not reduce security or privacy, beyond the fact that bridged conversations by definition will be visible to the bridge and to the service you are interoperating with.

If the service has E2EE (WhatsApp, iMessage, secret chats on Messenger) then the bridge will necessarily have to decrypt (and reencrypt, where possible) the data when passing it to the other service. This means the conversation is no longer E2EE, and thus less secure (the bridge could be compromised and inspect or reroute their messages) - and so gatekeepers must warn the user that their conversation is leaving their platform and is no longer E2EE with something like this:

Why is the DMA good?

The upside is that the user has the freedom to use an infinite number of services (bots, virtual assistants, CRMs, translation services, etc) as well as speak to any other user in the world, regardless what platform they use.

It also puts much-needed pressure on the gatekeepers to innovate and differentiate rather than rely on their network effects to attract new users - creating a much more vibrant, open, competitive marketplace for users.

See "What's driven the DMA?" for more details.

If the DMA requires that remote users have the same security as local users, how can bridges work?

The DMA requires that the APIs expose the same level of security as for local users - ie E2EE must be exposed. If the users in a conversation choose to use a bridge and thus reencrypt the messages, then it is their choice to tradeoff encryption in favour of interoperability for a given conversation.

Does this undermine the gatekeepers’ current encryption?

Absolutely not. Users talking to other users within the same E2EE-capable gatekeeper will still be E2EE (assuming the gatekeeper doesn’t pull that rug from under its users) - and in fact it gives the gatekeepers an excellent way to advertise the selling point that E2EE is only guaranteed when you speak to other users on the same platform.

But why do we need bridges? If everyone spoke a common protocol, you wouldn’t ever have to decrypt messages to convert them between protocols.

Practically speaking, we don’t expect the gatekeepers to throw away their existing stacks (or implement multihead messengers that also speak open protocols). It’s true that if they natively spoke Matrix or XMPP then the reencryption problem would go away, but it’s more realistic to focus on opening the existing APIs than interpret the legislation as a mandate to speak Matrix. Perhaps in future players will adopt Matrix of their own volition.

Where do these bridges come from?

There is already a vibrant community of developers who build unofficial bridges to the gatekeepers - eg Element, Beeper and hundreds of open source developers in the Matrix and XMPP communities. Historically these bridges have been hampered by having to use unofficial and private APIs, making them a second class citizen - but with open documented APIs guaranteed by the DMA we eagerly anticipate an explosion of high quality transparent bridges which will be invisible to the end user.

Can you run E2EE bridges clientside to make them safer?

Maybe. For instance, current iMessage bridges work by running iMessage on a local iPhone or Mac and then reencrypting the messages there for interoperability. Given the messages are already exposed on the client anyway, this means that E2EE is not broken - and avoids decrypting them on a server. There is lots of development in this space currently, and with open APIs guaranteed by DMA the pace should speed up significantly.

How can you tell what service you should use to talk to a given remote user?

For 1:1 chats this is easy: you can simply ask the user which service they want to use to talk to a given user, if that user is not already on that service.

For group chats it is harder, and this is why the deadline for group chats is years away. The problem is that you need a way to verify the identity of arbitrary numbers of remote users on different platforms - effectively looking up their identity in a secure manner which stops services from maliciously spoofing identities.

One possible way to solve this would be for users to explicitly link their identity on one service with that on the gatekeeper’s service - eg “Alice on AliceChat is talking in the same room as Bob on BobChat; Bob will be asked to prove to AliceChat that he is the real Bob” - and so if AliceChat has already validated Bob’s identity, then this can be used to spot him popping up on other services. It also gives Bob a way to block themselves from ever being unwittingly bridged to AliceChat.

There are many other approaches too - and the onus is on the industry to figure out the best solution for decentralised identity in the next 3-4 years in order to realise the most exciting benefits of the DMA.

For a much deeper dive into the above, please check out our post at "How do you implement interoperability in a DMA world?"

How do you implement interoperability in a DMA world?

29.03.2022 17:57 — General Matthew Hodgson
Last update: 29.03.2022 09:23

With last week’s revelation that the EU Digital Markets Act will require tech gatekeepers (companies valued at over $75B or with over $7.5B of turnover) to open their communication APIs for the purposes of interoperability, there’s been a lot of speculation on what this could mean in practice, To try to ground the conversation a bit, we’ve had a go at outlining some concrete proposals for how it could work.

However, before we jump in, we should review how the DMA has come to pass.

What’s driven the DMA?

Today’s gatekeepers all began with a great product, which got more and more popular until it grew to such a size that one of the biggest reasons to use the service is not necessarily the product any more, but the benefits of being able to talk to a large network of users. This rapidly becomes anti-competitive, however: the user becomes locked into the network and can’t switch even if they want to. Even when people have a really good reason to move provider (e.g. WhatsApp’s terms of use changing to share user data with Facebook, Apple doing a 180 on end-to-end encrypting iCloud backups, or Telegram not actually being end-to-end encrypted), in practice hardly anything changes - because the users are socially obligated to keep using the service in order to talk to the rest of the users on it.

As a result, it’s literally harmful to the users. Even if a new service launches with a shiny new feature, there is enormous inertia that must be overcome for users to switch, thanks to the pull of their existing network - and even if they do, they’ll just end up with their conversations haphazardly fragmented over multiple apps. This isn’t accepted for email; it isn’t accepted for the phone network; it isn’t accepted on the Internet itself - and it shouldn’t be accepted for messaging apps either.

Similarly: the closed networks of today’s gatekeepers put a completely arbitrary limit on how users can extend and enrich their own conversations. On email, if you want to use a fancy new client like Superhuman - you can. If you want to hook up a digital assistant or translation service to help you wrangle your email - you can. If you want to hook up your emails to a CRM to help you run your business - you can. But with today’s gatekeepers, you have literally no control: you’re completely at the mercy of the service provider - and for something like WhatsApp or iMessage the options are limited at best.

Finally - all the users’ conversation metadata for that service (who talks to who, and when) ends up centralised in the gatekeepers’ databases, which then become an incredibly valuable and sensitive treasure trove, at risk of abuse. And if the service provider identifies users by phone number, the user is forced to disclose their phone number (a deeply sensitive personal identifier) to participate, whether they want to or not. Meanwhile the user is massively incentivised not to move away: effectively they are held hostage by the pull of the service’s network of users.

So, the DMA exists as a strategy to improve the situation for users and service providers alike by building a healthier dynamic ecosystem for communication apps; encouraging products to win by producing the best quality product rather than the biggest network. To quote Cédric O (Secretary of State for the Digital Sector of France), the strategy of the legislation came from Washington advice to address the anticompetitive behaviour of the gatekeepers “not by breaking them up… but by breaking them open.” By requiring the gatekeepers to open their APIs, the door has at last been opened to give users the option to pick whatever service they prefer to use, to choose who they trust with their data and control their conversations as they wish - without losing the ability to talk to their wider audience.

However, something as groundbreaking as this is never going to be completely straightforward. Of course while some basic use cases (i.e. non-E2EE chat) are easy to implement, they initially may not have a UX as smooth as a closed network which has ingested all your address book; and other use cases(eg E2EE support) may require some compromises at first. It’s up to the industry to figure out how to make the most of that challenge, and how to do it in a way which minimises the impact on privacy - especially for end-to-end encrypted services.

What problems need to be solved?

We’ve already written about this from a Matrix perspective, but to recap - the main challenge is the trade-off between interoperability and privacy for gatekeepers who provide end-to-end encryption, which at a rough estimate means: WhatsApp, iMessage, secret chats in Facebook Messenger, and Google Messages. The problem is that even with open APIs which correctly expose the end-to-end encrypted semantics (as DMA requires), the point where you interoperate with a different system inevitably means that you’ll have to re-encrypt the messages for that system, unless they speak precisely the same protocol - and by definition you end up trusting the different system to keep the messages safe. Therefore this increases the attack surface on the conversations, putting the end-to-end encryption at risk.

Alex Stamos (ex-CISO at Facebook) said that “WhatsApp rolling out mandatory end-to-end encryption was the largest improvement in communications privacy in human history” – and we agree. Guaranteed end-to-end encrypted conversations on WhatsApp is amazing, and should be protected at all costs. If users are talking to other users on WhatsApp (or any set of users communicating within the same E2EE messenger), E2EE should and must be maintained - and there is nothing in the DMA which says otherwise.

But what if the user consciously wants to prioritise interoperability over encryption? What if the user wants to hook their WhatsApp messages into a CRM, or run them through a machine translation service, or try to start a migration to an alternative service because they don’t trust Meta? Should privacy really come so spectacularly at the expense of user freedom?

We also have the problem of figuring out how to reference users on other platforms. Say that I want to talk to a user with a given phone number, but they’re not on my platform - how do I locate them? What if my platform only knows about phone numbers, but you’re trying to talk to a user on a platform which uses a different format for identifiers?

Finally, we have the problem of mitigating abuse: opening up APIs makes it easier for bad actors to try to spam or phish or otherwise abuse users within the gatekeepers. There are going to have to be changes in anti-abuse services/software, and some signals that the gatekeeper platforms currently use are going to go away or be less useful, but that doesn't mean the whole thing is intractable. It will require changes and innovative thinking, but we’ve been making steady progress (e.g. the work done by Element’s trust and safety team). Meanwhile, the gatekeepers already have massive anti-abuse systems in place to handle the billions of users within their walled gardens, and unofficial APIs are already widespread: adding official APIs does not change the landscape significantly (assuming interoperability is implemented in such a way that the existing anti-abuse mechanisms still apply).

In the past, gatekeepers dismissed the effort of interop as not being worthwhile - after all, the default course of action is to build a walled garden, and having built one, the temptation is to try to trap as many users as possible. It was also not always clear that there were services worth interoperating with (thanks to the chilling effects of the gatekeepers themselves, in terms of stifling innovation for communication startups). Nowadays this situation has fundamentally changed however: there is a vibrant ecosystem of open communication startups out there, and a huge appetite to build a vibrant open ecosystem for interoperable communication, but like the open web itself.

What are the requirements?

Before going further in considering solutions, we need to review the actual requirements of the DMA. Our best understanding at this point is that the DMA will mandate that:

  • Gatekeepers will have to provide open and documented APIs to their services, on request, in order to facilitate interoperability (i.e. so that other services can communicate with their users).
  • These APIs must preserve the same level of end-to-end encryption (if any) to remote users as is available to local users.
  • This applies to 1:1 messaging and file transfer in the short term, and group messaging, file-transfer, 1:1 VoIP and group VoIP in the longer term.

So, what could this actually look like?

The DMA legislation deliberately doesn’t focus on implementation, instead letting the industry figure out how this could actually work in practice. There are many different possible approaches, and so from our point of view as Matrix we’ve tried to sketch out some options to make the discussion more concrete. Please note these are preliminary thoughts, and are far from perfect - but hopefully useful as a starting point for discussion.

Finding Bob

Imagine that you have a user Alice on an existing gatekeeper, which we’ll call AliceChat, who runs an E2EE messaging service which identifies users using phone numbers. Say that they want to start a 1-to-1 conversation with Bob, who doesn’t use AliceChat, but Alice knows he is a keen user of BobChat. Today, you’d have no choice but to send them an SMS and nag them to join AliceChat (sucks to be them if they don’t want to use that service, or if they’re unable to for whatever reason - e.g. their platform isn’t supported, or their government has blocked access, etc), or join BobChat yourself.

However, imagine if instead the gatekeeper app had a user experience where the app prompted you to talk to the user via a different platform instead. It’d be no different to your operating system prompting you to pick which app to use to open a given file extension (rather than the OS vendor hardcoding it to one of their own apps - another win for user rights led by the EU!).

Now, the simplest approach in the short term would be for each gatekeeper to pre-provision a set of options of possible alternative networks. (The DMA says that, on request, other service providers can ask to have access to the gatekeeper’s APIs for the purposes of interoperability, so the gatekeeper knows who the alternative networks may be). “Bob is not on AliceChat - do you want to try to reach him instead on BobChat, CharlieChat, DaveChat (etc)”.

Much like users can configure their preferred applications for file extensions in an operating system today, users would also be able to add their own preferred service providers - simply specifying their domain name.

Connecting to Bob

Now, AliceChat itself needs to figure out how to query the remote service provider to see if Bob actually exists there. Given the DMA requires that gatekeepers provide open APIs with the same level of security to remote users as their local ones using today’s private APIs - and very deliberately doesn’t mandate specific protocols for interoperability - they will need to locate a bridge which can connect to the other system.

In this thought experiment, the bridge used would be up to the destination provider. For instance, could announce that AliceChat users should connect to it via using the AliceChat protocol(or via Matrix or via XMPP) by a simple HTTP API or even a .well-known URL. Users might also be able to override the bridge used to connect to them (e.g. to point instead at a client-side bridge), and could sign the advertisement to prove that it hadn’t been tampered with.

AliceChat would then connect to the discovered bridge using AliceChat’s vendor-specific newly opened API, and would then effectively treat Bob as if they were a real AliceChat user and client to all intents and purposes. In other words, Bob would effectively be a “ghost user” on AliceChat, and subject to all their existing anti-abuse mechanisms.

Meanwhile, the other side of the bridge converts through to whatever the target system is - be that XMPP, Matrix, a different proprietary API, etc. For Matrix, it’d be chatting away to a homeserver via the Application Service API (using End-to-Bridge Encryption via MSC3202). It’s also worth noting that the target might not even be a bridge - it could be a system which already natively speaks AliceChat’s end-to-end encrypted API, thus preserving end-to-end encryption without any need to re-encrypt. It’s also worth noting that while historically bridges have had a bad reputation as being a second class (often a second class afterthought), Matrix has shown that by considering them as a first class citizen and really focusing on mapping the highest common denominator between services rather than lowest common denominator, it’s possible for them to work transparently in practice. Beeper is a great example of Matrix bridging being used for real in the wild (rather amusingly they just shipped emoji reactions for WhatsApp on iOS via their WhatsApp<->Matrix bridge before WhatsApp themselves did…)

Architecturally, it could look like this:

Or, more likely (given a dedicated bridge between two proprietary services would be a bit of a special case, and you’d have to solve the dilemma of who hosts the bridge), both services could run a bridge to a common open standard protocol like Matrix or XMPP instead (thus immediately enabling interoperability with everyone else connected to that network):

Please note that while these examples show server-side bridges, in practice it would be infinitely preferable to use client-side bridges when connecting to E2EE services - meaning that decrypted message data would only ever be exposed on the client (which obviously has access to the decrypted data already). Client-side bridges are currently complicated by OS limits on background tasks and push notification semantics (on mobile, at least), but one could envisage a scenario where you install a little stub AliceChat client on your phone which auths you with AliceChat and then sits in the background receiving messages and bridging them through to Matrix or XMPP, like this:

Another possible architecture could be for the E2EE gatekeeper to expose their open APIs on the clients, rather than the server. DMA allows this, to the best of our knowledge - and would allow other apps on the device to access the message data locally (with appropriate authorisation, of course) - effectively doing a form of realtime data liberation from the closed service to an open system, looking something like this:

Finally, it's worth noting that when peer-to-peer decentralised protocols like P2P Matrix enter production, clientside bridges could bridge directly into a local communication server running on the handset - thus avoiding metadata being exposed on Matrix or XMPP servers providing a common language between the service providers.

Locating users

Now, the above describes the simplest and most naive directory lookup system imaginable - the problem of deciding which provider to use to connect to each user is shouldered by the users. This isn’t that unreasonable - after all, users may have strong feelings about what providers to use to talk to a given user. Alice might be quite happy to talk to Bob via BobChat, but might be very deliberately avoiding talking to him on DaveChat, for whatever ominous reasons.

However, it’s likely in future we will also see other directory services appear in order to map phone numbers (or other identities) to providers - whether these piggyback on top of existing identity providers (gatekeepers, DNS, telcos, SSO providers, governments) or are decentralised through some other mechanism. For instance, Bob could send AliceChat a blinded proof that he authorises them to automatically route traffic to him over at BobChat, with BobChat maintaining a matching proof that Bob is who he claims to be (having gone through BobChat’s auth process) - and the proofs could be linked using a temporary key such that Bob doesn’t even need to maintain a long-term one. (Thanks to James Monaghan for suggesting this one!)

Another alternative to having the user decide where to find each other could be to use a decentralised Keybase-style identity system to track verified mappings of identities (phone numbers, email addresses etc) through to service providers - perhaps something like IDX might fit the bill? While this decentralised identity lookups have historically been a hard problem, there is a lot of promising work happening in this space currently and the future looks promising.

Talking to Bob

Meanwhile, Alice still needs to talk to Bob. As already discussed, unless everyone speaks the same end-to-end encrypted protocol (be it Matrix, WhatsApp or anything else), we inevitably have a trade-off here between interoperability and privacy if Bob is not on the same system as Alice (assuming AliceChat is end-to-end encrypted) - and we will need to clearly warn Alice that the conversation is no longer end-to-end encrypted:

To be clear: right now, today, if Bob were on AliceChat, he could be copy-pasting all your messages into (say) Google Translate in a frantic effort to workaround the fact that his closed E2EE chat platform has no way to do machine translation. However, in a DMA world, Bob could legitimately loop a translation bot into the conversation… and Alice would be warned that the conversation was no longer secure (given the data is now being bridged over to Google).

This is a clear improvement in user experience and transparency. Likewise, if I’m talking to a bridged user today on one of these platforms, I have no way of telling that they have chosen to prioritise interop over E2EE - which is frankly terrifying. If I’m talking to someone on WhatsApp today I blindly assume that they are E2EE as they are on the same platform - and if they’re using an unofficial app or bridge, I have no way to tell. Whereas in a DMA world, you would expect the gatekeeper to transparently expose it.

If anything, this is good news for the gatekeeper in that it consciously advertises a big selling point for them: that for full E2EE, users need to talk to other users in the same walled garden (unless of course the platform speaks the same protocol). No more need for bus shelter adverts to remind everywhere that WhatsApp is E2EE - instead they can remind the user every time they talk to someone outside the walled garden!

Just to spell it out: the DMA does not require or encourage any reduction in end-to-end encryption for WhatsApp or similar: full end-to-end encryption will still be there for users in the same platform, including through to users on custom clients (assuming the gatekeeper doesn’t flex and turn it off for other reasons).

Obviously, this flow only considers the simple case of Alice inviting Bob. The flow is of course symmetrical for Bob inviting Alice; AliceChat will need to advertise bridges which can be used to connect to its users. As Bob pops up from BobChat, the bridge would use AliceChat’s newly open APIs to provision a user for him, authing him as per any other user (thus ensuring that AliceChat doesn’t need to have trusted BobChat to have authenticated the user). The bridge then sends/receives messages on Bob’s behalf within AliceChat.

Group communication

This is all very well for 1:1 chats - which are the initial scope of the DMA. However, over the coming years, we expect group chats to also be in scope. The good news is that the same general architecture works for group chats too. We need a better source of identity though: AliceChat can’t possibly independently authenticate all the new users which might be joining via group conversations on other servers (especially if they join indirectly via another server). This means adopting one of the decentralised identity lookup approaches outlined earlier to determine whether Charlie on CharlieChat is the real Charlie or an imposter.

Another problem which emerges with group chats which span multiple service providers is that of indirect routing, especially if the links between the providers use different protocols. What if AliceChat has a direct bridge to BobChat (a bit like AIM and ICQ both spoke OSCAR), BobChat and CharlieChat are connected by Matrix bridges, and AliceChat and CharlieChat are connected via XMPP bridges? We need a way for the bridges to decide who forwards traffic for each network, and who bridges the users for which network. If they were all on Matrix or XMPP this would happen automatically, but with mixed protocols we’d probably have to extend the lookup protocol to establish a spanning tree for each conversation to prevent forwarding loops.

Here’s a deliberately twisty example to illustrate the above thought experiment:

There is also a risk of bridge proliferation here - in the worst case, every service would have to source bridges to directly connect to every other service who came along, creating a nightmarish n-by-m problem. But in practice, we expect direct proprietary-to-proprietary bridges to be rare: instead, we already have open standard communication protocols like Matrix and XMPP which provide a common language between bridges - so in practice, you could just end up in a world where each service has to find a them-to-Matrix or them-to-XMPP bridge (which could be run by them, or whatever trusted party they delegate to).


A mesh of bridges which connect together the open APIs of proprietary vendors by converting them into open standards may seem unwieldy at first - but it’s precisely the sort of ductwork which links both phone networks and the Internet together in practice. As long as the bridging provides for highest common denominator fidelity at the best impedance ratio, then it’s conceptually no different to converting circuit switched phone calls to VoIP, or wired to wireless Ethernet, or any of the other bridges which we take entirely for granted in our lives thanks to their transparency.

Meanwhile, while this means a bit more user interface in the communication apps in order to select networks and warn about trustedness, the benefits to users are enormous as they put the user squarely back in control of their conversations. And the UX will improve as the tech evolves.

The bottom line is, we should not be scared of interoperability, just because we’ve grown used to a broken world where nothing can interconnect. There are tractable ways to solve it in a way that empowers and informs the user - and the DMA has now given the industry the opportunity to demonstrate that it can work.

Interoperability without sacrificing privacy: Matrix and the DMA

25.03.2022 22:39 — General Matthew Hodgson
Last update: 25.03.2022 18:01

Yesterday the EU Parliament & Council agreed on the contents of the Digital Markets Act - new legislation from the EU intended to limit anticompetitive behaviour from tech “gatekeepers”, i.e. big tech companies (those with market share larger than €75B or with more than €7.5B a year of revenue).

This is absolutely landmark legislation, where the EU has decided not to break the gatekeepers up in order to create a more competitive marketplace - but instead to “break them open”. This is unbelievably good news for the open Internet, as it is obligating the gatekeepers to provide open APIs for their communication services. In other words: no longer will the tech giants be able to arbitrarily lock their users inside their walled gardens - there will be a legal requirement for them to expose APIs to other services.

While the formal outcomes of yesterday’s agreement haven’t been published yet (beyond this press release), our understanding is that the DMA will mandate:

  • Gatekeepers will have to provide open and documented APIs to their services, on request, in order to facilitate interoperability (i.e. so that other services can communicate with their users).
  • These APIs must preserve the same level of end-to-end encryption (if any) to remote users as is available to local users.
  • This applies to 1:1 messaging and file transfer in the short term, and group messaging, file-transfer, 1:1 VoIP and group VoIP in the longer term.

This is the best possible outcome imaginable for the open internet. Never again will a big tech company be able to hold their users hostage in a walled garden, or arbitrarily close down or sabotage their APIs.

So, what’s the catch?

Since the DMA announcement on Thursday, there’s been quite a lot of yelling from some very experienced voices that mandating interoperability via open APIs is going to irrevocably undermine end-to-end encrypted messengers like WhatsApp. This seems to mainly be born out of a concern that the DMA is somehow trying to subvert end-to-end encryption, despite the fact that the DMA explicitly mandates that the APIs must expose the same level of security, including end-to-end encryption, that local users are using. (N.B. Signal doesn’t qualify as a gatekeeper, so none of this is relevant to Signal).

So, for WhatsApp, it means that the API would expose both the message-passing interface as well as the key management APIs required to interoperate with WhatsApp using your own end-to-end-encrypted WhatsApp client - E2EE would be preserved.

However, this does mean that if you were to actively interoperate between providers (e.g. if Matrix turned up and asked WhatsApp, post DMA, to expose an API we could use to write bridges against), then that bridge would need to convert between WhatsApp’s E2EE’d payloads and Matrix’s E2EE’d payloads. (Even though both WhatsApp and Matrix use the Double Ratchet, the actual payloads within the encryption are completely different and would need to be converted). Therefore such a bridge has to re-encrypt the traffic - which means that the plaintext is exposed on the bridge, putting it at risk and breaking the end-to-end encryption guarantee.

There are solutions to this, however:

  • We could run the bridge somewhere relatively safe - e.g. the user’s client. There’s a bunch of work going on already in Matrix to run clientside bridges, so that your laptop or phone effectively maintains a connection over to iMessage or WhatsApp or whatever as if it were logged in… but then relays the messages into Matrix once re-encrypted. By decentralising the bridges and spreading them around the internet, you avoid them becoming a single honeypot that bad actors might look to attack: instead it becomes more a question of endpoint compromise (which is already a risk today).

  • The gatekeeper could switch to a decentralised end-to-end encrypted protocol like Matrix to preserve end-to-end encryption throughout. This is obviously significant work on the gatekeeper’s side, but we shouldn’t rule it out. For instance, making the transition for a non-encrypted service is impressively little work, as we proved with Gitter. (We’d ideally need to figure out decentralised/federated identity-lookup first though, to avoid switching from one centralised identity database to another).

  • Worst case, we could flag to the user that their conversation is insecure (the chat equivalent of a scary TLS certificate warning). Honestly, this is something communication apps (including Matrix-based ones!) should be doing anyway: as a user you should be able to tell what 3rd parties (bots, integrations etc) have been added to a given conversation. Adding this sort of semantic actually opens up a much richer set of communication interactions, by giving the user the flexibility over who to trust with their data, even if it breaks the platonic ideal of pure E2E encryption.

On balance, we think that the benefits of mandating open APIs outweigh the risks that someone is going to run a vulnerable large-scale bridge and undermine everyone’s E2EE. It’s better to have the option to be able to get at your data in the first place than be held hostage in a walled garden.

Other considerations

One other complaint which has come up a bunch is around speed of innovation: the idea that WhatsApp or similar would be seriously slowed down by having to (effectively) maintain stable documented federation APIs, and figure out how to do backwards compatibility for new features. It’s true that this will take a bit more effort (similar to how adding GDPR compliance takes some effort), but the ends make it more than worth it. Plus, if the rag-tag Matrix ecosystem can do it, it doesn’t seem unreasonable to think that a $600B company like Meta can figure it out too...

Another consideration is that it might make it too easy to build malicious 3rd party clients - e.g. building your own "special" version of Signal which connects to the official service, but deliberately or otherwise has security flaws. The fact is that we're already in this position though: there are illicit alternative clients flying around all over the place, and the onus is on the app stores to protect their users from installing malware. This isn't reason to throw the baby of interoperability out with the bathwater of bootleg clients.

The final complaint is about moderation and abuse: while open APIs are good news for consumer choice, they can also be used by spammers, phishers and other miscreants to cause problems for the users within the gatekeeper. Much like a mediaeval citadel; opening up your walled garden means that both good and bad people can turn up. And much like real life, this is a solvable problem, even if it’s unfortunate: the benefits of free trade massively outweigh the downsides of having to police strangers more effectively. Frankly, moderation and anti-abuse approaches on the Internet today are infamously broken, with centralised moderation by gatekeepers producing increasingly erratic results. By opening the walled gardens, we are forcing a much-needed opportunity to review how to empower users and admins to filter unwanted content on their own terms. There’s a recent write-up of the proposed approach for Matrix at, which outlines one strategy - but there are many others. Honestly, having to improve moderation tooling is a worthwhile price to pay for the benefits of open APIs.

So, there you have it. Hopefully you’ll agree that the benefits here outweigh the risks: without open APIs we wouldn't even have the option to talk about interoperability. We should be celebrating a new dawn for open access, rather than fearing that the sky is falling and this is nefarious attempt to undermine end-to-end encryption.

This Week in Matrix 2022-03-25

25.03.2022 00:00 — This Week in Matrix Thib

Matrix Live 🎙

Dept of Status of Matrix 🌡️

Thib announces

You might have been following our past efforts on making sure the DMA was meaningful. Those efforts are being rewarded, and Amandine covers in a blog post what this means for Element and other businesses in Europe. Matthew covers what this means for Matrix and end to end ecrypted services.

Dept of Spec 📜

Andrew Morgan (anoa) announces

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

MSC Status

New MSCs:

MSCs in Proposed Final Comment Period:

MSCs in Final Comment Period:

Merged MSCs:

  • No MSCs were merged this week.

Spec Updates

Mostly continued review of MSCs, while implementation work continues on in the background.

Random MSC of the Week

The random MSC of the week is... MSC2499: Fixes for Well-known URIs!

This MSC proposes some much-desired practical and usability fixes to the "Well-Known" discovery method for Matrix homeservers. This is part of the system that enables homeserver's to "delegate" their homeserver address (your Matrix ID is, but your homeserver is listening for requests on

Well-known for homeserver delegation was introduced a number of years ago, and since then some friction has arisen from various implementations. This MSC aims to address a collection of them!

Dept of Servers 🏢

Synapse (website)

Synapse is a Matrix homeserver implementation developed by the core team

Brendan Abolivier says

Hey everyone! This week we've released Synapse 1.55, which includes a bunch of new features, performance improvements and bugfix. If you're using Mjolnir to moderate your rooms, and/or synctl to manage your homeserver, this release also introduces a few changes you definitely want to be aware of, head over to the announcement on the blog for more!

Yesterday, we noticed a compatibility issue with a newly released version of Jinja, which is the tool we use in Synapse to render e-mail and web templates. We've quickly put out Synapse 1.55.2 to address this - so if you were unable to start Synapse because of it just update and you should be fine 🙂 Note that this doesn't apply to deployments of Synapse using the matrixdotorg/synapse Docker image or Debian packages from since they are already using a compatible version of Jinja.

Apart from that, work continues towards integrating Poetry with Synapse, which should prevent this kind of issues from happening in the future, and on improving room join times.

Dendrite (website)

Second generation Matrix homeserver

neilalexander announces

We've just released Dendrite 0.7.0, which has quite a lengthy list of changes:

  • The roomserver input API will now queue all events into NATS, which provides better crash resilience
  • The roomserver input API now configures per-room consumers, which should use less memory
  • Canonical aliases can now be added and removed
  • MSC2946 Spaces Summary now works correctly, both locally and over federation
  • Healthcheck endpoints are now available at:
    • /_dendrite/monitor/up, which will return 200 when Dendrite is ready to accept requests
    • /_dendrite/monitor/health, which will return 200 if healthy and 503 if degraded for some reason
  • The X-Matrix federation authorisation header now includes a destination field, as per MSC3383
  • The /sync endpoint now uses less memory by only ranging state for rooms that the user has participated in
  • The /messages endpoint now accepts stream positions in both the from and to parameters
  • Dendrite will now log a warning at startup if the file descriptor limit is set too low
  • The federation client will now attempt to use HTTP/2 if available
  • The federation client will now attempt to resume TLS sessions if possible, to reduce handshake overheads
  • The built-in NATS Server has been updated to version 2.7.4
  • NATS streams that don't match the desired configuration will now be recreated automatically
  • When performing a graceful shutdown, Dendrite will now wait for NATS Server to shutdown completely, which should avoid some corruption of data on-disk
  • The create-account tool has seen a number of improvements, will now ask for passwords automatically
  • The /sync endpoint will no longer lose state events when truncating the timeline for history visibility
  • The /context endpoint now works correctly with lazy_load_members
  • The /directory/list/room/{roomID} endpoint now correctly reports whether a room is published in the server room directory or not
  • Some bugs around appservice username validation have been fixed
  • Roomserver output messages are no longer unnecessarily inflated by state events, which should reduce the number of NATS message size errors
  • Stream IDs for device list updates are now always 64-bit, which should fix some problems when running Dendrite on a 32-bit system
  • Purging room state in the sync API has been fixed after a faulty database query was corrected
  • The federation client will now release host records for remote destinations after 5 minutes instead of holding them in memory forever
  • Remote media requests will now correctly return an error if the file cannot be found or downloaded
  • A panic in the media API that could happen when the remote file doesn't exist has been fixed
  • Various bugs around membership state and invites have been fixed
  • The memberships table will now be correctly updated when rejecting a federated invite
  • The client API and appservice API will now access the user database using the user API rather than accessing the database directly

In addition, there are some minor changes for Docker users:

  • Docker images are now published to GitHub Container Register as well as Docker Hub — they can be found here
  • Docker images are now being automatically generated for the main branch by CI and will be available on the :main tag

As always, feel free to join us in for Dendrite-related discussion!

Dept of Bridges 🌉

matrix-appservice-kakaotalk (website)

A Matrix-KakaoTalk puppeting bridge.

Fair reports

This week brings yet more bugfixes & stability to DMs: now, there should be no trouble sending messages into a KakaoTalk DM that hasn't been active for a few days.

The other major improvements are:

  • A command for listing your KakaoTalk friends list, appropriately named list-friends
  • Receiving images from KakaoTalk

I had hoped to finish support for sending images from Matrix by today, but I couldn't quite crack it in time--either KakaoTalk changed their API for sending media messages, or I'm doing something wrong 🙃

Nonetheless, the bridge is rapidly approaching a state of being usable!

Discussion: Issue page:

Dept of Clients 📱

Syphon (website)

Chat with your privacy and freedom intact

0x1a8510f2 announces

Hi all 👋.

A little over a year has passed since our last update, but we're not dead! On the contrary, Syphon has seen some significant improvements over the last year both in terms of features and project structure; the project is more alive than ever before, and we're really excited to share some updates!

Core Team

Syphon now has a core team, consisting of (creator of Syphon),,, and (me)! With some of the workload now being shared, we're hoping Syphon will grow even faster with less time needed to review and merge PRs, triage and fix bugs, evaluate and implement features and answer support requests.

Cross-platform Availability

Syphon has been steadily expanding its list of supported platforms over the past year:

  • worked hard to bring Syphon to Windows with full feature parity, including (currently unofficial) Windows builds of Syphon.
  • has created an AUR package of Syphon for Arch Linux users.
  • I've been busy creating a flatpak for Syphon which is available on Flathub.
  • Regular and official ARM64 builds are also planned soon, with the first manual one already released. Once the CI infrastructure is properly set up, these will be included for every release and the flatpak will receive ARM64 support too!


Between 0.1.7 (21 Mar 2021) and 0.2.12 (23 Mar 2022), 21 releases were published. Of course, too much changed to list everything, but here are some highlights:

  • Multi-account support 🎉
  • Media messages 🎉
  • Markdown support 🎉
  • Message editing 🎉
  • Key import and export 🎉
  • App lock with encryption 🎉
  • HTTP proxy support 🎉
  • Theme tweaks
  • 3pid auth support
  • EXIF data removal from sent images
  • System brightness setting
  • Various customisation options
  • (Unencrypted) chat message search
  • Ability to deactivate an account
  • Countless new translations
  • Massive performance improvements
  • Numerous bug fixes (including encryption and SSO)
  • Lots of refactoring and cleanup

Many of these would not have been possible without our awesome contributors.


We have also received many contributions in the form of translations and Syphon now supports, at least partially, 26 languages. Of these, 6 languages are fully or almost fully translated. To deal with all the incoming translations, there is now also an official Weblate page for Syphon.

All of these translations are submitted by volunteers and we're really grateful for their contributions in making Syphon more accessible to an international audience.

Syphon Space

We also now have an official Syphon space which we use for support, development discussion or just friendly offtopic chat. Come join us if you like at!

SchildiChat (website)

SchildiChat is a fork of Element that focuses on UI changes such as message bubbles and a unified chat list for both direct messages and groups, which is a more familiar approach to users of other popular instant messengers.

SpiritCroc reports

SchildiChat-Android now has more styles of message bubbles! So if you prefer the Schildi-bubbles over the Element ones (which you can use too in SchildiChat if you want), you can now also select between bubbles with or without tail, and select some more round bubbles than what we had previously, which was a highly requested feature!

If you wonder what makes SchildiChat special except for the different design now that Element has bubbles as well: it's hard to describe in a couple of short sentences, as it's mostly in the details. So if you are interested in a list of things that we did on Android, I wrote up some aspects here. Note however that this list is usually not really kept up-to-date, and there might already be some things that are now outdated since I added them. However, it might give you some general ideas of what SchildiChat has to offer :)

Nheko (website)

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

Nico reports

Beep, boop, v0.9.3 is out. It's mostly bugfixes and small improvements, changelog below:


  • New upload UX
    • Queue multiple uploads by pasting or dragging multiple files.
    • Videos will now properly have a thumbnail as well as images.
    • Duration, width and height is now also properly included so that clients can resize appropriately.
    • Thumbnails are excluded if they are bigger than the original image. (tastytea)
  • Improvements for mobile devices (Malte E)
    • You should now be able to scroll by touching anywhere with no random dead zones.
    • Preedit text can now be used in a completer and is properly sent
    • If an input method is active, pressing Enter will not send the current message.


  • Optionally always open videos and images in an external program. (math)


  • Build macOS releases against Qt 5.15.3 to resolve missing spaces after some punctuation.
  • Send the shortcode as the body for stickers without a body.
  • Elide long usernames in the timeline. (Malte E)
  • Cleanup the reply popup. (Malte E)
  • Use standard buttons where possible. (tastytea)
  • Various improvements to the bubble layout. (Malte E)
  • Enable online key backup by default.
  • Update the bundled gstreamer in our Flatpaks.


  • Indonesian (Linerly)
  • Estonian (Priit)
  • Finnish (Priit)
  • Esperanto (Tirifto)


  • Fix hovering the action menu.
  • Try to avoid using unknown UIA flows.
  • Don't Components actively in use.
  • Fix screensharing.
  • Fix device id when doing SSO logins.

Downloads should be live now, flatpak might take a while to publish still :3

Fractal (website)

Matrix messaging app for GNOME written in Rust.

Julian Sparber reports

Hello folks, quick update on what major things happened in Fractal-next the last two month. The most exciting addition is definitely the SSO support we merged this week and therefore we could close a 2 years old issue.


  • You can now send files via drag-n-drop and via the file send button to a room. It also includes a nice preview for Images.
  • The timeline now shows audio messages with a small inline player.
  • Fractal-next lets you now remove messages you sent

Session verification

  • During first login, Fractal checks if the user hasn't started session verification from another client before offering to start a new one
  • The QrCode scanning is now spec compliant, and asks for user's confirmation after scanning.
  • We dropped screenshot support for QrCode scanning, since it makes the UX worse without adding any real benefit.

Room details

  • The room details show now the members of the room including the power level


  • Fractal-Next now supports SSO 🎉️
  • We implemented auto-discovery of the homeserver via .well-known

FluffyChat (website)

Krille Fear announces

Sorry that I was a little bit silent in the last weeks. So much stuff to do...

If you haven't heard it yet (because I have not made it that much public yet) there are experimental video calls in FluffyChat now. You need to enable them first under Settings > Chat and then you can try them out. They should be fully compatible with the Element video calls. But be aware that they are very unstable at the moment and may let your app crash.

FluffyChat 1.3.1 has been released

This release contains a lot of updated translations and bugfixes. I'm very excited about the new keyboard shortcuts from TheOneWithTheBrain. Also in your stories you can now pick the background color and the size of the picture. This is still a little bit experimental but I will share of course update the stories MSC asap. Thanks to all contributors and translators.


  • Allow app to be moved to external storage (Marcel)
  • Translated using Weblate (Arabic) (Mads Louis)
  • Translated using Weblate (Basque) (Sorunome)
  • Translated using Weblate (Basque) (—X—)
  • Translated using Weblate (Chinese (Simplified)) (Eric)
  • Translated using Weblate (Czech) (Sorunome)
  • Translated using Weblate (Dutch) (Jelv)
  • Translated using Weblate (English) (Raatty)
  • Translated using Weblate (French) (Anne Onyme 017)
  • Translated using Weblate (Galician) (Xosé M)
  • Translated using Weblate (German) (Maciej Krüger)
  • Translated using Weblate (Indonesian) (Linerly)
  • Translated using Weblate (Irish) (Graeme Power)
  • Translated using Weblate (Persian) (Anastázius Darián)
  • Translated using Weblate (Russian) (Nikita Epifanov)
  • Translated using Weblate (Swedish) (Joaquim Homrighausen)
  • Translated using Weblate (Turkish) (Oğuz Ersen)
  • Translated using Weblate (Ukrainian) (Ihor Hordiichuk)
  • Update proguard rules to a more modern setup (MTRNord)
  • chore: Minor story viewer fixes (Krille Fear)
  • chore: Remove story line count and make answering to stories online (Krille Fear)
  • chore: Update dependencies (Dependency Update Bot)
  • design: Make pinned events use less vertical space (Krille Fear)
  • feat: Extended stories (Krille Fear)
  • feat: Restrict map zoom to tile server capabilities (Marcel)
  • feat: implement keyboard shortcuts (TheOneWithTheBraid)
  • fix: Build on macOS (Krille Fear)
  • fix: Emojipicker issues (Krille Fear)
  • fix: Hide redacted stories (Krille Fear)
  • fix: Mark story as read (Krille Fear)
  • fix: Open room from notification click produces errors (Krille Fear)
  • fix: SSO on Android 12 (Krille Fear)
  • fix: Send read receipts on all taps (Krille Fear)
  • fix: make fluffy usable at 720 px wide (Raatty)
  • fix: Add forgotten sendOnEnter (Krille Fear)
  • refactor: Switch to just audio for playing sounds (Krille Fear)

Ement.el (website)

Matrix client for emacs

alphapapa announces

[[][Ement.el]], a Matrix client for Emacs, has learned to create new rooms and invite users to rooms. Feedback is appreciated; see our chat room, [[][]], or the issue tracker on the repo.

Element Web/Desktop (website)

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

kittykat announces

  • Threads will be released behind a labs flag in the next release and enabled by default in the Release Candidate (RC) from 5th April

  • If you’re using an older version of Synapse (<v1.55.0) you might experience compatibility problems with stable prefixes. After upgrading Element to v1.18.0 unstable threads will be moved to the main room timeline

  • Groups have been deleted on develop. It has also landed alongside other fairly major changes so please definitely report issues if you see them

  • Continuing work to remove skinning from the application. This is a fairly major change to how everything works under the hood, so when it lands please report any issues with the app as most will be subtle and therefore might be missed.

    • Currently expected to land on or about April 5th
    • Component replacement will still be possible (and this will be documented)
  • In labs (you can enable labs in settings on or on Nightly):

    • Thread list is now ordered by last reply

    • Fixes for the room list counter

    • Last stretch of threads acceptance testing before releasing to beta

    • Iteration to the new search dialog to integrate people & public rooms search into the new experience.

Element iOS (website)

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

Doug says

  • Element 1.8.7 was released on the App Store after delays with the review: we’ve made ignoring users easier and now suggest a Matrix ID when using “Sign in With Apple” to resolve the issue.
  • Space creation and management will be available in the next release, due next week.
  • We had some issues with publishing releases to TestFlight so the latest release candidates haven’t been updated publicly - we have been testing them internally so releases will not be delayed

Element Android (website)

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

adam reports

Our current in progress release 1.4.6+ is running a little behind schedule, however when it does land it'll contain:

  • Fixes in the timeline for missing messages, inconsistent read marker, decryption crashes and the room icon looking like donut
  • Improved Threads via MSC3440
  • The ability to share a user specified location

For the forks, a heads up that we've updated our development branch Kotlin version to 1.6.0 which involved overhauling a lot of our when statements

Dept of Ops 🛠

Synatainer (website)

Synapse Maintenance Container – Docker container with tools for synapse & postgres database maintenance

saces reports

Synatainer v0.3.1 has been released

New since v0.2.0

  • add a db-shell and scripts to reset the state compressor
  • add options for passing purge/keep room lists

Start it without command and let it do its magic :)

What it does by default:

  • daily:
    • purge all rooms without local members
    • run the state autocompressor (small setting 500/100)
  • weekly:
    • delete old remote media (>90 days)
    • delete old message history from public joinable rooms (>180 days)
  • monthly:
    • run the state autocompressor (big setting 1500/300)
    • vacuum the database



Compose example:

If you are looking for a docker container with just the auto compressor for linux amd64/arm64 in it, her you go:

Dept of Bots 🤖

Mjölnir (website)

The moderation bot for Matrix

Gnuxie announces

We have released Mjölnir v1.4.1 (via v1.4.0)

Which in addition to fixes, includes a few new tools that you might find useful:

  • a protection for detecting & measuring federation lag in your rooms
  • bugfixes for the synapse antispam module (in particular squashing a bug that was removing users from the profile directory when blocking was disabled)
  • a new message length limiter for the antispam module
  • a new command to grab admin permissions from rooms being administrated by users on your homeserver
  • a command to show when users in a given room have joined
  • another command to filter through recent room joiners by the time they joined.
  • Improvements that make writing protections easier.

Don't forget you can join our development room if you have any have any questions for setting up and running Mjölnir!

Dept of Events and Talks 🗣️

HarHarLinks announces

don't miss on March 30th!

Thib adds

The theme of the episode is "analytics and privacy". We will have guests from the awesome non-profit Exodus Privacy to shed some light on analytics: what can your apps know about you and how you can get better informed.

Nad from Element will give us the perspective from the other side: as a vendor, does it make sense to use analytics? Are there better alternatives? Is there a way to do it right?

Join us in #otwsu and on

Dept of Ping 🏓

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

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

RankHostnameMedian MS

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

RankHostnameMedian MS

That's all I know 🏁

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

Synapse 1.55 released

22.03.2022 00:00 — Releases Brendan Abolivier

Hi all, Synapse 1.55 is out! Let's see the main talking points of this new release.

Update: After the initial release of Synapse 1.55, the developers of a third-party tool (Jinja, which is the tool Synapse uses to render email and web templates) released a new version of their project which proved incompatible with Synapse. To address this issue, we have released Synapse 1.55.2.

Deployments of Synapse using the matrixdotorg/synapse Docker image or Debian packages from are not affected as they are already using a compatible version of the tool.

It's worth noting that the work we are doing to integrate Poetry into Synapse (more on that a bit further in this post) will, once completed, prevent this kind of issues from happening.

Removing support for Mjolnir 1.3.1 and older

Administrators of large homeservers and communities will already be familiar with Mjolnir, which is a tool designed to help them moderate a large number of rooms in an efficient way. It includes a bot as well as a Synapse module to better interface with the homeserver.

Due to a change in how we manage some of Synapse's internal utilities, this release of Synapse breaks compatibility with Mjolnir versions 1.3.1 and older. Homeserver administrators using Mjolnir and upgrading to Synapse 1.55 should make sure they're running Mjolnir version 1.3.2 or later.

See the upgrade notes for more information.

Moving synctl

synctl is a tool provided as part of Synapse to run and manage your instance and its workers (if any).

As part of our work to integrate Poetry in Synapse (which in turn will enable a lot of cool things, such as reproducible builds), we have recently moved the way we package this tool. As of this release, homeserver administrators should stop invoking it using its direct path (e.g. /path/to/synctl start), but should instead call it directly, e.g. synctl start.

This means homeserver administrators using synctl must make sure that the tool is in their PATH. This is automatically done when installing and upgrading Synapse using the matrixdotorg/synapse Docker image or Debian packages from When installing from a wheel, sdist, or PyPI, an executable is created in your Python installation's bin directory.

See the upgrade notes for more information.

Everything else

This release also introduces new module callbacks, allowing homeserver administrators to more efficiently review which users are able to deactivate users and shutdown rooms. More information on that in Synapse's documentation.

We have also started experimenting with using the native Python asyncio event loop in Synapse which, if successful, would make it easier to use building blocks from the Python ecosystem when adding new features to Synapse.

See the full changelog for a complete list of changes in this release. Also please have a look at the upgrade notes for this version.

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Dirk Klimpel, Beeper, and ~creme.