Releases

Hey all,

It’s another quarter and therefore another spec release! Matrix 1.2 was released back in February, and while a bit late in the quarter this time around we’ve still got some exciting additions coming to you in this release.

Like last time, the speed of these releases might feel a bit quick for developers: fret not if you’re still working on v1.1 or v1.2 implementations. We’re not expecting that implementations update as soon as a new spec release is published, but rather that the ecosystem gradually update over the course of the next few months. Implementations should be aiming for as close to realtime as they can get though, particularly considering v1.4 is expected to have some large features (more on that later on).

Matrix 1.3 sees 14 MSCs get merged, but we can’t possibly go into detail on them all here. We’ve picked some notable highlights and recommend the full changelog at the bottom for a complete idea of what’s been going on.

🔗Aggregations and the relationships made along the way

It’s no secret that MSC1849-style server-side aggregation of related messages have been in the review backlog for a while. We ended up splitting MSC1849 down into more reviewable chunks like MSC2675, allowing us to finally land the first pieces into Matrix 1.3 today.

In the spec there aren’t currently any defined relationships which make use of aggregations or even the rel_type described by MSC2674, but we do expect that v1.4 of the spec will have support for at least threads (MSC3440) and edits (MSC2676), filling the gap. For now, we’ve decided that holding aggregations back until v1.4 doesn’t make a lot of sense, so we have launched them into the world as-is for custom relations or for clients & servers to prepare for what’s expected to be coming in v1.4 of the spec.

To further prepare for threads, we’ve also removed some restrictions of rich replies through MSC3676, thus allowing replies to be constructed with non-text messages like images. Check out the new rich replies module for more information.

🔗Join if you can, or just knock

When we launched restricted rooms in Matrix 1.2 we noted that we forgot to handle a case where someone might want to support both knocking and restricted rooms at the same time. We’ve fixed that with a stop-gap join rule from MSC3787 in room version 10.

The new knock_restricted join rule allows the room to keep its desire to be restricted whilst also allowing members who do not meet the criteria to knock on the room instead. We’ll likely expand on this sort of mixing of join rules in proposals like MSC3386 down the line, however for now this should cover the gap in support. Next up: figuring out how to make encrypted room history available to these new joiners in a safe way.

🔗A thread for next time

Originally planned for this release, MSC3440-style threads are anticipated to be ready for v1.4 (next quarter) with support for notifications and, of course, a whole new way to communicate in a room.

Threads are one of the more complicated features we’ve tried to land in recent history as it has a large impact on a wide variety of the spec: everything from event relationships (fixed in this release) to read receipts to push notifications needs to be worked out to build a system that not only users can understand, but also the developers trying to build it. With this massive surface area we just weren’t comfortable with adding threads to v1.3 as-is, given problems like notifications aren’t yet fully solved.

Alongside threads, we also anticipate that MSC2676-style message editing will be landing in v1.4, finally specifying how to update an event’s contents without having to redact & re-send. Although message editing has been supported for a long time in some clients, we're excited that it will finally become part of the official specification, meaning it can be implemented more widely. Messaging clients are encouraged to give the proposal an early read and possibly even attempt implementation if not already done to help us ensure the system is in a reasonable state for inclusion in the spec, though we do note that feature requests for edits will likely be deferred to a future MSC.

Keep an eye on This Week In Matrix for updates on what v1.4 is expected to include, and how things are progressing.

🔗The full changelog

MSCs are how the spec changes in the way it does - adding, fixing, and maintaining features for the whole ecosystem to use. The blog post can’t cover them all, but that doesn’t make them any less important! Check out the full changelog below, and the Spec Change Proposals page for more information on how these MSCs got merged (hint: they submitted a proposal, which anyone can do - take a look at the Matrix Live episode where Matthew covers the proposal process).

🔗Client-Server API

Deprecations

• Deprecate the sender_key and device_id on m.megolm.v1.aes-sha2 events, and the sender_key on m.room_key_request to-device messages, as per MSC3700. (#1101)

Backwards Compatible Changes

• Make from optional on GET /_matrix/client/v3/messages to allow requesting events from the start or end of the room history, as per MSC3567. (#1002)
• Add refresh tokens, per MSC2918. (#1056, #1113)
• Relax the restrictions on Rich Replies, as per MSC3676. (#1062)
• Describe a structured system for event relationships, as per MSC2674. (#1062)
• Describe how relationships between events can be "aggregated", as per MSC2675 and MSC3666. (#1062)
• Add support for a new knock_restricted join rule in supported room versions, as per MSC3787. (#1099)

Spec Clarifications

• Clarify that the url field in m.room.avatar events is not required. (#987)
• Clarify that the type in user-interactive authentication can be omitted. (#989)
• Adjust the OpenAPI specification so that the type Flow information is explicitly defined when the client-server API is rendered. (#1003)
• Correct the default value for invite where it is not specified in an m.room.power_levels event. (#1021)
• Update various links which pointed to the old matrix-doc github repository. (#1032)
• Removed m.room.message.feedback per MSC3582. (#1035)
• Fix various typos throughout the specification. (#1051, #1054, #1059, #1081, #1097, #1110, #1115, #1126, #1127, #1128, #1129, #3681, #3708)
• Clarify that state keys starting with @ are in fact reserved. Regressed from #3658. (#1100)
• Remove unenforced size limit on the name field of m.room.name events. (#3669)
• Remove erroneous room_id field from examples of m.read, m.typing in /sync and m.fully_read in room account data. (#3679)
• Clarify the behaviour of event_match in push rule conditions. (#3690)
• Fix incorrectly referenced m.login.appservice login identifier, instead using m.login.application_service. (#3711)
• Fix membership state transitions to denote that invite->knock and external->leave are valid transitions. (#3730)

🔗Server-Server API

Backwards Compatible Changes

• Add a destination property to the Authorization header, as per MSC3383. (#1067)

Spec Clarifications

• Remove largely unused origin field from PDUs. (#998)
• Update various links which pointed to the old matrix-doc github repository. (#1032)
• Clarify the format for the Authorization header. (#1038, #1067)
• Clarify what a "valid event" means when performing checks on a received PDU. (#1045)
• Clarify that valid_until_ts is in milliseconds, like other timestamps used in Matrix. (#1055)
• Clarify that checks on PDUs should refer to the state before an event. (#1070)
• Clarify the historical handling of non-integer power levels. (#1099)
• Fix various typos throughout the specification. (#1110)
• Correct misleading text for /send_join response. (#3703)
• Clarify that the content for X-Matrix signature validation is the parsed JSON body. (#3727)

🔗Application Service API

Backwards Compatible Changes

• Add timestamp massaging as per MSC3316. (#1094)

🔗Identity Service API

No significant changes.

🔗Push Gateway API

No significant changes.

🔗Room Versions

Backwards Compatible Changes

• Add room version 10 as per MSC3604. (#1099)
• Enforce integer power levels in room version 10 as per MSC3667. (#1099)
• Add a knock_restricted join rule supported by room version 10 as per MSC3787. (#1099)
• Update the default room version to 9 as per MSC3589. (#3739)

Spec Clarifications

• Improve readability and understanding of the state resolution algorithms. (#1037, #1042, #1043, #1120)
• Improve readability of the authorization rules. (#1050)
• For room versions 8, 9, and 10: clarify which homeserver is required to sign the join event. (#1093)
• Clarify that room versions 1 through 9 accept stringy power levels, as noted by MSC3667. (#1099)
• For all room versions: Add m.federate to the authorization rules, as originally intended. (#1103)
• For room versions 2 through 10: More explicitly define the mainline of a power event and the mainline ordering of other events. (#1107)
• For room versions 7, 8, 9, and 10: fix join membership authorization rules when join_rule is knock. (#3737)

🔗Appendices

No significant changes.

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 synapse.app.appservice and synapse.app.user_dir worker application types. Homeserver administrators should change the configuration of instances using these types to the generic synapse.app.generic_worker 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 is out! Let's dive into this new release.

🔗Poetry

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.

We've released updates to matrix-appservice-irc and our forked node-irc that it depends on to patch a High security vulnerability. It's advised to update to 0.34.0 as soon as possible.

The vulnerability allows an attacker to manipulate a Matrix user into executing IRC commands by having them reply to a maliciously crafted message.

Incorrect handling of a CR character allowed for making part of the message be sent to the IRC server verbatim rather than as a message to the channel.

If you are currently a matrix-appservice-irc user, exercise caution when replying to messages from untrusted participants in IRC bridged rooms until your bridge instance has been upgraded.

The vulnerability has been patched in node-irc version 1.2.1 and matrix-appservice-irc 0.34.0. You can get the release on Github.

The bridges running on the Libera Chat, OFTC and other networks bridged by the Matrix.org Foundation have been patched.

The vulnerabilities are tracked as GHSA-37hr-348p-rmf4 and GHSA-52rh-5rpj-c3w6.

Thank you, Val Lorentz for reporting this vulnerability.

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.

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 +matrix:matrix.org 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.

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 packages.matrix.org 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 packages.matrix.org. 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 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.

Rejoice everyone, Synapse 1.53 is out! Let's have a look at what's new with this release.

🔗Stabilisation of registration tokens

Registration tokens is a feature introduced in Synapse 1.42.0, which allows homeserver administrators to force their users to use specific tokens when registering. This is similar to Synapse's registration shared secret support, but with added features, such as the possibility to limit how users can be registered with the same token, or to make a token expire. See the admin API documentation for more information on how to manage registration tokens on your homeserver.

Registration tokens were initially proposed to the Matrix specification in MSC3231 by Callum Brown during their Google Summer of Code internship last summer. The MSC has since been accepted, and released in the stable Matrix specification as of Matrix v1.2. As a result, its Synapse implementation has been updated to remove support for unstable identifiers. Administrators of homeservers on which the reverse proxy rules explicitly allow the unstable route for this feature need to update their configuration. Same goes for developers of Matrix clients that support this feature. See the upgrade notes for more information.

🔗Time-based cache expiry now enabled by default

To avoid being overly intensive on resources by making too many queries to the database, Synapse maintains several in-memory caches to store data it needs to use frequently. However, this comes with the inconvenience that, if Synapse needs to store too much data, these caches can become fairly big and occupy too much space in the host's memory.

Historically, Synapse has dealt with this issue by having set sizes for each cache, either hardcoded or set in the configuration, and evicting the oldest items when exceeding this size. Synapse 1.38 introduced the possibility for homeserver administrators to configure Synapse to evict cache entries based on the time they were last accessed on. This mechanism acts on top of the aforementioned eviction policy, and allows automatically evicting entries that haven't been accessed for some time, leaving more room in the caches to store data that needs to be accessed more often.

Synapse 1.53 enables this behaviour by default. Without specific configuration, Synapse will automatically evict cache entries that haven't been accessed for more than 30 minutes. Server administrators that were already using this feature might need to update their configuration, as this change deprecates the expiry_time configuration setting, which will be removed in a future version of Synapse. See the upgrade notes for more information.

🔗Everything else

You might have heard that we're working on improving the time it takes to join big Matrix rooms with Synapse. If not, then you definitely want to have a look at the demos Matrix live that was published earlier this month and includes more details and a demo of the work we've been doing in this area.

This release of Synapse includes an implementation of MSC3706, which is part of this work. It's still very experimental and definitely not production-ready, but it's a huge stepping stone towards making room joins snappier than ever.

We've also been continuing our work towards enabling end-to-end encryption for application services (see the Synapse 1.50 release blogpost for more context on that). Synapse 1.53 includes support for sending to-device messages to application services. This is also still very experimental, watch this space for future updates.

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, Brad Jones, and Alexander Mnich.

Synapse 1.52 is out! Here's what's new with this week's release.

🔗Twisted security release

The team behind Twisted, which is the main framework Synapse uses under the hood, recently released Twisted 22.1. This version fixes a security vulnerability within the Twisted library.

While preparing the release of Synapse 1.52, we have investigated the impact of this vulnerability on Synapse. We came to the conclusion that it does not affect Synapse. We however advise server administrators to ensure they use an up-to-date version of the library as a matter of good practice.

For instances installed with pip, the library can be updated with pip install --upgrade Twisted treq. For instances installed with the matrixdotorg/synapse Docker image or Debian packages from packages.matrix.org, updating to Synapse 1.52.0 is sufficient, as these images and packages include up-to-date versions of all dependencies.

It is also worth noting that a release candidate for Twisted 22.2 has been published, with a fix for a potential denial of service vulnerability with SSH. Administrators of Synapse homeservers that have the manhole feature enabled (which is the only feature of Synapse using SSH) are encouraged to ensure access to the manhole is correctly restricted (e.g. by preventing access from external locations).

🔗Federation admin APIs

This release of Synapse introduces a few admin APIs to help server administrators monitor and handle how their Synapse homeserver interacts with other federated homeservers. One of these APIs offers server administrators a way to visualise which rooms are shared between the local homeserver and a given remote one.

Another API allows server administrators to reset federation timeouts. If Synapse fails to connect to a remote homeserver, it will make note of the failure and will not retry the connection after a certain amount of time. This can happen if the remote homeserver goes offline or experiences connectivity issues. Synapse has a few ways of figuring out whether a remote homeserver has come back online, but this new admin API adds a way for administrators to manually tell Synapse a destination should be available.

🔗Everything else

This release also improves Synapse's deactivation behaviour by deleting account data when deactivating a user. "Account data" refers to private arbitrary data that is specific to an account. It is used among other things for secure server-side storage (SSSS) which allows securely backing up end-to-end encryption keys.

Please see the Synapse 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 (in no particular order) Dirk Klimpel, Vaishnav Nair, SequentialRead Software and Nick Barrett from Beeper.