This Week in Matrix 2021-07-02

02.07.2021 21:03 — This Week in Matrix Ben Parsons
Last update: 02.07.2021 19:28

Matrix Live 🎙

Dept of Status of Matrix 🌡️

We missed it at the time, but wanted to share in TWIM. Terence Eden, noted UK technologist, shared a thorough, compelling argument for the UK Government to use Matrix as a foundation for the digital workplace.

This is a long read, but a detailed argument. Also please note that this is was produced for the purpose of an MSc course of study, it was not commissioned for any other purpose, as the preamble makes clear.

Next, a high billing for Beeper this week, who have been working hard and getting product out!

Beeper update

Tulir reported:

It's been a month since our last update. A lot of the work since then has been on making everything more reliable, but we've also added new features to our clients and started making some new bridges.


  • Added thread UI for Slack-bridged rooms. Internally they're just replies like before, but the client will intelligently collapse replies in Slack rooms into threads.

  • Merged upstream Element additions like voice messages.


  • Released Beeper iOS to Testflight.


  • Added grouping rooms by chat network based on the m.bridge state event. The UI is similar to spaces, but they're not actual Matrix spaces (yet).

  • Added support for Android 11's "conversation" notifications.


  • Android Messages is turning out difficult to reverse-engineer to a sufficiently reliable level, so we're building a new SMS bridge into our Android app. It'll also be available as a standalone open-source app, which already exists at (but doesn't have any setup instructions yet).

  • We've funded development of a LinkedIn bridge. sumner will post a more detailed update about that.

We're hiring React, iOS, Android and SRE/Devops engineers. If you're interested, check out or DM Eric Migicovsky.


Dept of Spec 📜

MSC state changes:

Bruno has been working on aggregations as part of his work for Hydrogen. He reported:

I've been cleaning up the relations MSCs, finding a balance between documenting the current state and not losing track of community concerns. I've started with MSC 2674 which is the very basic format of relations, and will move on to annotations/reactions (MSC 2677) next week.

Spec progress graph

Dept of Servers 🏢


Synapse is a popular homeserver written in Python.

callahad announced:

We're pleased to announce the release of Synapse 1.37.1 this week, which includes mitigations for the recent distributed spam attack across the public Matrix network. We advise upgrading as soon as possible.

Otherwise, Synapse 1.37 highlights include:

...and a bunch of smaller bug fixes and performance improvements.

Check out the blog post for more.

Homeserver Deployment 📥️


Ananace offered:

Got another week of Helm Chart updates, with the Synapse chart getting a bunch of worker improvements and additional configurability, as well as being updated to first 1.37.0 and then 1.37.1

Dept of Bridges 🌉

LinkedIn <-> Matrix Bridge

sumner reported:

I'm excited to announce that I started working on a new bridge for bringing LinkedIn messages to Matrix! It's currently in the early stages of development and not production-ready. The current feature set includes: backfill from LinkedIn, user name and profile picture sync, message sending from Matrix -> LinkedIn, and real-time message puppetting from LinkedIn -> Matrix. There's much more to come, and you can join for updates. Development is being funded by Beeper, and is being designed with integration into Beeper as it's primary goal. However, the bridge is open source (Apache 2.0) and will be available to self-host. The source code is here:

Great work from Sumner! Glad to see people have the option to bridge their LinkedIn messages!

matrix-puppeteer-line update

Fair reported:

matrix-puppeteer-line: A bridge for LINE Messenger based on running LINE's Chrome extension in Puppeteer.

Better LINE->Matrix read receipt bridging is now supported in the testing branch! The bridge now checks all LINE chats (not just the most recently-used one) to see if messages you sent have been read (in LINE). This works by cycling through all LINE chats where the final message is posted by you and doesn't have a "Read" marker on it yet (or for multi-user chats, if your last message hasn't been read by everyone in the room).

With that, I'll consider the bridge to be in Early Beta! 🎉 I'm now testing the bridge for myself to iron out a few kinks, and am preparing a PR to the webpage to have this listed on

Discussion: Issue page:

Matrix Adapter for WebThings 0.4.0

Christian told us:

This addon for the WebThings gateway lets you send Matrix messages when your IoT fridge is empty – or whatever you have connected to your gateway.

The update fixes predefined messages getting sent to the default room and is the first to be tested against gateway version 1.0.0. or in the addon list of your WebThings gateway

Dept of Clients 📱


Carl Schwan announced:

This week, NeoChat gained support for a Global Menu on Plasma and macOS. Aside from that, we fixed a few crashes.

But the biggest news of the week is that we will get funding from NLNet to implement E2EE support in Quotient and NeoChat as part of their grants to improve the internet. We will report on our progress on that front here!

This is terrific news, big thanks to NLNet for making this choice!


FluffyChat is the cutest cross-platform matrix client. It is available for Android, iOS, Web and Desktop.

krille said:

FluffyChat 0.33.0 has been released.

Just a more minor bugfixing release with some design changes in the settings, updated missing translations and for rebuilding the arm64 Linux Flatpak.


  • redesigned settings

  • Updated translations - thanks to all translators

  • display progress bar in first sync

  • changed Linux window default size

  • update some dependencies


  • Favicon on web

  • Database not storing files correctly

  • Linux builds for arm64

  • a lot of minor bugs


Nheko is a desktop client using Qt and C++17. It supports E2EE and intends to be full featured and nice to look at

Nico ( offered:

Hello World! I am here to bring you Nheko news!

We merged the Spaces branch, which means Nheko master can now show some spaces. Peeking unjoined rooms, nesting spaces and creating them should be coming soon. We are also looking into how to fit knocking into the UI (we already rendered incoming knocks in the timeline for a while).

You can also now edit still pending messages, which should help if your server is slow and you notice a typo. The edit will then get queued and be sent as soon as the server acknowledges they received the original message. Apart from that there have been some improvements to the readability of the room list and some other UI elements.

Last but not least, we switched out our entire http backend from Boost to Curl. For that I wrote a simple wrapper around Curl. This fixes about 10 issues around connection shutdown, brings proxy support, http/2 and http/3 support and in general makes Nheko crash less and reduces latency a LOT! This will obviously cause some pain for packagers, but I hope it isn't too bad. Some of the issues this fixes only had 2 digits in our bugtracker and one was even filed by benpa!

Have a nice weekend everyone! ♥



Alexandre Franke told us:

Chris tweaked the UI in various places. It’s a lot of small details that together make for a smoother experience. I encourage you to read the details in the description of !782. This is the only MR that landed since last week, but our people have been hard at work nonetheless. Kai blogged about his journey working on the search bar of doom and Alejandro shared his own struggle. In the meantime, Julian’s work has mostly happened upstream in matrix-rust-sdk.

Element Clients

Updates sent by the teams

Delight team

  • Spaces:
    • Research: We’ve been reaching out to people to walk us through how they use Spaces now and what they’d like to see different to help us learn and iterate;
    • Restricted room access: Some good progress towards shipping improved team spaces


  • v1.7.32-rc.1 is on in advance of release on Monday - please test!
  • Some major progress on conversion to TypeScript, finding some bugs along the way. The main source of the element-desktop project is now fully converted to TypeScript!
  • A styled player component for the audio messages feature, available in the labs section.



  • We are actively implementing the highly expected voice message feature!
  • A release candidate v1.1.12 will be available during the week-end
  • We are focusing to fix some crashes, to improve the stability of the application

Vocie messages!


tusooa reported:

kazv is a matrix client based on libkazv.

Talk to us on .


  1. fixed a thread-safety issue that caused crashes.

  2. We now have a new developer . She implemented a login failure prompt for kazv.

You can get the current AppImage build at .

Dept of SDKs and Frameworks 🧰

matrix-bot-sdk v0.5.19

TravisR announced:

v0.5.19 of the matrix-bot-sdk is out now with fixed power level checking (with an added utility function), improved default error logging, and a typo fix in reply creation. Check it out, and visit for help & support.

Dept of Ops 🛠

Matrix Navigator 0.1.2

Christian told us:

It's an alpha-stage webapp for developers to replace curl for room state administration.

This week I added features for better member management, including kick, ban and unban.

Dept of Services 🚀

GoMatrixHosting v0.5.1 🚀

Michael told us:

Exciting new update, we can now wireguard an on-premises server from just about anywhere and make it work with the AWX system. This is useful when your server doesn't have a static or public IP address, or when some other networking issue prevents you from running a Matrix service on it.

Follow of on GitLab:

Or come say hello on Matrix:

* Add '00 - Create Wireguard Server' template for AWX admin to provision Wireguard servers that on-premises servers can use to connect.

* Subscription involved can view an additional '0 - {{ subscription_id }} - Provision Wireguard Server' template.
* Add /docs/ guide.

* Add onboarding script for Windows 10 users.
* Raise maximum download size to 200MB.

Dept of Bots 🤖


TravisR offered:

Mjolnir is a moderation bot for communities on Matrix. It helps with a lot of the actions covered by the moderation guide, including capabilities to apply bans from other trusted communities. It's still a bit terse in its documentation, but if you're looking for a featureful moderation bot then it's worth a go.

In related news, Mjolnir v0.1.18 is out with a couple quality of life fixes - if you've been bothered by the log spam, it's now fixed :)

Dept of Guides 🧭

Matrix Limits

Ryan said:

I started a tiny repo to collect various limits and related factoids about the Matrix specification and implementations. I hope that distilling and summarising such things at glance will make it easier to see what is and is not possible.

If you know of more that should be listed, please contribute! 🙂

Self hosting your own Matrix server on a Raspberry Pi

Peter Roberts announced: of has written a guide on getting started with Synapse on a Raspberry Pi using Docker Compose. You can read it here.

Public Rooms News 🏟️

Matrix Science Reading Group

Florian said:

Together with J. Ryan Stinnett, I created the 🔖 for exchange of and on scientific papers, books and related resources on all things Matrix: Topics ranging from peer-to-peer broadcast overlay networks over conflict-free replicated data types to end-to-end encryption. Investigating security, performance, deployability, or whatever else is interesting, by methods from observation over simulation to formal verification. 🎓️ Please join if you want to read about papers that might not be Matrix-related enough to make it into TWIM, or want to engage in the discussion. 😊 The resulting papers are collected at:

German Element translation feedback

Libexus announced:

Hallo deutschsprachige Matrix-Community! ist ein Raum für Feedback zur deutschsprachigen Übersetzung aller Element-Clients.

Hast du einen Fehler gefunden, ist etwas unklar oder hast du ein Anliegen an uns? Dann schreibe es gerne hier hinein!

Jederzeit willkommen sind natürlich auch neue Übersetzerinnen und Übersetzer. Joint dazu einfach, und lest euch den Translation Guide durch.

Hello German-speaking Matrix community! is a room for feedback about the German translation of Element.

Have you found a mistake, is something unclear or do you have a suggestion? Please write it there!

Also, we are always happy about new translators (for all languages!). Just join and have a look at the translation guide on how to get started!

Room of the week

timokoesters told us:

Hi everyone! Did you ever feel lost in the Matrix world? The room directory is big, but it's still hard to find something you like. Or are you a room moderator, but there is not much activity in your room because it doesn't have enough users?

This is why I want to share rooms (or spaces) I find interesting.

This week's room is:

"A public space for Free/Open Source Software maintainers to swap notes and discuss their craft. Inspired by, all maintainers welcome!"

If you want to suggest a room for this section, tell me in

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!

Security update: Synapse 1.37.1 released

30.06.2021 00:00 — Releases Matthew Hodgson

Hi all,

Over the last few days we've seen a distributed spam attack across the public Matrix network, where large numbers of spambots have been registered across servers with open registration and then used to flood abusive traffic into rooms such as Matrix HQ.

The spam itself has been handled by temporarily banning the abused servers. However, on Monday and Tuesday the volume of traffic triggered performance problems for the homeservers participating in targeted rooms (e.g. memory explosions, or very delayed federation). This was due to a combination of factors, but one of the most important ones was Synapse issue #9490: that one busy room could cause head-of-line blocking, starving your server from processing events in other rooms, causing all traffic to fall behind.

We're happy to say that Synapse 1.37.1 fixes this and we now process inbound federation traffic asynchronously, ensuring that one busy room won't impact others. First impressions are that this has significantly improved federation performance and end-to-end encryption stability — for instance, new E2EE keys from remote users for a given conversation should arrive immediately rather than being blocked behind other traffic.

Please upgrade to Synapse 1.37.1 as soon as possible, in order to increase resilience to any other traffic spikes.

Also, we highly recommend that you disable open registration or, if you keep it enabled, use SSO or require email validation to avoid abusive signups. Empirically adding a CAPTCHA is not enough. Otherwise you may find your server blocked all over the place if it is hosting spambots.

Finally, if your server has open registration, PLEASE check whether spambots have been registered on your server, and deactivate them. Once deactivated, you will need to contact [email protected] to request that blocks on your server are removed.

Your best bet for spotting and neutralising dormant spambots is to review signups on your homeserver over the past 3-5 days and deactivate suspicious users. We do not recommend relying solely on lists of suspicious IP addresses for this task, as the distributed nature of the attack means any such list is likely to be incomplete or include shared proxies which may also catch legitimate users.

To ease review, we're working on an auditing script in #10290; feedback on whether this is useful would be appreciated. Problematic accounts can then be dealt with using the Deactivate Account Admin API.

Meanwhile, over to Dan for the Synapse 1.37 release notes.

Synapse 1.37 Release Announcement

Synapse 1.37 is now available!

**Note: ** The legacy APIs for Spam Checker extension modules are now considered deprecated and targeted for removal in August. Please see the module docs for information on updating.

This release also removes Synapse's built-in support for the obsolete ACMEv1 protocol for automatically obtaining TLS certificates. Server administrators should place Synapse behind a reverse proxy for TLS termination, or switch to a standalone ACMEv2 client like certbot.

Knock, knock?

After nearly 18 months and 129 commits, Synapse now includes support for MSC2403: Add "knock" feature and Room Version 7! This feature allows users to directly request admittance to private rooms, without having to track down an invitation out-of-band. One caveat: Though the server-side foundation is there, knocking is not yet implemented in clients.

A Unified Interface for Extension Modules

Third party modules can customize Synapse's behavior, implementing things like bespoke media storage providers or user event filters. However, Synapse previously lacked a unified means of enumerating and configuring third-party modules. That changes with Synapse 1.37, which introduces a new, generic interface for extensions.

This new interface consolidates configuration into one place, allowing for more flexibility and granularity by explicitly registering callbacks with specific hooks. You can learn more about the new module API in the docs linked above, or in Matrix Live S6E29, due out this Friday, July 2nd.

Safer Reauthentication

User-interactive authentication ("UIA") is required for potentially dangerous actions like removing devices or uploading cross-signing keys. However, Synapse can optionally be configured to provide a brief grace period such that users are not prompted to re-authenticate on actions taken shortly after logging in or otherwise authenticating.

This improves user experience, but also creates risks for clients which rely on UIA as a guard against actions like account deactivation. Synapse 1.37 protects users by exempting especially risky actions from the grace period. See #10184 for details.

Smaller Improvements

We've landed a number of smaller improvements which, together, make Synapse more responsive and reliable. We now:

  • More efficiently respond to key requests, preventing excessive load (#10221, #10144)
  • Render docs for each vX.Y Synapse release, starting with v1.37 (#10198)
  • Ensure that log entries from failures during early startup are not lost (#10191)
  • Have a notion of database schema "compatibility versions", allowing for more graceful upgrades and downgrades of Synapse (docs)

We've also resolved two bugs which could cause sync requests to immediately return with empty payloads (#8518), producing a tight loop of repeated network requests.

Everything Else

Lastly, we've merged an experimental implementation of MSC2716: Incrementally importing history into existing rooms (#9247) as part of Element's work to fully integrate Gitter into Matrix.

These are just the highlights; please see the Upgrade Information and Release Notes for a complete list of changes in this release.

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 aaronraimist, Bubu, dklimpel, jkanefendt, lukaslihotzki, mikure, and Sorunome,

This Week in Matrix 2021-06-25

25.06.2021 00:00 — This Week in Matrix Ben Parsons

Matrix Live 🎙

  • Valere presents the latest Spaces UX
  • Neil Alexander shows off P2P progress
  • ChristianP shows Matrix Navigator
  • Eric Eastwood (Gitter fellow!) shows off MSC2716 (message history batches)
  • Rich vdH presents Jaeger for Synapse profiling
  • Bruno presents reactions in Hydrogen

Dept of Status of Matrix 🌡️

Room of the week

timokoesters said:

Hi everyone! Did you ever feel lost in the Matrix world? The room directory is big, but it's still hard to find something you like. Or are you a room moderator, but there is not much activity in your room because it doesn't have enough users?

This is why I want to share rooms (or spaces) I find interesting.

This week's space is: RPG

Biggest room: #D&

"Casual chat about Dungeons & Dragons, tabletop RPG, OSR, DM tips, player stories, world building, and more."

If you want to suggest a room for this section, tell me in

Dept of Spec 📜


anoa told us:

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:

MSCs in Final Comment Period:

  • No MSCs are in FCP.

New MSCs:

Spec Updates

Spaces work continues with MSC3083 (Restricted room memberships), which will include a new room version due to the new join_rule of `restricted. On the other side of things, MSC3245 (voice messages) and by extension extensible events, is moving as the implementation work is pushed forward. Lots of activity on MSC3215 (improved moderation tooling) as well which will no doubt prove to be invaluable as the Matrix network continues to grow.


Dept of Servers 🏢


Conduit is a Matrix homeserver written in Rust

timokoesters reported:

After some more work on swappable database backends, I worked on a few small features:

  • User directory improvements (show remote users and appservice puppets)

  • /state endpoint

  • /event_auth endpoint

  • Filter our room directory based on the search term

  • /search over multiple rooms


Synapse is a popular homeserver written in Python.

anoa said:

Knock, knock TWIM! It's a new week, and I'm filling in for Dan today to bring you an update on Synapse's latest progress!

Hot off the heels of Synapse 1.36.0’s release last week, we’ve put out 1.37.0rc1! It includes the long-awaited “room knocking” feature (note that no clients currently support knocking), a completely reworked pluggable modules interface and experimental support for backfilling history into rooms. With knocking support in, this means Synapse now has support for room v7!

Among those exciting updates, we also have the usual churn of bug fixes and improvements across the board. Many updates to the documentation as well as we lean into using the new Synapse documentation site more and more. Please help us test the RC if you can!

Homeserver Deployment 📥️


Ananace offered:

This week too sees some Kubernetes chart updates, with element-web being updated to 1.7.31 and matrix-synapse getting some fixes for envvars and mounts, as well as some improvements to the ingress support.


Mamie offered:

YunoHost is an operating system aiming for the simplest administration of a server, and therefore democratize self-hosting.

Synapse integration had been updated to 1.34.0 (1.35.1 available in branch testing)

Element Web integration had been updated to 1.7.28 (1.7.29 available in branch testing)

Dept of Bridges 🌉


Eric Eastwood offered:

It has been several months since we last updated you on MSC2716 for backfilling historical messages into existing rooms but we made some big progress this week and merged an experimental Synapse implementation taking us one step closer to importing the massive archive of messages on Gitter over to Matrix! This iteration will only make the historical messages visible on the local homeserver but we have plans to make them federate in the next. It's still early days on this before we can actually use it on Gitter. Here is a proof of concept to get your juices flowing:


Dept of Clients 📱


A minimal Matrix chat client, focused on performance, offline functionality, and broad browser support.

Bruno said:

Released Hydrogen 0.2.0 with:

  • support for receiving and sending reactions ❤👍🚀
  • adds a right panel with basic room information, thanks to @MidhunSureshR! Watch this space in the near future for more functionality soon.

Loving Hydrogen right now. It's fast and works great! See Bruno present reactions as one of the Matrix Live demos (scroll up)


Carl Schwan announced:

In terms of code, this week we didn't get much activity. The only noteworthy news is that we can now send spoilers, and use two new commands: /tableflip and /unflip thanks to Smitty van Bodegom.

Aside from that, we had 2 productive BoFs during Akademy 2021. The first one was about creating a library with shared chat visual components for KDE's chat apps: NeoChat for Matrix, Tok for Telegram and Kaidan for XMPP, KDE Connect and Spacebar for SMS, ... The second BoF was more about NeoChat and Quotient and we discussed how to move forwards with some problems (e.g. non-hacky text input auto-completion) but also the roadmap around E2EE, Spaces and Widgets support. Speaking about E2EE, we will have some very good news to announce next week, stay tuned!

/me only learned about /tableflip and /unflip this today... and looking forward to this E2EE news!


Alexandre Franke announced:

In the past couple of weeks, Alejandro and Kai started the coding period of their GSoC internship and explained on their blogs what they will be working on. Their projects are respectively to add support for multiple accounts, and to bring Fractal Next to feature parity with current stable. Read more details on their blogs, and subscribe to them to keep informed as they go!

Julian managed to land the “Explore” view, our room directory. There may be some changes down the road, but it looks good for now:


Newcomer Giuseppe De Palma removed bashisms from our git hook because they were preventing him from contributing. They then went on to tweak the history style to remove the grey background around it. They also got rid of a papercut from the login form: before his intervention, users needed to provide the full homeserver URL with the http:// or https:// scheme prefix. It will now default to HTTPS.

We also did some housekeeping work that should improve the experience for people joining us on the Fractal Next fun. After being away for a while, Christopher Davis came back with a patch to add a couple more build related directories to our .gitignore. Julian cleaned up the pseudo-milestone description that we had in the README, now that we have a proper Gitlab milestone. And finally, I added a warning on the login screen to better reflect on the Work In Progress state of the branch.

Element Clients

Updates from the teams! Android will return next week.

Delight team

  • Spaces:
    • Drag and drop for reordering Spaces is now live on Android! And testable on develop for Web
    • We’ve also added labs flags to Web & Android to test a few different things, in particular
      • Toggling ‘Home’ to show all rooms, or only rooms which don’t belong to Spaces
      • Toggling to not show People in Spaces
    • Please try them out! After living with a different config for a few days, we’d love to hear your feedback!


  • 1.7.31 released on Monday
  • Nightly builds of Element Desktop optimised for Apple silicon are now available for testing! Please give it a try and report any issues.
  • Added to room directory on develop, staging, and app. It will appear in desktop builds as well next time they update.
  • On develop
    • Various CI tweaks and performance improvements
  • In flight
    • Adding large account performance tests


  • 1.4.2 released on Monday. 1.4.3 with the fix on wellknown on Thursday
  • Fix a bug where the wellknown was no more fetched
  • Device dehydration is available in the SDK
  • Still good progress on voice messages


kitsune offered:

0.0.95 RC is out, available from the usual place at GitHub, and also as Flatpak from Flathub. The usual stabilisaton/bug fixing work, no new features compared to betas. This version is considerably better, and more stable, than - packagers are welcome to push it as if it were the final release. Translators, please help to complete more languages: Polish is at 90%, Spanish almost 80%, and French just below 60% - you can make a difference!

Dept of Encryption 🔐

New paper: “Key Agreement for Decentralized Secure Group Messaging with Strong Security Guarantees”

Florian offered:

Here is a scientific paper for all interested in decentralized end-to-end encryption cryptography protocols, like Matrix' Megolm, or the MLS future of Matrix: The preprint “Key Agreement for Decentralized Secure Group Messaging with Strong Security Guarantees” by Weidner, Kleppmann et al., which will appear in the ACM CCS 2021 Conference, surveys existing centralized and decentralized end-to-end cryptography protocols, Olm/Megolm (labeled as “Matrix”) among them, and discusses why the Messaging Layer Security (MLS) IETF draft has its problems with decentralization. Following that, they come up with their own decentralized protocol, including a security and performance analysis. They improve asymptotic complexity when compared to Olm/Megolm, and the assumptions on the underlying communication layer are easily fulfilled by Matrix. They also discuss that the very good asympotic complexity of MLS cannot be reached for a decentralized end-to-end cryptography protocol.

Dept of SDKs and Frameworks 🧰


kitsune reported:

Last week's news actually, but libQuotient master branch can built with Qt 6 now, laying ground for the GSoC works on PyQuotient - Python bindings for libQuotient. The library has also been updated to follow the latest CS API specification, which means basic low-level support for knocking, with higher-level library API for it coming later.

🧙 Polyjuice Util

Polyjuice Client is a Matrix library for Elixir

uhoreg said:

Polyjuice Util is a library of Matrix functions for Elixir that can be used for both client-side and server-side applications. Polyjuice Util 0.2.0 has been released, which includes functions for common errors, handling identifiers, and for checking room permissions. Thanks to Nico for his contributions to this release. This release also contains some backward-incompatible changes. See the changelog for more information.

Polyjuice Client 0.4.1 has also been released, which uses the new Polyjuice Util release, and adds support for the whoami endpoint (thanks to multiprise).

Dept of Ops 🛠

synadm 0.30

jojo said:

Hello dear Synapse Admins, synadm v0.30 is out. lt seems I was in "story telling mode" already when I wrote the release notes yesterday. That should perfectly suit a TWIM article as well 🙂 So there you go, copy/pasted from with love:


synadm finally got some nicely rendered documentation pages hosted at

"Login as a user" admin API support:

New subcommand matrixsupporting execution of regular Matrix commands. As a first shot a command to issue any Matrix API call has been implemented:

  • synadm matrix raw endpoint/url -m post -f data.json

  • synadm matrix raw endpoint/url -m put -d '{"key1": "value1"}' --prompt

  • The new command's docs

Note that this is meant to be a convenience function in case a Synapse homeserver admin wants to quickly help users e.g set specific settings available via regular Matrix calls and not the Synapse admin API directly. Also note that it is not meant to replace the awesome Matrix CLI tools that are already out there. matrix-commander, matrixcli to mention just a few.

The second command below matrix is:

It implements a plain login on a Matrix server using username and password. It can even be used to retrieve a token for an admin user, e.g helpful for setting up fresh synadm installations. Read about it here


The README has been updated to point to the nicely rendered docs recently published at


Update via PyPI or git as described in the update chapter:

Thanks to the friendly people in for reviewing, testing, discussing functionality and giving advice. And for this release, a special thanks to

Matrix Navigator v0.1.1

Christian said:

Matrix Navigator aims to be a replacement for curl when querying and mutating room states, including permissions.

  • Plenty of fixes (reminder, this is still alpha software)

  • Allows to join, leave rooms and inviting users.

  • New wide-screen layout

  • Errors are now shown in input fields or alerts.

Code and roadmap:

Dept of Services 🚀

Thoughts on Matrix account ownership

Thib told us:

with the change of policy we deployed on GNOME's Matrix instance, it occurred to me that we had overlooked an important aspect in our relationship with Matrix: do we own our Matrix account? And the answer is... maybe! In this post I cover the differences between personal account, organisation-owned account, the importance of segregating activities on Matrix... and why this may change with Portable Identities in the future

Dept of Jobs 💰️

Tchap are hiring!

Thib reported:

the French government deployed Tchap, an instant messaging based on Matrix. They are looking for tech and processes oriented people to improve the service. (🇫🇷) (🇫🇷)

Final Thoughts 💭

Andy reported:

I know this isn't TWIM-worthy, but I figured people in this room would find it interesting: yesterday there was a very popular post on reddit about how we don't appreciate email enough, and in the comments there were some mentions of matrix as the counterpart for messaging:

Actually I think this is very interesting. Worth taking a read to understand how people not already using Matrix might see the world.

Dept of Ping 🏓

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

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

RankHostnameMedian MS

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

RankHostnameMedian MS

That's all I know 🏁

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

This Week in Matrix 2021-06-18

18.06.2021 00:00 — This Week in Matrix Ben Parsons

Matrix Live 🎙

Talking to Half-Shot about Libera Chat IRC bridging.

Dept of Status of Matrix 🌡️

GNOME community loves Matrix

Thib reported:

The GNOME community loves Matrix and wants it to grow! That's why it's closing registrations on its instance. What? Yes, we want both to provide the best experience for our community and to be a good citizen in the Matrix universe.

Dept of Spec 📜

anoa said:

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

Closed MSCs:

Merged MSCs:

MSCs in Final Comment Period:

New MSCs:

Spec Updates

Feedback from the Spec Core Team has landed on MSC3244: Room version capabilities, MSC3083: Restricted room membership and a myriad of others. Travis has stormed in with MSC3245: Voice messages via Extensible Events and MSC3246: Audio event/waveform representation in extensible events and as a result MSC1767: Extensible Events has gotten some love.

Finally MSC3173: Expose stripped state events to potential joiners reached FCP this week, which is a step towards informing clients about the state of a room before they attempt to join or knock on it, which allows for nicer client UX when deciding whether you want to join a room or not.


Dept of Servers 🏢


callahad offered:

This week's big news is the release of Synapse 1.36 which completely eliminates memory spikes when joining rooms! I'll let the "Joining Matrix HQ" graph speak for itself:


We also fixed a few bugs with presence (especially over federation or on a worker process), and would strongly encourage you to upgrade.

We'll spend the next few weeks on smaller changes as we prepare our Q3 goals, but we look forward to sharing those with you when we have them.

Happy weekend, TWiM!

Happy weekend to you too! Let's upgrade to 1.36 this weekend!


f0x said:

Actively deployed to's Synapse now, and running very smoothly. Happy graphs show 91% of requests are handled without Synapse involved.

Also demonstrated the very seamless drop-in enable and disable, just changing the reverse proxy url back and forth from Synapse, and with this you could cautiously try this out for your own server, but stay in touch with


Got an update after realizing that's horrible but technically correct server discovery didn't get handled correctly yet

Homeserver Deployment 📥️


Ananace told us:

This week sees another installation of the regular Kubernetes updates, bumping the Synapse chart and image to 1.36.0

Dept of Bridges 🌉


hifi offered:

Heisenbridge roundup!

Heisenbridge is a bouncer-style Matrix IRC bridge.

  • Plumbing private/invite-only rooms is possible

  • IRC quit messages are visible as leave reasons

  • Nick changes are now displayed in leave reason instead of a notice

  • Prioritized Matrix->IRC queue for improved responsiveness while sending out a lot of messages

  • Improved AUTOCMD with multi-command support

  • Improved ZNC support with display of external messages by yourself

  • Improved plumbing message formatting: ZWSP in sender names, smarter truncation

  • IRC user displayname cases update if PRIVMSG source differs from current

  • New rooms respect cases of IRC nicks and channels

  • Conduit related fixes, thanks Peetz0r!

  • Channels with keys on IRCnet now rejoin correctly

  • Finally 100% working identd so it works on all tested networks

  • Cleaned up SASL support which makes server messages during authentication visible

  • Proper cleanup when leaving Heisenbridge rooms

  • Tiny bugfixes everywhere!

Currently working towards 1.0 release so mostly bug hunting and improving existing code and features.

Call for mutual help! The plumb feature needs more testing on busy IRC channels. If you need to plumb public Matrix rooms and IRC channels on any IRC network that does not have a public bridge available or just want to use a relaybot on IRC side for some reason hit me up on and we can setup a test plumb, free of charge! Only requirements are that I can lurk around to monitor how it works and there's nothing offensive on-topic.

In other news @warthog9 submitted an article to how to use ZNC and Heisenbridge together to keep using your existing IRC bouncer with Heisenbridge as a client for it. Pretty cool stuff!


matrix-appservice-irc weights in at release 0.27.0

Half-Shot told us:

Hola everyone! Today we're releasing the latest in bridge greatness, matrix-appservice-irc 0.27.0. This release contains the bulk of our work done for As always, thanks to the community for testing, writing up issues and creating PRs so that we can build better bridges to our friends on other networks.

The highlights are:

  • Username/password SASL authentication support. The bridge now lets you set a !username.

  • Bridge operators can now choose to block messages in the I->M direction while Matrix users are not joined to IRC as a privacy preservation technique.

  • You can now configure the bridge to publish rooms to the public room directory (rather than the appservice directory). The bridge can now also use the whole alias namespace (e.g. -> #foo).

  • Numerous bug fixes and quality of life fixes!

This is now live on, and will be live on the other bridges very soon!

Watch Matrix Live for more from Half-Shot.


Fair reported:

matrix-puppeteer-line: A bridge for LINE Messenger based on running LINE's Chrome extension in Puppeteer.

Even more read receipt improvements are here! In summary, with the magic of MSC2409, the bridge shouldn't ever "view" a LINE chat on your behalf in order to sync a message (which would send a read receipt to your chat contacts, even though you didn't read the chat yourself). For LINE messages that require viewing its chat in order to be bridged, like images/stickers (to get the image) and messages in multi-user chats (to know who sent them), the bridge instead sends a "placeholder" message that gets updated with the real LINE message content when you view the placeholder. That way, the bridge will only view a LINE chat when you view its Matrix portal.

A few stability fixes have been pushed as well. Namely, sync should be less likely to accidentally skip chats.

Only one final read receipt improvement remains, for LINE->Matrix read receipt bridging (which I mentioned last week): to make the bridge check all LINE chats (not just the most recently-used one) to see if messages you sent have been read (in LINE). This will work by cycling through all LINE chats where the final message is posted by you and doesn't have a "Read" marker on it yet.

Once that is taken care of, I'll consider the bridge to be in beta! 🎉


Issue page:

Dept of Clients 📱

Element Clients

Updates from the teams

Delight team

  • Spaces:
    • The highly requested drag & drop for reordering of Spaces has entered RC, expect it soon
    • New settings to setup aliases for spaces will also land in next release
    • Ongoing work to improve team spaces with restricted rooms.
    • We have a plan for iOS


  • 1.7.31 RC on staging
    • Various tweaks and improvements to the Spaces beta experience
    • Added room intro warning when E2EE is not enabled
    • Improved message forwarding UI
    • Improved timeline reflow and room list filter performance
  • On develop
  • In flight
    • Continuing to improve application performance
    • Working on Apple silicon desktop builds
    • Working on translation mismatch errors
    • Starting work on message bubbles, building on existing work from the community
    • Fuzzy matching for the room list filter in progress
  • Coming soon
    • Voice messages: we're in the testing stages and looking for feedback before they go live. Give it a go and let us know!


  • The new side menu and the new UI to join a room by alias are on develop.
  • The security settings screen has been updated to match the UX of element-web. The iOS app now uses the same wording for “Security Phrase” and “Security Key”
  • Device dehydration now works in the SDK. We need to polish the work before merging the PR
  • Voice message is still progressing well. We need to figure out how we will deal with the ogg format on iOS. We also need to add a cache to improve performance in the audio (and encryption) processing


  • Theme changes are now merged on develop and will be included in release 1.1.10. All the themes and styles have been moved to a dedicated gradle module. This is the first step to be able to develop new app features using dedicated modules. Other steps are required for us to be able to do that though (create a core module, etc.).
  • All the PlayStore descriptions have been pushed to the PlayStore using Fastlane, should be live soon. F-Droid already has the up to date translations for the store assets. Thanks to all the contributors on Weblate!
  • Release 1.1.10 will be prepared today. Expect it to be in production next week if everything is fine.


Carl Schwan said:

Last week was another busy week in NeoChat. Carl made the room list sidebar resizable and improved the responsive design of the settings pages.

Janet Blackquill implemented custom emojis using the im.ponies.user_emotes extension. For now auto-completion works, the custom emojis will be displayed in the emoji picker and lastly there is also an UI to add new emojis. We plan to implement more of the im.ponies MSC (custom stickers, sticker pack) soon :)



Smitty van Bodegom implemented spoilers and added /j and /leave alias for /join and /part. He also fixed the spellchecker trying to spellcheck commands like /rainbowme.

Oh and finally NeoChat was also featured on last week's "This Week in Linux" podcast: Don't forget to follow us on Twitter @NeoChatKDE or Mastodon @[email protected], to get your latest news about NeoChat.

Akademy is also happening this weekend and next week. KDE is using Matrix and BigBlueButton for the conference. There will be a lot of talk, training and bofs. We have a bof the 22th June at 16th. It's virtual and everyone is welcome to join and discuss with us NeoChat development.


FluffyChat is the cutest cross-platform matrix client. It is available for Android, iOS, Web and Desktop.

krille offered:

FluffyChat 0.32.0 is out now 💪 and targets improved stability and a new onboarding flow where single sign on is now the more prominent way to get new users into the app.

This release also introduces a complete rewritten database under the hood based on the key value store Hive instead of sqlite.

This should improve the overall stability and the performance of the web version.


[pioneer] told us:

Here's the FluffyChat subreddit, in order to provide more structured way of discussions, keep questions asked again and again in one place, and refer to older answers whenever the need is, as well as just to hang out


Nheko is a desktop client using Qt, Boost.Asio and C++17. It supports E2EE and intends to be full featured and nice to look at

Nico ( told us:

We've slowly been adding spaces support. Nheko can now show your spaces in the sidebar, filter on them and show a (very basic) overview page for a space. We are still playing around with what to actually put there, allow you to expand and collapse subspaces in the sidebar and allowing you to peek into rooms in a space, which you haven't joined yet. Creating and modifying spaces is also still work in progress until we figure out a proper design for it.


Nheko also now supports deeplinking using the matrix:// scheme


Dept of SDKs and Frameworks 🧰

Matrix Dart SDK

krille offered:

The Dart language now has a new SDK for Matrix developed and maintained by and published here:

It provides a fully featured base for Dart and Flutter applications including E2EE, and Cross Signing. After more than 2 years of development we now declared it as stable. The Matrix Dart SDK (formerly known as famedly SDK) was initially a rewrite of the FluffyChat backend which was written in JavaScript. It came a long way since then and is now the base for the Famedly App and for the Flutter version of FluffyChat.

Hyper-targeted callback: Hey Naren, Famedly are the Matrix-using folk I was telling you about. This is the latest version of their Dart work and will be a great place to start building from.


tusooa offered:

kazv is a matrix client based on libkazv.

Talk to us on .


We got an AppImage build for x86-64 GNU/Linux systems. Feel free to try -))

Dept of Ops 🛠

Matrix Navigator

Christian announced:

Hi, I started a small, static webapp last weekend for viewing and modifying room states.

It can locally store multiple access tokens and helps debug and maintain room permissions. It's not looking fancy yet but already proved useful for many of the IRC support requests.

2021-06-18-fhMmB-Screenshot2021-06-18at17-33-21MatrixNavigator.png (statically hosted) (license not yet decided)

Dept of Bots 🤖


Tulir told us:

The GitLab maubot plugin recently received major improvements to webhook handling. The Matrix messages now look much nicer (similar to the GitHub maubot plugin) and it also sends fancy reactions for CI status.

It's already in use in and Beeper's internal commit log room. It's unfortunately not yet available on, because I'm too lazy to write a migration script to copy data from the very old standalone gitlab bot written in Go.

In the future I might figure out some interoperability between the github and gitlab plugins so that I can also get CI reactions for my repos (which are primarily on github, but have CI on gitlab)


Dept of Events and Talks 🗣️

Interoperability event hosted by, and featuring, Matrix

Denise offered:

Tomorrow Element will host an event alongside Protonmail, Open-Xchange and Open Forum Europe on the DMA and the topic of interoperability. This will be hosted on Matrix, based on the infrastructure first used during FOSDEM. The event will be livestreamed over on

Registration is free here:

NB this event took place earlier in the week, but we still wanted to honour it!

Message à Caractère Informatique

Brendan Abolivier announced:

I've been invited to appear in the latest episode of Clever Cloud's tech podcast Message à Caractère Informatique, where we talked mostly about Matrix and decentralisation, but also about a bunch of other interesting things ranging from timbl minting his source code as an NFT to how to hack autonomous car with sound. It was loads of fun, thanks to them for the invite!

The episode, which is in French (sorry non-French speakers!), is available here:

Perhaps to pique (French word?) our interest Brendan Abolivier added:

(if anyone's curious about the autonomous car hacking, which I found particularly interesting, the paper we were discussing is in english 😛)

Dept of Interesting Projects 🛰️


MTRNord said:

After some fixes the bot is now back in shape. This means that all Rooms should again have the correct names from now on and accept invites again. Be aware the bot currently doesnt support encrypted rooms.

As a side effect also now found 3x the rooms as before.

Also the webpage got a big overhaul which brings a lot more mobile phone friendliness :) So you can finally properly use it on your phone as well.

Another change is that tombstoned rooms now get filtered from the list to keep it clean.

For developers a API reference is now available at

Also if you use the apis please note that the content is gzip encoded. The server currently doesnt respect the Accept-Encoding Header.

On the side of internal changes is now that the retries are limited to 5 times instead the previously buggy amount. This should reduce join requests from my server drastically.

For people usings the /servers api endpoint there is also now a include_members option. This means

now also gives unique servers based on known members.

Dept of Guides 🧭

A Matrix bot created with Simple-Matrix-Bot-Lib!

krazykirby99999 reported:

This bot is written with short, easy to understand Python code. Try writing your own bot with Python and Simple-Matrix-Bot-Lib!

This project is also a bot in itself, but I believe it is a great form of documentation, hence Guides section.

Easy guide to joining Matrix

Bram told us:

After having tried to convince several people to join the Matrix, my main conclusion is that it's too difficult for people. Apps that big tech companies produce are so simple that having to choose a client, choose (or set up) a homeserver and building bridges is too much of a push factor from the Matrix.

To help those people, I've written a quick guide that should help people without a programming background join the Matrix. I'm using this as a reference when people ask how they could join the Matrix, feel free to do this yourself as well:

Matrix in the News 📰

German universities survey

Remember the survey of German universities we reported on a few weeks ago? There is now an english-language version of the results available.

Wired article now online

Cat announced:

Remember the Wired article we spotted in the print edition and got a blurry picture of? It has now made it onto their website.

Final Thoughts 💭

Room of the week

timokoesters reported:

Hi everyone! Did you ever feel lost in the Matrix world? The room directory is big, but it's still hard to find something you like. Or are you a room moderator, but there is not much activity in your room because it doesn't have enough users?

This is why I want to share rooms (or spaces) I find interesting.

This week's room is:

"People reading eBooks usually know Calibre (, one of the most prominent ebook management solutions by Kovid Goyal. We've had an "unofficial" (as in: Kovid doesn't like real-time communications :) ) channel on what used to be freenode that I've moved to Libera and which is - of course! - bridged to #calibre" ~Philantrop

If you want to suggest a room for this section, send a Matrix message in

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.36.0 released

15.06.2021 11:20 — Releases Dan Callahan
Last update: 14.06.2021 23:14

Synapse 1.36.0 is out, and it's a big one!

Room Join Memory Improvements

We did it! Synapse no longer experiences a memory spike when joining large / complex rooms.

Memory usage graph for Synapse 1.33 and 1.36

These improvements mainly arise from processing join responses incrementally, rather than trying to load everything into memory at once. However, realizing these gains involved a fair bit of rewriting, as the entire processing pipeline had to work incrementally, and with appropriately sized batches, to avoid downstream bottlenecks. You can hear more about our original plans for this work in last month's Matrix Live: S6E23 — Dan and Erik talk about Synapse.

Presence Improvements

Running presence on a single worker process is now expected to work correctly. This feature first debuted in Synapse 1.33, but a few bugs cropped up which could lead to presence state becoming outdated. With #10149 merged, we believe the last of these issues to be resolved.

We had also noticed a recent increase in presence load on federation workers; this was ultimately tracked to two bugs, both fixed in this release: We were processing local presence via federation workers (#10163) and we were occasionally sending duplicate presence updates (#10165).

With both issues fixed, outgoing federation load has returned to normal levels:

Graph of outgoing federation transaction rate ranging from around 75 Hz down to under 25 Hz

(Thank you to David Mehren for this graph from issue #10153)

Everything Else

Synapse now has two new Admin APIs for unprotecting and removing media from quarantine, thanks to contributions by dklimpel.

Synapse now implements the stable /_matrix/client/r0/rooms/{roomId}/aliases endpoint originally introduced by MSC2432, and, thanks to contributions by govynnus, makes the reason and score fields of event reports optional per MSC2414.

These are just the highlights; please see the Release Notes for a complete list of changes in this release.

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 14mRh4X0r, aaronraimist, bradtgmurray, crcastle, dklimpel, govynnus, and RhnSharma.

Adventures in fuzzing libolm

14.06.2021 00:00 — Security Denis Kasak


Hi all! My name is Denis and I'm a security researcher. Six months ago, I started working for Element on doing dedicated security research on important Matrix projects. After some initial focus on Synapse, I decided to take a closer look at libolm. In this entry, I'd like to present an overview of that work, along with some early fruits that came out of it.

TL;DR: we found some bugs which had crept in since libolm's original audit in 2016, thanks to properly overhauling our fuzzing capability, and we'd like to tell you all about it! The bugs were not easily exploitable (if at all), and have already been fixed.

Update: CVE-2021-34813 has now been assigned to this.

To give a bit of a background, libolm is a cryptographic library implementing the Double Ratchet Algorithm pioneered by Signal and it is the cryptographic workhorse behind Matrix. The classic algorithm is called Olm in Matrix land, but libolm also implements Megolm which is a variant for efficient encrypted group chats between many participants.

Since libolm is currently used in all Matrix clients supporting end-to-end encryption, it makes for a particularly juicy target. The present state of libolm's monopoly on Matrix encryption is somewhat unfortunate -- luckily there are some exciting new developments on the horizon, such as the vodozemac implementation in Rust. But for now, we're stuck with libolm.

To start, I decided to do a bit of fuzzing. libolm already had a fuzzing setup using AFL, but it was written a while ago. The state of the art in fuzzing had advanced quite rapidly in the last few years, so the setup was missing many modern features and techniques. As an example, the fuzzing setup was configured to use the now ancient afl-gcc coverage mode, which can be slower than the more modern LLVM-based coverage by a factor of 2.

I also noticed that the fuzzing was done with non-hardened binaries (instead of using something like ASAN), so many memory errors could've gone unnoticed. There were also no corpora available from previous fuzzing runs and some of the newer code was not covered by the harnesses.


I decided to tackle these one by one, adding ASAN and MSAN builds as a first step. I took the opportunity to switch to AFL++ since it is a drop-in replacement and contains numerous improvements, notably improved coverage modes which are either much faster (e.g. LLVM-PCGUARD) or guaranteed to have no collisions (LTO)1. AFL++ also optimizes mutation scheduling (by using scheduling algorithms from AFLFast) and mutation operator selection (through MOpt). All of this makes it much more efficient at discovering bugs.

After this, I changed the existing harnesses to use AFL's persistent mode (which lowers process creation overhead and thus increases fuzzing performance). This change, combined with the switch to a newer coverage mode, increased the fuzzing exec/s from ~2.5k to ~5.5k on my machine, so this is not an insignificant gain!


In the context of fuzzing, collisions are situations where two different execution paths appear to the fuzzer as the same one due to technical limitations. Classically, AFL tracks coverage by tracking so-called "edges" (or "tuples"). Edges are really pairs of (A, B), where A and B represent basic blocks. Each edge is meant to represent a different execution "jump", but sometimes, as the number of basic blocks in a program grows, two different execution paths can end up being encoded as the same edge. LTO mode in AFL++ does some magic so that this is guaranteed not to happen.

After this preparatory work, I generated a small initial corpus and ran a small fleet of fuzzers with varying parameters. Almost immediately, I started getting heaps of crashes. Luckily, after some investigation, these turned out not to be serious bugs in the library but a double-free in the fuzzing harness! The double-free only got triggered when the input was of size 0. It also only happened with AFL++ and not vanilla AFL, presumably due to differences in input trimming logic, which must be the reason no one noticed this earlier. I quickly came up with a patch and resumed.

The plot thickens

I let the fuzzers run for a while. Since ASAN introduces a bit of a performance overhead, I only run a single AFL instance with ASAN variant of the binary. This is okay because all fuzzer instances actually synchronize their findings, which means every instance gets to see every input which increases coverage. When I came back to check, there was another crash waiting. This time the crashing input wasn't being generated continually so it looked much more promising -- and only the ASAN instance was crashing. A-ha!

Running the offending input on the ASAN variant of the harness revealed it was an invalid read one byte past the end of a heap buffer. The read was happening in the base64 decoder:

❮ ./build/fuzzers/fuzz_group_decrypt_asan "" pickled-inbound-group-session.txt <input
==1838065==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf4a00795 at pc 0x56560660 bp 0xffff9df8 sp 0xffff9de8
READ of size 1 at 0xf4a00795 thread T0
    #0 0x5656065f in olm::decode_base64(unsigned char const*, unsigned int, unsigned char*) src/base64.cpp:124
    #1 0x565607b5 in _olm_decode_base64 src/base64.cpp:165
    #2 0x565d5a9e in olm_group_decrypt_max_plaintext_length src/inbound_group_session.c:304
    #3 0x56558e75 in main fuzzers/fuzz_group_decrypt.cpp:46
    #4 0xf7509a0c in __libc_start_main (/usr/lib32/
    #5 0x5655a0f4 in _start (/home/dkasak/code/olm/build/fuzzers/fuzz_group_decrypt_asan+0x50f4)

0xf4a00795 is located 0 bytes to the right of 5-byte region [0xf4a00790,0xf4a00795)
allocated by thread T0 here:
    #0 0xf7a985c5 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x56558ce3 in main fuzzers/fuzz_group_decrypt.cpp:32
    #2 0xf7509a0c in __libc_start_main (/usr/lib32/

SUMMARY: AddressSanitizer: heap-buffer-overflow src/base64.cpp:124 in olm::decode_base64(unsigned char const*, unsigned int, unsigned char*)
Shadow bytes around the buggy address:
  0x3e9400a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e9400b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e9400c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e9400d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e9400e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x3e9400f0: fa fa[05]fa fa fa 05 fa fa fa fa fa fa fa fa fa
  0x3e940100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e940110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e940120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e940130: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e940140: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc

Following the stack trace, I quickly pinpointed the root of the bug: the logic of the decoder was subtly flawed, unconditionally accessing a remainder byte2 in the base64 input which might not actually be there. This occurs when the input is 1 (mod 4) in length, which can never happen in a valid base64 payload, but of course we cannot assume all inputs are necessarily valid payloads. Specifically, if the payload was not 0 (mod 4) in length, the code was assuming it was at least 2 (mod 4) or more in length and immediately read the second byte. This spurious byte was then incorporated into the output value.


By remainder byte, I mean bytes which are not part of a group of 4. These can only occur at the end of a base64 payload and they're the ones that get suffixed with padding in padded base64.

I examined the code in an attempt to find a way to have it leak more than a single byte, but it was impossible. As it turned out, not even the full byte of useful information was encoded into the output -- due to the way the byte is encoded, only about 6 bits of useful information ended up in the output value.

Still, even a single leaked bit is too much in a cryptographic context. Could we do some heap hacking so that something of interest is placed there and then have it be leaked to us?

I next tracked down all call sites of the vulnerable function olm::decode_base64. Most of them were immune to the problem since they were preceded with calls to another function, olm::decode_base64_length, which checks that the base64 payload is of legal length. This left me with only a few potentially vulnerable call sites, so I examined where their base64 inputs come from. Promisingly, two of them received input from other conversation participants, but they either had no way of leaking the information back to the attacker or they hardcoded the number of bytes to be processed, after ensuring the input was of some minimum length. The output of the remaining function olm_pk_decrypt is never sent anywhere externally, so there was again no way of leaking the data to the attacker.

In conclusion, even though this invalid read is a valid bug, I was not able to find a working exploit for it.

But wait a second! Something was still bothering me about olm_pk_decrypt. It's a fairly complex function, receives several string inputs from the homeserver and it itself isn't tested by any of the harnesses. Furthermore, the reason I started looking at it in the first place is that it was missing the olm::decode_base64_length check. Perhaps it warrants a closer look?

It does

And sure enough, there was something amiss. As olm_pk_decrypt receives three base64 inputs from the homeserver: the ciphertext to decrypt, an ephemeral public key and a MAC. All three are eventually passed to olm::decode_base64 to be decoded. Yet there was only a single length check there, to ensure the decrypted ciphertext would fit its output buffer. What would happen if the server returned a public key that was longer than expected?

struct _olm_curve25519_public_key ephemeral;
    (const uint8_t*)ephemeral_key, ephemeral_key_length,
    (uint8_t *)ephemeral.public_key

As can be seen from the snippet, the decoded version of public key gets written to ephemeral.public_key, which is an array allocated on the stack. If the input is longer than expected, this will become a stack buffer overflow.

The purpose of olm_pk_decrypt is to decrypt secrets previously stored by a Matrix device on the homeserver. The point of encryption is to prevent the server from learning these secrets since they're supposed to be known only by your own devices. One use case for this mechanism is to allow one of your devices to store encrypted end-to-end encryption keys on the homeserver. Your other devices can then retrieve those keys from the homeserver, making it possible to view all of your private conversations on each of your devices.

I decided to go for an end-to-end test to confirm the bug is triggerable by connecting with the latest Element Android from my test phone to my homeserver, with mitmproxy sitting in between. This allowed me to write a small mitmproxy script which intercepts HTTP calls fetching the E2E encryption keys from the homeserver and modifies the response so that the key is longer than expected.

import json

from mitmproxy import ctx, http

def response(flow: http.HTTPFlow) -> None:
    if ("/_matrix/client/unstable/room_keys/keys" in flow.request.pretty_url
            and flow.request.method == "GET"):

        response_body = flow.response.content.decode("utf-8")
        response_json = json.loads(response_body)

        rooms = response_json["rooms"]
        room_id = list(rooms.keys())[0]

        sessions = rooms[room_id]["sessions"]
        session = list(sessions.keys())[0]
        session_data = sessions[session]["session_data"]

        ephemeral = session_data["ephemeral"]"Replacing ephemeral key '{ephemeral}' with '{ephemeral * 10}'")
        session_data["ephemeral"] = ephemeral * 10

        modified_body = json.dumps(response_json).encode("utf-8")
        flow.response.content = modified_body

This longer value is then eventually passed by Element Android to libolm's olm_pk_decrypt, which triggers the buffer overflow. With all of that in place, I deleted the local encryption key backup on my device and asked for it to be restored from the server:

F libc    : stack corruption detected (-fstack-protector)
F libc    : Fatal signal 6 (SIGABRT), code -6 (SI_TKILL) in tid 24517 (DefaultDispatch), pid 24459 (
F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG   : Build fingerprint: 'xiaomi/tissot/tissot_sprout:9/PKQ1.180917.001/V10.0.24.0.PDHMIXM:user/release-keys'
F DEBUG   : Revision: '0'
F DEBUG   : ABI: 'arm64'
F DEBUG   : pid: 24459, tid: 24517, name: DefaultDispatch  >>> <<<
F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
F DEBUG   : Abort message: 'stack corruption detected (-fstack-protector)'
F DEBUG   :     x0  0000000000000000  x1  0000000000005fc5  x2  0000000000000006  x3  0000000000000008
F DEBUG   :     x4  0000000000000000  x5  0000000000000000  x6  0000000000000000  x7  0000000000000030
F DEBUG   :     x8  0000000000000083  x9  7d545b4513138652  x10 0000000000000000  x11 fffffffc7ffffbdf
F DEBUG   :     x12 0000000000000001  x13 0000000060b0f2a9  x14 0022ed916fede200  x15 0000d925cd93f18f
F DEBUG   :     x16 00000079e741b2b0  x17 00000079e733c9d8  x18 0000000000000000  x19 0000000000005f8b
F DEBUG   :     x20 0000000000005fc5  x21 0000007940e3c400  x22 000000000000026b  x23 00000000000001d0
F DEBUG   :     x24 000000000000002f  x25 000000793d9653f0  x26 0000007948303368  x27 0000007945dd5588
F DEBUG   :     x28 00000000000001d0  x29 0000007945dd37d0
F DEBUG   :     sp  0000007945dd3790  lr  00000079e732e00c  pc  00000079e732e034


This vulnerability is a server-controlled stack buffer overflow in Matrix clients supporting room key backup.

Of course, the largest fear stemming from any remotely controlled stack buffer overflow is code execution. This is perhaps even doubly so in a cryptographic library, where we have the additional worry of an attacker being able to leak our dearly protected conversations.

The federated architecture of Matrix may be somewhat of a mitigating circumstance in this case, since users are much more likely to know and trust the homeserver owner, but we don't want to have to rely on this trust.

Native binaries

Luckily, on its own, this bug is not enough to successfully execute code on native binaries. By default, libolm is compiled for all supported targets with stack canaries (also called stack protectors or stack cookies), which are magic values unknown to the attacker, placed just before the current function's frame on the stack. This value is checked upon returning from the function -- if its value is changed, the process aborts itself to prevent further damage. This is evident from the Abort message: 'stack corruption detected (-fstack-protector)' message above. Besides canaries, other system-level protections exist to make exploiting bugs such as this harder, such as ASLR.

Therefore, to achieve remote code execution, an attacker would need to find additional vulnerabilities which would allow him to exfiltrate the stack canary and addresses of key memory locations from the system.


With WASM, the analysis is much more complicated due to its very different memory and execution model. In WASM, the unmanaged stack is generally much more vulnerable due to it missing support for stack canaries. This implies a stack buffer overflow can not only overwrite the frame of the function in which the overflow occurred but also all parent frames.

On the other hand, due to typed calls and much stronger control-flow integrity techniques, it's much harder for the attacker to make the code do something that is (maliciously) useful. Notably, return addresses live outside unmanaged memory and are out of reach to the attacker. Because of this, the primary way of influencing code execution is by manipulating call_indirect instructions in such a way as to call.

The analysis of the impact of this bug on the WASM binary is thus left as an exercise to the reader. If you're interested, the 2020 USENIX paper Everything Old is New Again: Binary Security of WebAssembly is a great starting point.

The fix

Once the problems were identified, the patches were rather trivial and the issues were promptly resolved. The first libolm release that includes the fix is 3.2.3 which was released on 2021-05-25.

We reached out to all Matrix clients which were determined to be affected. The Element client versions which first fix the issue are as follows:

  • Element Web/Desktop: v1.7.29
  • Element Android: v1.1.9
  • Element iOS: v1.4.0

For the mobile clients, these versions are already available in their respective application stores at the time of publishing this post. If you haven't already, please upgrade.

Future work

Even though the fuzzing setup is in a much better shape now (or rather will be, since I still have some PRs to merge upstream), there's still a lot that can be done to further improve it.

Right now, there are undoubtedly parts of the codebase that are not fuzzed well. The reasons for this range from the obvious, like some parts of the code simply not being called by any the existing harnesses, to more subtle ones such as the fact that cryptographic operations form a nearly-insurmountable natural barrier for naive fuzzing operations3. Finally, some of the existing harnesses accept additional parameters as command-line arguments, meaning we would have to re-run the same harness with different values of those parameters in order to reach full coverage of the code. This is suboptimal.

So the plan for future work is roughly as follows:

  1. Write missing harnesses to cover more portions of the codebase.
  2. Write starting corpus generators. These should generate believable, valid input for each of the harnesses. For example, for the decryption harness, we should generate a variety of encrypted messages: empty, short, long, text, binary, etc.
  3. Modify the harnesses so that their extra parameters are determined from the fuzzed input. This will allow the fuzzer to vary these itself, which reduces the importance of the human in the loop and makes it harder to forget some combination.
  4. Fuzz for some time until coverage stops increasing. The corpora generated should be saved so that future fuzzing attempts can resume from an earlier point so that this work is not wasted.
  5. Use afl-cov to investigate which parts of the code are not covered well or at all. This should inform us what further changes are needed.
  6. Write intelligent, custom mutators. These will allow the fuzzer to take a valid input and easily produce another valid input instead of only corrupting it with a high probability.
  7. Design harnesses which test for wanted semantic properties instead of only memory errors.

Classic fuzzers famously have a hard time circumventing magic values and checksums, and cryptography is full of these. This is further complicated by the fact that the double ratchet algorithm is very stateful and depends on the two ratchets evolving in lockstep. This means that even if, for example, the decryption harness is supplied with a corpus of valid encrypted messages, the mutations done by the fuzzer would only manage to produce corrupted versions of those messages which will fail to decrypt, but it will ~never manage to produce a different valid encrypted message.

It's very exciting that we're able to do full-time security research on Matrix these days (thanks to Element's funding), and going forwards we'll publish any interesting discoveries for the visibility and education of the whole Matrix community. We'd also like to remind everyone that we run an official Security Disclosure Policy for and we'd welcome other researchers to come join our Hall of Fame! (And hopefully we will get more bounty programmes running in future.)

This Week in Matrix 2021-06-11

11.06.2021 00:00 — This Week in Matrix Ben Parsons

Matrix Live 🎙

Dept of Status of Matrix 🌡️

Room of the week

timokoesters said:

Hi everyone! Did you ever feel lost in the Matrix world? The room directory is big, but it's still hard to find something you like. Or are you a room moderator, but there is not much activity in your room because it doesn't have enough users?

This is why I want to share rooms (or spaces) I find interesting.

This week's room is:

"Share your artwork and drawings and chat about it. You don't have to be good!"

If you want to suggest a room for this section, send an email to

[email protected] or a Matrix message in

Yep, go ahead and email your suggested Matrix room-of-the-week to Timo!

Dept of Spec 📜

kegan said:

MSC3079: Low Bandwidth CS API now has an experimental implementation containing a proxy server and mobile bindings! In addition, there's a blog post explaining how to use this implementation to add low bandwidth support to your servers/clients! This implementation will use about 22% of the bandwidth that the normal CS API would use. Please be aware that low bandwidth Matrix is in its infancy and is subject to change without notice.

anoa said:

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 Updates

Mostly Spaces and E2EE work this week. New spec release is still in the works.

Graph will return in a future edition!

Dept of P2P 👥


Neil Alexander told us:

I have spent quite a bit of time lately working on Pinecone network convergence for P2P Matrix. There's still quite a bit to do in order to call Pinecone "complete", but a network of 50 nodes now bootstraps entirely from cold much more quickly and converges on full end-to-end reachability in roughly 6 seconds. This is a significant improvement to before! Keep an eye out for future P2P Matrix demo builds using these new protocol changes.


This chart also represents interest in Pinecone over time!

Dept of Servers 🏢


Conduit is a Matrix homeserver written in Rust

timokoesters told us:

Hello! The last two weeks I mostly tried to make our database backend swappable so we don't need to rely on the sled database anymore. I was able to try out rocksdb, but there were bugs in the rust bindings which required inefficient and unsafe workarounds.

If you know about other key-value databases that work better with Rust, please comment on the issue:

  • Feature: Swappable database backend

  • Improvement: Don't apply push rules for users of other homeservers

  • Fix: is_direct now works for locally invited users

  • Fix: Deactivated accounts are now actually deactivated (-> performance improvements for appservice puppets)


f0x offered:

This week I implemented the remaining API route for URL previewing. Already has some nicer url preview results like showing images with Twitter posts and proper YouTube previews instead of the cookie wall text :)

With this, synapse-media-proxy should be a drop-in overlay for all Synapse's /_matrix/media routes. I don't really recommend using it in prod yet however, but I have a test instance that could use some responsible disclosure pentesting at, please DM me if you find anything :)
synapse-media-proxy now has a room at



Synapse is a popular homeserver written in Python.

callahad reported:

🚪 Knock, knock... It's Friday!

After over a year of work and over a hundred commits, we're now one major step closer to supporting MSC 2403: Add "Knock" feature, which allows users to request admission to rooms which would otherwise be invite-only. Specifically, last Wednesday we merged (#6739) which is an experimental implementation of the MSC, under an unstable prefix. Knocking is not available in any current room versions — we need to implement room version 7 for that — but the remaining work is minimal¹ compared to what it took to get to this point. 🙂 Major kudos to Sorunome, Anoa, and Clokep for their work on both the spec and implementation.

Otherwise we're looking forward to releasing Synapse 1.36 early next week, and we have some great things in store... but I'll not spoil them today! 🤫

From everyone on the Synapse team, have a great weekend!

¹: Well, on the server-side at least. No clients support knocking, yet...

Homeserver Deployment 📥️


Ananace reported:

This week too comes with an update on the Helm Charts I'm maintaining, with an update of element-web to 1.7.30

Docker-based development environment for Matrix

psrpinto wrote:

Hi folks. Some time ago I asked here about any projects that provided a local Matrix "node" through docker, and it seemed not much existed in that space, so I went ahead and created the following repo:

Docker-based development environment for Matrix. Provides a local sandbox with the following pre-configured services:

  • synapse: the reference homeserver implementation
  • synapse-admin: homeserver admin UI
  • element: a web-based Matrix client

If this is something that would be useful to you, feel free to give it a try and send some feedback, either here or through GitHub issues. Thanks in advance! I hope this is helpful to some of you 🙇

Thanks uhoreg for passing this on! Looks like a really useful way to get a local env running

Dept of Bridges 🌉 IRC bridge work continues

Half-Shot reported:

Hi folks, just a quick update on the bridge situation. We're still rapidly working on the bridge, the milestone highlights for this week are:

  • Nearly 6k Matrix users are now connected to IRC and growing by the minute.

  • We're midway though our #matrix* Freenode to Libera channel/bridge migrations.

  • FOSDEM has been migrated over

  • We're still working through our backlog of migration requests from users, a lot of you phoned in!

We're still continuing to rapidly work on the bridge, with a release expected on Monday 🤞. For any of you who aren't in the know yet, you can start bridging to by simply joining a channel like or by searching the room directory.

I'm hoping we'll be nearing the end of our journey on this bridge, and it will settle into a natural stable state over the coming days! Anyway, thanks everyone for your patience and we hope to see you on Matrix or IRC!

IRC Bridge 0.27.0-rc1 leaps out of the gate

Half-Shot offered:

Hi bridge followers, today we've released 0.27.0-rc1 of the IRC bridge containing a huge number of changes following all the work we've been doing on Notable things to call out in this release are:

  • We've refactored the node-irc library to be typescripty and modern, rather than the quite old JS that it was.

  • SASL support for username/password auth has landed, which hopefully means a smoother login process for many. (We're aware of some issues around setting usernames, watch this space)

  • Allowing you to spin up the bridge with complete control over the alias namespace of a host (e.g. links to #libera).

  • And finally, a privacy feature to block incoming IRC messages when Matrix users are not all joined which is requested by some IRC networks.

Please report bugs as you see them to, and let's all pray this will be a smooth release :)


Fair offered:

matrix-puppeteer-line: A bridge for LINE Messenger based on running LINE's Chrome extension in Puppeteer.

Read receipt improvements are here! They are in temporary branches until they've been tested for stability:

  • The better-receipts-dm branch contains some smarts to prevent Puppeteer from having to "view" a LINE DM chat in order to sync it, which would make the contact you're DMing think you've read their messages when it was really Puppeteer that "saw" them. However, this doesn't work for non-text messages (like images) or messages in group chats.

  • The better-receipts-msc2409 branch (which extends the above branch) uses MSC2409 to detect when you read a bridged message on Matrix, so it can tell Puppeteer to view it on LINE on your behalf. This will let your LINE contacts know when you've read their messages.

After this, only a few read receipt improvements are left to be made:

  • Make Puppeteer check all LINE chats (not just the most recently-used one) to see if messages you sent have been read (in LINE). This will work by cycling through all LINE chats where the final message is posted by you and doesn't have a "Read" marker on it yet.

  • Use MSC2409 to avoid having to view a LINE chat when syncing non-text messages (like images). The idea is to send a placeholder message that will get replaced with the real message (which requires Puppeteer to view the LINE chat) only when you actually view the placeholder.


Issue page:

Dept of Clients 📱


Nheko is a desktop client using Qt, Boost.Asio and C++17. It supports E2EE and intends to be full featured and nice to look at

Nico ( reported:

I've been slowly refactoring the room and communities list to prepare it for spaces. This work is now mostly complete, changing ~4000 lines of code, of which 1500 just got deleted. All of the sidebars are now expandable and collapsible, so you can see the full name of your tags and communities and the lists should also update more dynamically now. Startup also only takes half as long as before on my system and Nheko uses 100MB less memory for my account. Next week I'll probably add spaces to the communities list as well as the room list.

Apart from that LorenDB has been rewriting the member list as well as the invite dialog in Qml and manu has been making progress on the room directory. All of that seems to be coming along nicely and behave much more reasonably than the old versions. There has also been a lot of progress on the Italian and Esperanto translations as well as a few smaller bug fixes and performance improvements.

I hope we will make it to space next week!



Element Clients

Updates from the teams.

Delight, a team aiming to delight users

  • We’re making good progress on the ability to re-order Spaces on Web & Android, expected to land soon!
  • We’re also adding aliases to Space creation, to make it easier to share and onboard other users
  • On iOS, we recently merged a refactor with a new sidebar design which lays the foundations for iOS joining the Spaces beta
  • We’ve also been working on adding pagination to the Space Summary API on Synapse
  • Meanwhile, we’re also shepherding various MSCs through the spec process to improve private Spaces in the very near future


  • 1.7.30 released on Monday
  • On develop
    • Upgraded to React 17
    • First GitHub Actions pipeline for web
  • In flight
    • Continuing to improve application performance
    • Adding dashboard for performance benchmarks
    • Working on Apple silicon desktop builds
    • Working on translation mismatch errors


  • 1.4.1 released on Tuesday on the App Store
  • The new side menu and voice messages are coming.
  • We are setting up Towncrier to avoid merge conflicts on our CHANGES files. Those conflict prevent Github Actions, our CI, from starting
  • We fixed several annoying bugs regarding VoIP and app stability


  • Element Android 1.1.9 has been pushed to production
  • We are working with the design team on the dark and light themes, not forgetting the black theme, to ensure some coherence across the application and also to clean up some legacy code. There were too many shades of grey… We will also do the same work on TextAppearance.


Carl Schwan said:

This week was a busy week for NeoChat. We added tons of cool stuff! We rewrote the setting page to add a bit of organization in the settings. This also pushed us to add new appearance options. You can now add a blur effect as background, change the color scheme of NeoChat and switch between bubbles and a more compact layout as you wish.



Another thing we worked on was spellchecking. NeoChat will now add a small red underline under misspelled words and will suggest corrections. This is using the Sonnet frameworks and will integrates perfectly with your personal dictionary from your other KDE apps.


Finally something we added two weeks ago but forgot to mention, we added a quick room switcher using the Ctrl + K shortcut.


Dept of SDKs and Frameworks 🧰


kitsune reported:

Another small release - libQuotient 0.6.7 is out, fixing an issue causing NeoChat to not add rooms to the roomlist after joining. Thanks to Carl Schwan for hunting the problem down!

Tobias Fella added:

Apparently my work-in-progress end-to-end-encryption implementation for libQuotient was bad enough to cause performance problems on my homeserver (Sorry about that!). This should be fixed now 🙂

Dept of Interesting Projects 🛰️


MTRNord announced:


  • Server now uses warp instead of actix-web

  • /relations request instead of 10s now takes 2s overall

  • Added a /servers api endpoint which returns all servers based on the room_ids. (It splits of the server_name from room_ids and puts them into an array)

Bug Fixes

  • Aliases with emoji will now get recognized.

Thanks to jo , Nico , joepie91 🏳️‍🌈 and poljar for helping to archive these improvements and hinting where improvements were possible to be made :)

Dept of Guides 🧭

A guide for creating simple Matrix bots with Python and Simple-Matrix-Bot-Lib

krazykirby99999 told us:

Simple-Matrix-Bot-Lib allows anyone who needs a bot in a Matrix Room to do so without having to spend unnecessary time learning a complex framework!

Dept of Grants 💰️

Code Lutin grant program

numéro6 told us:

If you live in France (or eurozone) and your Matrix-related project need some funds, you may candidate to the 2021 #MécénatCodeLutin grant program for FLOSS by Code Lutin. Candidates may fill the dedicated form before july 8th.

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!

Low Bandwidth Matrix: An implementation guide

10.06.2021 17:08 — Tutorials Kegan Dougal
Last update: 10.06.2021 11:28

Disclaimer: Low bandwidth Matrix is experimental, not yet standardised, and subject to change without notice.

This guide is for Matrix developers who want to support MSC3079: Low Bandwidth CS API in their clients/servers. Please read the experimental MSC if you want to learn more about what is happening at a protocol level. If you want a high level overview of low bandwidth Matrix and why you should care, watch the 12 minute demo on Matrix Live.

Matrix currently uses HTTP APIs with JSON data to communicate from the client to the server. This is widely supported but is not very bandwidth efficient. This means that the protocol is slower, more costly and less able to be used on low bandwidth links (e.g 2G networks) which are common in certain parts of the world. MSC3079 defines a low bandwidth protocol using CoAP and CBOR instead of HTTP and JSON respectively. In the future homeservers will natively support some form of low bandwidth protocol. However, at present, no homeserver natively supports MSC3079. Therefore, this guide will set up a low bandwidth proxy server which can be put in front of any Matrix homeserver (Synapse, Dendrite, Conduit, etc) to make it MSC3079-compatible. This guide will also configure an Android device to speak MSC3079.

Low bandwidth Matrix currently does not support web browsers due to their inability to send UDP traffic. You do not need to be running a homeserver to follow this tutorial.

Setting up a low bandwidth proxy for your homeserver


  • Go 1.13+
  • openssl to generate a self-signed DTLS certificate, or an existing certificate you want to use.
  • Linux or Mac user


  • Clone the repo: git clone
  • Build the low bandwidth proxy: go build ./cmd/proxy
  • Generate a elliptic curve DTLS key/certificate: (we use curve keys as they are smaller than RSA keys, but both work.)
    openssl ecparam -name prime256v1 -genkey -noout -out private-key.pem
    openssl req -new -x509 -key private-key.pem -out cert.pem -days 365
    # you now have cert.pem and private-key.pem
  • Run it pointing at
    ./proxy -local '' \
    --tls-cert cert.pem --tls-key private-key.pem \
    --advertise "" \
    --dtls-bind-addr :8008
  • You should see something like this:
    INFO[0000] Listening on :8008/tcp to reverse proxy from to - HTTPS enabled: false 
    INFO[0000] Listening for DTLS on :8008 - ACK piggyback period: 5s

Mac users: If you are having trouble generating EC certificates, make sure you are using OpenSSL and not LibreSSL which comes by default: openssl version. To use OpenSSL, brew install openssl which then dumps the binary to /usr/local/opt/openssl/bin/openssl.

To test it is working correctly:

# build command line tools we can use to act as a low bandwidth client
go build ./cmd/jc
go build ./cmd/coap

# do a CoAP GET request to via the proxy
./coap -X GET -k 'http://localhost:8008/_matrix/client/versions' | ./jc -c2j '-'


If this doesn't work:

  • Check the proxy logs for errors (e.g bad hostname)
  • Try adding -v to ./coap (e.g bad method or path)
  • Run the proxy with SSLKEYLOGFILE=ssl.log and inspect the decrypted traffic using Wireshark.

Otherwise, congratulations! You now have a low bandwidth proxy! You can connect to your proxy just like you would to or any other homeserver.

Security considerations

  • The proxy acts as a man in the middle and can read all non-E2EE traffic, including login credentials. DO NOT USE UNTRUSTED LOW BANDWIDTH PROXY SERVERS. Only use proxy servers run by yourself or the homeserver admins.

Further reading

Setting up a custom Element Android

We'll add low bandwidth matrix to Element Android and iOS by default once it's standardised - but while things are still experimental, here's a guide for how to build Element Android to do it yourself if you feel the urge. This can be used as inspiration for other Matrix clients too.


  • Android Studio


  • Clone the repo: git clone
  • Checkout kegan/lb: git checkout kegan/lb. This branch replaces all HTTP traffic going to /_matrix/client/* with LB traffic. /_matrix/media traffic is left untouched. This branch also disables TLS checks entirely so self-signed certificates will work.
  • Clone the low bandwidth repo if you haven't already: git clone
  • In the low bandwidth repo, build the mobile bindings:
    go get
    cd mobile
    # if gomobile isn't on your path, then ~/go/bin/gomobile
    gomobile bind -target=android
  • Copy the output files to a directory in the Element Android repo which Gradle will pick up:
    mkdir $PATH_TO_ELEMENT_ANDROID_REPO/matrix-sdk-android/libs
    cp mobile-sources.jar $PATH_TO_ELEMENT_ANDROID_REPO/matrix-sdk-android/libs
    cp mobile.aar $PATH_TO_ELEMENT_ANDROID_REPO/matrix-sdk-android/libs
  • Open the project in Android Studio.
  • Build and run on a device/emulator.
  • Configure the proxy's --advertise address. If you are running on a local device, restart the proxy with an --advertise of your machines LAN IP e.g instead of If you are running on an emulator, restart the proxy with an --advertise of the host IP: The URL scheme should be https not http, else image loading won't work as Element Android won't download media over http.
  • Login to your account via the proxy with the --advertise address as the HS URL e.g or The port is important.

To verify it is running via low bandwidth:

  • Install Wireshark.
  • Restart the proxy with the environment variable SSLKEYLOGFILE=ssl.log.
  • Run tcpdump on the right interface e.g: sudo tcpdump -i en0 -s 0 -v port 8008 -w lb.pcap
  • Force stop the android app to forcibly close any existing DTLS connections.
  • Re-open the app.
  • Open lb.pcap in Wireshark and set ssl.log as the Pre-Master Secret log filename via Preferences -> Protocols -> TLS -> Pre-Master Secret log filename.
  • Check there is DTLS/CoAP traffic.


To send a single 'Hello World' message to /room/$room_id/send/$txn_id and receive the response, including connection setup:

ProtocolNum packetsTotal bytes


  • CoAP OBSERVE is not enabled by default. This extension allows the server to push data to the client so the client doesn't need to long-poll. It is not yet enabled because of the risk of state synchronisation issues between the proxy and the client. If the proxy gets restarted, the client will not receive sync updates until it refreshes its subscription, which happens infrequently. During this time the client is not aware that anything is wrong.
  • CoAP uses Blockwise Transfer to download large responses. Each block must be ACKed before the next block can be sent. This is less efficient than TCP which has a Receive Window which allows multiple in-flight packets at once. This means CoAP is worse at downloading large responses, requiring more round trips to completely send the data.
  • The current version of /sync sends back much more data than is strictly necessary. This means the initial sync can be slower than expected. On a low kbps link this can flood the network with so much data that the sync stream begins to fall behind. Future work will look to optimise the sync API.
  • The proxy currently doesn't implement the low bandwidth response in /versions.

This Week in Matrix 2021-06-04

04.06.2021 20:37 — This Week in Matrix Ben Parsons
Last update: 04.06.2021 19:10

Matrix Live 🎙

Dept of Status of Matrix 🌡️

Wired UK feature article

Wired UK have published a feature on Matrix in their print edition this month. We'll be sure to link to it when it's made available online!

Wired Article

German-universities poll

jfkimmes shared:

I just learned that in a poll of 89 universities in Germany, Matrix ranked third place in the chat category already.

The source is in only available in German, unfortunately:

However, the conclusion list (first table) may be understandable from context. It lists the top three solutions per category with their respective number of universities using it.

Oleg clarified:

The evaluation was "which solution are you using".

Florian added:

The Instant Messaging part starts at slide 15, the first chart on that slide is "which solution do you use", the second is "How content are you with the solution?", with Matrix having the best average of all solutions, namely ~8.8/10.

also JCG:

What's also noteworthy: Those using matrix are the happiest with the solution


Dept of Spec 📜


anoa offered:

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 with proposed Final Comment Period:

  • No MSCs entered proposed FCP state this week.

MSCs in Final Comment Period:

  • No MSCs are in FCP.

Merged MSCs:

  • No MSCs were merged this week.

Spec Updates

This week the Spec Core Team has been reviewing various Spaces MSCs, most recently MSC3230 (Space ordering). We're also hoping to square away the aggregations MSCs (message editing, reactions, etc) once and for all, though this will likely take a concerted effort from a few members to pull off.

Finally MSC3231 is a (currently draft status) MSC from Callum, one of's GSoC students this year! His project aims to allow native token-based registration to homeservers (the idea is so that you can generate a few tokens from your registration-disabled homeserver and hand them out to a few trusted friends and family members).

And finally, work still continues on finishing up the technical portions of the new release process for the spec. As mentioned last week, we've attempted to split the work up over multiple people in order to get it done quicker. Slowly but surely...


Dept of Servers 🏢


Synapse is a popular homeserver written in Python.

callahad said:

Hello from the Synapse team! A short update for a short workweek (thanks, bank holidays!):

  • Synapse 1.35 was released this week! The Spaces flag is on by default, a bunch of bugs were fixed, and we've landed many of the prerequisites to eliminating RAM spikes on room joins.

  • 📚 We have new docs! 📚 Anoa converted our docs to build with mdbook (#10086), and you can now browse them at! Check it out and let us know what you think. (Note: Not all of the pages have been converted from reStructuredText to Markdown yet, so some might render a bit strangely, but the structure is there!)

Catch you next Friday! 👋



f0x announced:

Another round of updates on my smart caching media proxy. After refactoring a lot (as always), I implemented thumbnailing! Now the only big feature left to add is url previewing. I also have a test deployment configured on now, so you can try fetching a bit of remote media through there, or view this submissions screenshot


Got started implementing a Prometeus /metrics endpoint, with a rudimentary Grafana dashboard for my test installation.

comparison with matrix-media-repo

While they both implement Matrix' media endpoints, they serve rather different niches, where matrix-media-repo fully decouples the media repo aspect, my proxy cooperates with Synapse's filesystem and database, to speed up operation while ultimately making it a seamless drop-in and removal process.

also :P


Homeserver Deployment 📥️


Ananace offered:

And another weekly installment of Kubernetes Helm Chart (and deprecated Docker image) updates, tracking the Synapse releases this week (1.35.0/1).

Dept of Bridges 🌉

Heisenbridge demo video

hifi shared this great demonstation video of Heisenbridge:

Half-Shot hit us late with a pair of updates:

Security release for the matrix-appservice-irc and matrix-appservice-bridge library

Hello. This week we've released an update to the library containing a security fix for room upgrade handling. The security report will come later, but for now we advise anyone using the room upgrade handler feature to upgrade to 2.6.1. By the same token, we would also advise all IRC bridge admins to update their bridge to 0.26.1.

The bridge is still ongoing

Howdy folks. As you've likely seen over the last few days, we're still hard at work getting the final pegs in place for the bridge. As usual, you can start using the bridge now while it's in beta by going to #<foo>, but we're hoping to have the thing stable by next week. Catch us in for the juicy gossip about it.


Fair reported:

matrix-puppeteer-line: A bridge for LINE Messenger based on running LINE's Chrome extension in Puppeteer.

  • Send a bridge notice when getting unexpectedly logged out of LINE, to warn you to log in again.
  • Improve resiliency of LINE user avatar syncing.
  • Properly support syncing LINE rooms with participants who aren't in your LINE friends list (This was harder than it sounds...!)

These changes (and ones before it) will be merged to master once I reorganize some messy commits.

The next big task is still to fix outbound read receipts (i.e. to make it so that the bridge syncing a message doesn't make your > LINE contacts think you actually read that message). Once that is done, I'll consider the bridge to be in beta.

Discussion: Issue page:

Dept of Clients 📱

Thunderbird Matrix support

freaktechnik announced:

Thunderbird now has Matrix support based on matrix-js-sdk enabled in the Nightly builds.

The star feature is probably that we support multiple Matrix accounts in the same client. Right now all your unencrypted rooms with text messages should work fine. While we think we won't destroy your account's state, it's still recommended to use a testing account with it. During account setup, it will ask you for a password, even if the homeserver supports SSO. If you intend to log in through SSO, just leave the password field blank.

We're not quite at the point where we support all the things you love about chatting with Matrix. Many of the missing features and polish to make communication successful are tracked in this meta bug. The goal for that milestone is to enable Matrix in our Beta builds.

You can get a Thunderbird Nightly build at the bottom of by switching from "Beta Channel" to "Nightly Channel". If you run into bugs with the Matrix integration, please report them through this form. When filing a bug, please include debug logs. You can copy the debug logs for the account by going to the "Show Accounts" dialog, right clicking the account and selecting "Copy Debug Log". Note that the debug log may contain information from any of your conversations, so you might want to check the contents before posting it anywhere.

Also, check out Matrix Live!


Carl Schwan announced:

NeoChat 1.2, our third major release, was released this week bringing many improvements to the timeline and text input component. If you missed it, you can read the announcement here: and we even have a nice release video :)

Other than that, we started working on an integration with KDE web shortcuts functionality to quickly search selected text on the web:



Nico ( told us:

Callum, our GSoC student, after spending some time on Synapse, had now his first go at Nheko's codebase. He implemented, that you can now just enter the server name on registration instead of the full URL. This means entering or works now nicely, since those servers are actually hosted at a different URL. He's now working on the Token Registration MSC, which he will implement in Synapse and Nheko, so exciting times ahead!

We also had a small contribution from pcworld, who fixed that if you only viewed the room list in the narrow layout, you would not get notifications for the last selected room.

I'll leave you with some words, that you may have heard a few times already: "Watch this space for next weeks update!"


Alexandre Franke reported:

A dozen merge requests have been integrated in our fractal-next branch since last week.

Amongst the more trivial changes, Julian made sure rooms are added to the sidebar in batch (!737) to improve performances, added in-app notifications for invite errors (!760), added a menu entry to leave rooms (!769), and implemented display of user and room avatars (!770). We also gained a right-click-menu entry to display event sources thanks to Kévin (!766).

Element Clients

Updates provided by the teams.

Delight team

  • We’re continuing progress on implementing Blurhash on Web & Android to improve the image loading experience, especially on low bandwidth
  • On Spaces, we’ve started working on the ability to drag and drop to re-order Spaces, along with improving adding aliases to public Spaces


  • 1.7.30 RC on staging
    • Improved layout performance in the timeline and room list
    • Refined the message action bar UI
  • Continuing to improve application performance
    • Recent focus on minimising browser layout work when things change
    • Reducing DOM size
  • Working on Apple silicon desktop builds


  • 1.4.0 is available on the public TestFlight. We expect to make it available on the App Store on Monday. It has:
    • Performance improvements
    • Crash fixes
    • New languages: Esperanto, Portuguese (Brazil), Kabyle, Norwegian, Swedish, Japanese and Welsh.
    • There are some API breaks in MatrixSDK due to those performance improvements.
    • We have now a MXLog module with log levels! It is now possible to disable all logs from MatrixSDK
  • We continued to work on performance and stability and will continue to for the coming sprint period:


  • 1.1.8 has been released to production, and 1.1.9 has been released to beta on the PlayStore
  • We are currently working with the design team on the light and dark theme of the application, especially colors and text appearance. Lots of cleanup to do...


A minimal Matrix chat client, focused on performance, offline functionality, and broad browser support.

Bruno announced:

Released Hydrogen 0.1.56 this week, with redactions. In the meantime, I've been making good progress on reactions, which should hopefully get released early next week. Midhun has made good progress on the right panel, ironing out the last bugs.

Here's a sneak preview of reactions (with slow network to show off the local echo animation):



tusooa reported on kazv:

kazv is a matrix client based on libkazv. Talk to us on


I guess it's a long time from our last twim. Here's what is going on in that time:

  • We used fluent for translations.
  • We supported read and save client state.
  • A work-in-progress, but we are displaying some common event types; there are even chat bubbles (>w<) Check out a screenshot below: (yes, and we got a new logo)


Dept of Events and Talks 🗣️

Matrix @ FrOSCon this year

Oleg said:

On August 21-22 the annual Free and Open Source Conference (short FrOSCon) will take place. Usually the conference takes place in a German University of applied Sciences Bonn Rhine Sieg. This year it will be virtual. On the positive side - we don't need to travel.

As German Matrix community grows this is a great opportunity to meet each other and hack together.

Matrix Dev Room

We are planing to do a virtual Dev Room this year. The idea is to exchange on the latest Matrix development and projects, get to know each other and drink <your_favorite_beverage> (virtually) together. 😉

To make it happen we need your help!

Dev Room is living from talks and workshops - this is your chance to present your Matrix project or to do a workshop!

Language: preferably German, but English is also ok

Submission is until 2021-06-11, but please give us feedback ASAP so we can create a plan now.

If it's your first talk or workshop some free of charge coaching is included. 😉

Also help in organizing the Dev Room (moderation, timekeeping) is needed.

Matrix Open Source booth

It was a great place to chit-chat and to get your in-depth answers regarding Matrix at FOSDEM this year. 👍️

We also planing to have a virtual booth at FrOSCon.

We need your support in answering questions about Matrix or just to have a good time.

Get in touch

If you want to take part please contact (or [email protected]) ASAP to add you to the Dev Room participants list.

BTW: we also have a room

Dept of Interesting Projects 🛰️


cvwright reported:

  • Set up a new (virtual) EU homeserver in Frankfurt, so European folks can join the beta starting next week

  • Use StoreKit to detect when a user is in Europe and should therefore use the EU homeserver, both for GDPR and to minimize latency

  • Made some progress toward supporting messages

  • Experimented with using the new iOS photo picker to better protect users' privacy Homepage: Source code:

You can also support circles on Kickstarter.

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.35.0 released

01.06.2021 00:00 — Releases Dan Callahan

Synapse 1.35.0 is out! This release focused on improving internals as we drive toward better memory performance during room joins, but more on that below.

Update: Synapse 1.35.1 was published on Thursday, June 3rd. It resolves a bug (#10109) which mistakenly listed invite-only rooms in the Spaces summary.

We'd also like to call the attention of client developers to a deprecation: The unstable prefixes used during development of MSC2858: Multiple SSO Identity Providers will be removed from Synapse 1.38, due out in August. Please ensure your client supports the stable identifiers for this feature.

Spaces: On by Default

Following the successful release of Synapse 1.34, the experimental Spaces flag is now enabled by default. If you had manually enabled the experimental_features: { spaces_enabled: true } flag in your homeserver configuration, you may now remove it.

Bug Squashing

This release of Synapse fixes an issue which could cause federated room joins to fail when the join response exceeded a size limit which was too low (#10082). We've also improved what Synapse logs when it drops a connection in similar circumstances (#10091), which should aid diagnosis if a similar issue were to arise in the future.

GitHub user thermaq contributed a fix (#10014) for a bug which could cause user presence state to become stale.

Lastly our OpenTracing support now allows for profiling end-to-end performance on a per-user basis (#9978).

An Update on Room Joins

We've been hammering away at shrinking Synapse's memory footprint when joining large / complex rooms, and while we're not there yet, the end is in sight! In particular, this release includes many internal refactorings, including using ijson to parse the JSON response to /send_join (#9958), clearing the way for substantial improvements.

Memory usage still spikes because we're effectively doing the same work with a different library, but ijson's design allows for iterative parsing. This will pay dividends once we modify the code downstream of /send_join to take advantage of it.

Concretely, Erik Johnston has an experimental branch of Synapse which completely eliminates the memory spike:

Memory usage graph for Synapse 1.33, 1.35, and an experimental branch

The remaining work is centered on splitting that branch into self-contained, reviewable pull requests, like a rewrite of the Synapse Keyring class (#10035). After that's merged, we'll need to make one further change to properly batch up work, at which point we should attain the efficiency gains from Erik's experiment.

Everything Else

GitHub user savyajha contributed a security hardened systemd unit file which effectively sandboxes Synapse (#9803). While not enabled by default, we'd encourage security conscious users to review the example file and associated documentation.

Please see the Release Notes for a complete list of changes in this release.

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 dklimpel, jerinjtitus, junquera, lonyeon, savyajha, and thermaq.