Brendan Abolivier

29 posts tagged with "Brendan Abolivier" (See all Author)

Security release: Synapse 1.61.1

28.06.2022 16:19 — Releases Brendan Abolivier

Hey everyone!

Today we're exceptionally releasing Synapse 1.61.1, which comes as a security release. Server administrators are encouraged to update as soon as possible.

This release fixes a vulnerability with Synapse's URL preview feature. URL previews of some web pages can lead to unbounded recursion, causing the request to either fail, or in some cases crash the running Synapse process.

Homeservers with the url_preview_enabled configuration option set to false (the default value) are unaffected. Instances with the enable_media_repo configuration option set to false are also unaffected, as this also disables the URL preview functionality.

Server administrators who are unable to update Synapse should disable URL previews by setting url_preview_enabled: false in their configuration file. They can also delegate URL preview to a separate, dedicated worker to ensure the process crashing does not impact other functionality of Synapse.

Please see this security advisory for more information.

Synapse 1.61 released

17.06.2022 11:48 — Releases Brendan Abolivier

Hey everyone! Guess what? Synapse 1.61 is out! Let's have a look at it.

Farewell, groups

If you are new to Matrix, you might have not heard of the feature referred to as "groups" or "communities" (depending on the context). This feature allowed grouping rooms and users to better represent a community, one of which being which used to represent the Matrix community. This may sound similar to Matrix Spaces, and it would make sense since Spaces are meant to be a more powerful replacement for groups.

In Synapse 1.56, support for groups was deprecated, with a plan to fully remove it in a later release of Synapse. This has now been done as of Synapse 1.61, and most of the code supporting this feature has now been removed.

Note that this means that administrators of homeservers using workers can remove endpoints related to groups from their reverse proxy configuration. See the upgrade notes for more information.

Media retention

A common issue we see homeserver administrators struggle with is managing the disk space used by Synapse. A non-negligible part of that disk space usage is dedicated to storing files uploaded by Matrix users, both local and remote.

Up until now Synapse would only provide administrators with limited, manual ways to manage the media store of their homeserver, via the admin API.

As of this release, Synapse now allows administrators to define retention lifetimes for local and remote media. This allows media that hasn't been accessed in a long time to be automatically deleted, therefore freeing up disk space. Server administrators wishing to control media retention more finely can also define different policies for remote and local media.

This feature can be enabled by configuring the media_retention setting, see the configuration guide for more information.

Everything else

This release of Synapse introduces a change in the return value of the check_event_for_spam spam checker module callback, in order to allow modules more flexibility in communicating to users why their messages are rejected. This is part of ongoing improvement works around spam checker callbacks, watch this space next time for more information!

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

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

This Week in Matrix 2022-06-17

17.06.2022 00:00 — This Week in Matrix Brendan Abolivier

Hey everyone! Thib is away today so I'm taking over TWIM for this week (but don't worry, he should be back next week!)

Let's see what the Matrix community has shared with us this week.

Matrix Live 🎙

In this week's Matrix Live, Thib talks to Ivan from the Matrix Rust SDK development team to ask him about the SDK's bindings for Node.JS and WASM.

Dept of GSoC 🎓️

Marco Melorio says

Hi there! I'm Marco Melorio and I'm participating in this year's Google Summer of Code, under the GNOME Foundation. I'm working on Fractal, the GNOME matrix client, with the help of my mentor Julian Sparber. More specifically I'm working on implementing a media history viewer to the app.

To follow my progress on the project you can check out my blog here. I've already published a small introduction post about me and a first update post which includes a mockup and milestones about the project.

Dept of Servers 🏢

Synapse (website)

Synapse is a Matrix homeserver implementation developed by the core team

Brendan says

This week the team released Synapse 1.61, which main new feature is media retention. That's right, you can now control how long Synapse keeps media files around, which should help server admins manage Synapse's disk space usage more efficiently. On a different note, this release of Synapse removes support for groups/communities (which was deprecated back in Synapse 1.56), as it has now been replaced by Spaces. Farewell groups, you have served your users well.

See the full Synapse 1.61 release announcement on the blog here:

Aside from this, the team is as always hard at work on making Synapse better and more efficient.

Dept of Clients 📱

Quadrix (website)

JFA says

New version of Quadrix (1.0.6) available on desktops and mobiles. Mainly bug fixes, plus the addition of a button to deactivate the account on the server (this apparently will be soon mandatory for iOS and MacOS messaging apps). The new desktop version should offer better support for Wayland (tested on Fedora 36, Ubuntu 22.04 and Mobian/Phosh). Repo at, project room at :-)

Nheko (website)

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

Nico announces

Since I skipped the last update, this one is a bit longer :3

First of all there have been lots and lots of updates to the translations! Finnish is now at 100% thanks to the tireless work of Aminda and Lurkki.

Nheko now also shows a nice badge on Unity compatible desktops (like KDE) for unread messages (although that doesn't work properly for multiple profiles being open at the same time due to limitations in that desktop protocol. Thank you d42 for contributing this, may you role a natural 42 every dice throw!

Syldra fixed up the paste behaviour (which didn't properly tie into undo in some edge cases), cleaned up how we find some of our dependencies and made cusor movement more consistent across systems.

Finally we fixed our glare resolution when verifying other sessions, which will be especially noticeable when verifying Cinny, since that responds to verification requests in a different way than I tested before! This should get rid of a whole range of verification issues people might have experienced. As part of our stabilization for the next release, we also fixed a crash on logout because I fatfingered and deleted a return statement, we now send an Element Android compatible height attribute on emotes, properly compile when the C++ version is set to 20, we once again support the current version of the hidden read receipts MSC (so that others can't tell what you read), edits now properly update in replies again, you can close the image overlay again by clicking outside, cancelled uploads properly get removed again, logging out and back in now doesn't mess up your configuration anymore and pinned messages now properly refresh once the events are loaded.

Phew, that was a mouthful. And we are not even done yet!

I spent some time on making Nheko compilation a bit faster again as well as improve startup speed. This might order your room list a bit weirdly for a few days after updating, but should normalize when receiving a few messages in some rooms. With this we now don't need to load the last message in all rooms on startup. This makes Nheko startup now only take 7 seconds on my old laptop (when not doing something CPU heavy at the same time). The remaining startup time is 40% building up the font database and 40% loading the powerlevels for each room. So we do have the chance to speedup startup by probably another 60%. It is unlikely that is necessary though.

When I discovered Matrix, Element was still called Riot. At the time some of the big design changes started happening to make it the Element you know today. One of the sideeffects was that the roomlist was consistently taking up 20% of my CPU on my Laptop, which I used at the time (and am forced to use now again, since I broke my newer laptop). It also used a lot more RAM than it does today. So for that reason I started shopping around for what other clients there are and I found Nheko. Clearly because it isn't a webclient, it had to be faster and use less RAM. Well, it did maybe a bit, but frankly the difference wasn't that much. Especially since at the time it loaded and rendered ALL your messages on startup (kinda). It never removed messages from memory, so it would just continuously render more and more parts of your timeline, which clearly increased RAM usage. It did however never resort the full roomlist, which made it not use a lot of CPU.

Since I didn't know any web development at the time, but I knew some C++, I started contributing to Nheko. At some point I made the roomlist constantly resort, which used quite some amount of CPU, but I quickly fixed that. At the time the most noticeable difference was that my fans didn't spin when using Nheko, but Element did (because of the roomlist sorting, iirc). RAM usage was pretty bad though. So that was one of the next projects, removing all events from RAM and only pulling them from the database as needed. While this means some additional load when switching rooms, it did decrease RAM requirements by quite a bit. Some new features made us still require loading data for every room from the database on startup, which causes quite some noticeable startup delay. The latest changes however got rid of most of that. We now don't need to load the messages from the database anymore. The only thing we still load is a small info object with roomname, notification and member count as well as the power levels of the room.

Since I recently broke my new and fast laptop, I decided to checkout how things changed on my old and slow laptop. Nowadays I am not in 15 rooms anymore, but I am in 900 rooms, but Matrix, servers as well as clients, has also gotten a lot more performant. So in the end I decided to do a little benchmark of where things stand. DISCLAIMER: This is completely unscientific and unfair, so please take those numbers with a grain of salt. Almost no one runs such a slow laptop as I do, so likely your measurements will completely different. Even more, I was video recording the benchmark, which makes both clients a lot slower. Nonetheless it does somewhat mirror my personal experience.

I came to the conclusion that with 900 rooms, Nheko takes about 10-20 seconds to load and be ready for use on my system, while Element takes about 3 to 4 minutes. So basically Element handles 60 times as many rooms about 2x slower than it did back in the day, while Nheko got a bit faster or about the same speed on the same hardware (but still 60x as many rooms). I've attached a sped up video to this post, so that you can compare it for yourself. But since a lot of people ask, I guess the reason is that I wanted to see how fast you can make a Matrix client. I think I somewhat achieved that in the startup time department, but switching rooms still has a loooooong way to go. Also it is just fun to implement whatever you want in a client, since you are the maintainer and none can tell you how bad of an idea it is. That's probably the reason a lot of people start their own clients? (Although I didn't start Nheko, I just wrote too much code and people didn't want to review it anymore.)

That's it, I hope your eyes didn't glaze over with me babbling on about things. See you next time! :3

This Week in Matrix 2022-05-27

27.05.2022 00:00 — This Week in Matrix Brendan Abolivier

Hey everyone! Thib is out today, so I'll be exceptionally hosting TWIM in his stead this week. Let's have a look at what's been going on in Matrix-land!

Open Tech Will Save Us #16 🎙

The 16th edition of our virtual meetup Open Tech Will Save Us happened this week! This edition featured a few very interesting projects:

  • Quentin and Maximilien from Deuxfleurs are creating Garage, a robust and distributed storage backend that can run on old computers. Who can use it? Why? And when should I not use it? Let's find out!
  • Nathan from the Guardian Project is working with wind, butter, and rasperries to provide applications and messaging to people in low-connectivity areas. A fascinating dive off the grid.

Dept of Status of Matrix 🌡️

andybalaam says

Matrix's Outreachy intern for this summer has been chosen! Usman is starting in early June, and will be working on experiments with Starring Messages! He will be blogging every two weeks, so look out for more updates.

Dept of Spec 📜

Andrew Morgan (anoa) reports

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

MSC Status

New MSCs:

MSCs in Final Comment Period:

Merged MSCs:

  • No MSCs were merged this week.

Spec Updates

The upcoming release of Matrix v1.3 is still in the works, but near! Expect a solid release date to be announced next week.

Random MSC of the Week

The random MSC of the week is... MSC2872: Move the widget title to the top level of the definition!

A bite-size MSC which aims to clean up the definition of a widget state event... by moving the "title" field to the root of the state event, alongside the existing "name" field.

This MSC needs someone to write an implementation in at least one homeserver and client to move forwards. Perhaps that someone could be you?

Dept of Servers 🏢

Synapse (website)

Synapse is a Matrix homeserver implementation developed by the core team

squah reports

This week we cut two release candidates for Synapse v1.60, which include:

Meanwhile work continues on fast room joins and testing Synapse with workers on Complement. We'd like to remind readers that the fast room joins feature is highly experimental right now and we do not recommend enabling it on production homeservers just yet.

Synapse admin scripts (website)

Pierre announces

Morning, maybe it's useful for someone else, I just published my admin scripts for synapse. It's still WiP but it make some basic stuff that I needed in my organisation :

  • System notify users (all users/users from a list, specific user)
  • delete sessions/devices not seen for X days
  • purge the remote media cache
  • select rooms with various criteria (external/local/empty/created by/encrypted/cleartext)
  • purge history of theses rooms
  • shutdown rooms

It's my first python project, so the code may not structured as it should, I'm still learning, and it's early alpha :)

Dendrite (website)

Second generation Matrix homeserver

neilalexander says

This week we released Dendrite 0.8.6 which contains a number of fixes and tweaks:

  • Room versions 8 and 9 are now marked as stable
  • Dendrite can now assist remote users to join restricted rooms via /make_join and /send_join
  • The sync API no longer returns immediately on /sync requests unnecessarily if it can be avoided
  • A race condition has been fixed in the sync API when updating presence via /sync
  • A race condition has been fixed sending E2EE keys to remote servers over federation when joining rooms
  • The trusted_private_chat preset should now grant power level 100 to all participant users, which should improve the user experience of direct messages
  • Invited users are now authed correctly in restricted rooms
  • The join_authorised_by_users_server key is now correctly stripped in restricted rooms when updating the membership event
  • Appservices should now receive invite events correctly
  • Device list updates should no longer contain optional fields with null values
  • The /deactivate endpoint has been fixed to no longer confuse Element with incorrect completed flows

As always, please feel free to join us in the room for more discussion!

Dept of Clients 📱

Nheko (website)

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

Nico announces

We added a way to edit permissions in Nheko now. It is an unconventional drag and drop dialog, where you drag users and permissions between different roles. We are hoping that this will make powerlevels easier to understand. Be careful when trying it, the wrong powerlevels might make your room unusable. Now... the bad part about that is, that powerlevels add around 50-100 new strings to translate... Help is appreciated! <3

Nheko now also supports fallback keys, which should make E2EE more reliable after long periods of being offline and you can send images by pressing enter again. The privacy screen is also now fixed for separate room windows and our flatpak supports more image formats.

Element Web/Desktop (website)

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

Danielle announces

  • On Element Web this week we’ve smashed some bugs including those around Threads.
  • Threads work continues as we’re aiming to improve the notifications and read receipts to improve the experience.
  • Continuing to make improvements to our automated tests.
  • The team is driving to complete the work needed to move our new search experience out of Beta. We think this new search is easier to use and helps folks to find what they’re looking for faster.
  • We’re also making improvements specifically for new users, this will include a new home screen, watch out for those!

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

  • Video rooms; We’re ironing out some of the details to polish the experience

Element iOS (website)

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

Ștefan reports

  • This week we’ve fixed a crash, and a few bugs; specifically the bug where some rooms were missing from the room list.
  • On the iOS team generally we’re working towards a integration for better crash reporting to help us with this in the future.
  • Live location sharing and other features are making great progress.
  • Our new first time user experience will be ready for feedback soon!
  • ElementX has been refactored to adopt Swift’s new structured concurrency.

Element Android (website)

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

adam says

  • This week we added emoji14 support so if you want to hide 🫣 , salute 🫡 , or melt 🫠 for your friends, you’ll soon be able to! 🫶 (for Android 12 and above, or devices that support emoji14)
  • We’re getting ever nearer to a new sign up flow for new users. Our flow today can be confusing and complex, especially when all you want to do is chat with friends. We’ve been working on simplifying the flow and we’ll announce a community testing session very soon!
  • Also new this week, we’ve opened up a new layout of the app to a small selection of folks. These 15 people will trial the new layout for us, providing feedback along the way. We’ll be opening it up to more feedback soon.

Element (website)

Everything related to Element but not strictly bound to a client

Danielle reports

Hello and happy Friday!


  • Threads are still in progress as we continue to make progress on the notifications and sort/ordering work that remains.
  • In order for notifications to work better, we need read receipts to be updated. We’ve got several MSCs ongoing, along with a few Proof of Concepts (PoCs) to move us forward.
    • MSC3771: Read receipts for threads
    • MSC3772: Push rule for mutually related events
    • MSC3773: Notifications for threads
  • With that we’ve also updated some layouts and completed some bug fixes, on all platforms.

Community testing

Dept of SDKs and Frameworks 🧰

Trixnity (website)

Multiplatform Kotlin SDK for Matrix

Benedict says

Trixnity 2.1.0 has been released. It includes support for Server-Server-API endpoints (client and server) and fetching missing TimelineEvents in client. The latter is used for fragmented timelines: If you want to show a timeline starting from any EventId and RoomId (e. g. from unread marker), Trixnity will try to fetch missing TimelineEvents from server. If you reach TimelineEvents, that are already saved in the local database, the timeline fragments are merged magically 🧙

Ruma (website)

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

Kévin Commaille announces

Since our last update from about a month ago, we had two bugfix releases:

  • Ruma 0.6.2 added methods to get the current room powerlevels from a StrippedPowerLevelsEvent and to get a user's membership whether the state event is redacted or not, and added a missing export to track member changes.
  • Ruma 0.6.3 fixed the serialization and deserialization of events with a dynamic event_type and added convenience constructors for logging in with a UserIdentifier.

We have also landed a bunch of internal work:

And there are of course new fixes and features for our next release:

matrix-rust-sdk (website)

Matrix Client-Server SDK for Rust

ben reports

The majority of changes we've seen over the last week, where minor fixes in style, squashing of bugs and CI improvements as most work is currently happening in the background on Sliding Sync, mobile and UniFFI support. But there have been two additions worth mentioning: first, we've improved on the autojoin example for appservices, and secondly we've merged a community contribution to make resolving of room-alias more handy.

👉️ Wanna hack on matrix rust? Go check out our help wanted tagged issues and join our matrix channel at

Matrix Dart SDK (website)

Matrix SDK written in pure Dart.

Henri Carnot announces

This week, the team released version 0.9.7.

This week, we migrated to Matrix Api Lite 1.0.0, our simple wrapper around the matrix API endpoints and data models. This means we are now using the v1.2 Matrix spec 🎉.

Also, support for HiveCollections as Database provider was added now that our patches to hive were accepted upstream. And we now provide a way to dump and restore the client local database.

Finally, we fixed a bug with where reactions were not properly discarded from the cache and some bugs in our e2e tests.

See you next time ;)

Dept of Events and Talks 🗣️

saces reports

Matrix User Meetup Berlin

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

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

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

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

Matrix room:

Dept of Rockets 🚀

uhoreg shared with us a press release from Rocket.Chat announcing their work on interoperability with Matrix. It is super exciting to see another big player join the ecosystem. Watch this space next week for more announcements!

Dept of Ping 🏓

Thib is out this week, therefore so are the ping stats in TWIM (don't worry, they'll be back next week!).

You can still go check them out yourself in and!

That's all I know 🏁

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

Synapse 1.59 released

18.05.2022 00:00 — Releases Brendan Abolivier

Synapse 1.59 is out! Let's see what's new in this version.

Generic worker types

When Synapse instances are subject to high load, it can be useful to use workers to balance the load more effectively. Workers are separate processes that can take some of the load off the main Synapse process, and allow the homeserver to scale more effectively.

In the past, Synapse only provided a specific set of types of workers, each capable of handling a specific set of operations. For some time now we have been working on allowing more flexibility around worker configuration, which started all the way back in Synapse 1.12.0 with the introduction of a generic worker application type.

Synapse 1.59 furthers this work by deprecating the and worker application types. Homeserver administrators should change the configuration of instances using these types to the generic application type, and use the notify_appservices_from_worker and update_user_directory_from_worker to delegate application service and user directory work (respectively) to a worker.

See the upgrade notes for more information on this change.

Push rules

Push rules allow Matrix clients to define notification rules on a homeserver. One often reported issue with notification in Matrix is the fact that notifications are sent out when server ACLs, which define which server(s) can and cannot interact in a room, change. This is especially annoying during big waves of abuse, as there might be multiple servers that need to be banned from rooms, thus causing a lot of unneeded notifications.

Synapse 1.59 now supports silencing server ACL updates, by implementing the new push rule documented in MSC3786. However, since this MSC hasn't been incorporated into the spec yet, this behaviour is disabled by default in Synapse: see the implementation pull request for more information on turning it on.

Synapse 1.59 also allows third-party modules to validate and change the actions associated with an existing push rule via the Module API. This is helpful for modules wishing to, for example, configuring specific notification settings when new users register.

Everything else

As of Synapse 1.59, Synapse will not communicate the name of devices over federation (unless configured otherwise), in order to better preserve user privacy. See the upgrade notes for more information.

Also note that we have issued a patch release for 1.59 (1.59.1) which fixes a long-standing bug that started to bite a good amount of server administrators. Server admins that are looking into upgrading their instance to Synapse 1.59 are recommended to upgrade to 1.59.1 rather than 1.59.0.

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

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

Synapse 1.58 released

05.05.2022 00:00 — Releases Brendan Abolivier

Synapse 1.58 is out! Let's dive into this new release.


If you've been reading the past few Synapse release announcements, you might have already heard about our efforts to integrate Poetry into Synapse. Poetry is a tool which manages dependencies of a Python project. Its killer feature is its lockfile, which explicitly pins all dependencies (direct and transitive) to a fixed version, even across multiple Python versions and platforms. See more about why we choose Poetry here.

During the past few months, we've been hard at work converting Synapse and its CI to use Poetry. The goal is to make our Docker images and Debian packages more reproducible and to provide a fixed, known-good environment for CI. This will help us to ensure the stability and security of Synapse installations.

Synapse 1.57's Docker image was the first to use Poetry; after a successful trial, this was extended to Synapse 1.58's Debian packages. Installations from PyPI using pip will not use the locked environment, though everyone is welcome to install from source using our lockfile.

Huge props to David from the Synapse team for leading the work on this front.

Everything else

This release of Synapse also includes performance improvements around sharing device list updates, which should greatly improve login times for large Matrix accounts.

Synapse 1.58 also features the implementation of two MSCs: MSC3383 to include a destination parameter in federation authentication headers, and MSC2815 which (if enabled) allows room moderators to see the content of a redacted event (as long as it hasn't already been deleted by the homeserver).

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

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

Synapse 1.57 released

19.04.2022 16:28 — Releases Brendan Abolivier

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

Application services

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

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

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

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

Improvements to the module system

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

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

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

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

Everything else

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

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

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

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

Synapse 1.56 released

05.04.2022 00:00 — Releases Brendan Abolivier

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

Additional restrictions around registration

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

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

Please see the upgrade notes for more information.

So long groups, and thanks for all the fish

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

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

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

Everything else

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

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

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

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

Synapse 1.55 released

22.03.2022 00:00 — Releases Brendan Abolivier

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

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

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

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

Removing support for Mjolnir 1.3.1 and older

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

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

See the upgrade notes for more information.

Moving synctl

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

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

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

See the upgrade notes for more information.

Everything else

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

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

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

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

Synapse 1.54 released

08.03.2022 00:00 — Releases Brendan Abolivier

Synapse 1.54 is out! Let's see what goodness is coming your way with this new release.

Improving URL previews

As part of the Matrix specification, Matrix clients have the option to rely on the homeserver to generate URL previews. This means the homeserver (in this case Synapse) needs to have a look at the content at that URL and extract data to send back to the client.

In the past, Synapse has had issues with generating complete URL previews, and some metadata (e.g. image, description) would be missing from the data that Synapse sends to clients. Synapse 1.54 includes improvements to the generation of URL previews, and while testing it we've been able to observe improvements to previews generated for Twitter and Reddit.

New module callbacks

Synapse modules allow third-party developers to write extra features for Synapse, that wouldn't necessarily be generic enough to fit within the Matrix specification. This includes custom behaviours such as smarter event filters, bespoke media storage providers, or spam checkers. Since we rewrote Synapse's module system in Synapse 1.37, we have been improving it by adding new callback functions that module can implement, allowing them to interface better with Synapse.

Synapse 1.54 includes three new module callbacks. One of them, get_displayname_for_registration, allows modules to define the display name for newly registered users. Together with the existing get_username_for_registration introduced in Synapse 1.52, they allow modules a better control over the user registration process.

The two other module callbacks introduced in Synapse 1.54, on_profile_update and on_user_deactivation_status_changed, allow modules to react to profile changes, as well as the deactivation (or reactivation) of users.

Everything else

This release of Synapse also includes more work to make joining large Matrix rooms faster (I was telling you about that in the Synapse 1.53 release announcement). While it's still very experimental and not yet ready for show time, it's still very exciting to see this work happening!

Synapse 1.54 also includes a change to the client-side versions endpoint to advertise Matrix 1.1 and 1.2. See the Matrix 1.2 release announcement to read all about the changes this latest version of the specification brings to the ecosystem.

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

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