Releases

Hey all,

Welcome to the second installment of our quarterly spec releases. If it feels like it hasn’t been long since our last release, you’re not alone! Our last release was just 3 months ago, introducing the new platform and world we build within.

This improvement in speed might seem too fast, but fret not: implementations are not expected to update as soon as the new spec is published. Rather, it is more realistic to expect that the ecosystem gradually update over the course of the following few months/year. Particularly after the massive release that was v1.1.

So, what’s new in v1.2? With 18 MSCs merged there’s a lot to cover - we’ve picked some notable highlights and recommend the full changelog at the bottom for a complete idea of what’s been going on.

🔗Rearchitecting with Spaces

Spaces launched into beta last May, redefining how we can use rooms on Matrix to represent different data structures. Described mostly as MSC1772, Spaces are simply rooms with a specific type in their m.room.create event. With state events being used to define which other rooms (meaning Spaces too) are part of that Space, the possibilities for tree-like structured data become endless.

There’s still quite a lot of work to do in the Spaces space (hah), though we’re excited to see it all land. For instance, MSC3216 and MSC2962 target power level syncing, MSC3219 aims for flair, and MSC3089 looks at file structures using Spaces. We might even be able to replace the public room directory with a server-wide space, making writing clients a little bit easier.

🔗Public, but not too public, join rules

Restricted rooms are new in this release from MSC3083. In these rooms (and therefore Spaces too!), the join rules can be configured such that a member of another room can join without needing an invite. In a typical setup, this means that a Space could be set as invite-only, but all the rooms and Spaces underneath that Space could allow joins for members of the parent Space. When someone wishes to explore the universe you’ve laid out in your Space they can simply join the interesting rooms without having to ask for invites constantly.

This feature changes how membership events are authorized, so is only available in room versions 8 and 9 (both introduced in this release). Room version 9 fixes a relatively rare bug from version 8, so we’d recommend using v9 if you’re planning an upgrade for this functionality.

Further work in this area involves figuring out how to keep membership lists perfectly in sync between the rooms, which is currently done by external tooling. For example, evicting someone from the parent Space could (optionally) evict the user from all the subsequent rooms and Spaces too.

We also need to figure out how to support both knocking and restricted rooms at the same time (oops). MSC3613 and MSC3386 both tackle this problem in different ways and timescales.

🔗Matrix: A URI

A massive shoutout goes to kitsune and the whole community for working on MSC2312, giving us a URI we can pass around outside of Matrix to bring us back in. The early work on this dates all the way back to 2014, the very beginning of Matrix’s development, and has since been marked Provisional by the IANA.

The full spec is available here - feel free to discuss it at matrix:r/matrix-spec:matrix.org ;)

🔗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

Breaking Changes

• The prev_content field is now returned inside the unsigned property of events, rather than at the top level, as per MSC3442. (#3524)
• The aliases property from the chunks returned by /publicRooms, as per MSC2432. (#3624)

New Endpoints

• Add the Space Hierarchy API (GET /_matrix/client/v1/rooms/{roomId}/hierarchy) as per MSC2946. (#3610)
• Add /_matrix/client/v1/register/m.login.registration_token/validity as per MSC3231. (#3616)

Backwards Compatible Changes

• Extend /_matrix/client/r0/login to accept a m.login.appservice, as per MSC2778. (#3324)
• Add support for restricted rooms as per MSC3083, MSC3289, and MSC3375. (#3387)
• Add is_guest to /account/whoami as per MSC3069. (#3605)
• Expand guest access to sending any room event and state event as per MSC3419. (#3605)
• Add Spaces and room types as per MSC1772 and MSC2946. (#3610)
• Add new m.set_displayname, m.set_avatar_url, and m.3pid_changes capabilities as per MSC3283. (#3614)
• Add support for fallback keys (optional keys used once one-time keys run out), as per MSC2732. (#3615)
• Add token-authenticated registration support as per MSC3231. (#3616)

Spec Clarifications

• Make AesHmacSha2KeyDescription consistent with KeyDescription in marking name as optional. (#3481)
• Fix various typos throughout the specification. (#3482, #3495, #3509, #3535, #3591, #3601, #3611, #3671, #3680)
• Explicitly mention RFC5870 in the definition of m.location events (#3492)
• Add 403 M_FORBIDDEN error code to /profile/{userId} as per MSC3550. (#3530)
• Clarify the description of the /sync API, including a fix to an ASCII art diagram. (#3543)
• Clarify that base_url in client well_known may or may not include trailing slash. (#3562)
• Clarify which signature to check when decrypting m.olm.v1.curve25519-aes-sha2 messages. (#3573)
• Clarify what "Stripped State" is and what purpose it serves, as per MSC3173. (#3606)
• Clarify how to interpret missing one-time key counts. (#3636)
• Correct the schema for the responses for various API endpoints. (#3650)
• Clarify that group mentions are no longer in the specification. (#3652)
• Distinguish between "federation" event format as exchanged by the Federation API, and the "client" event formats as used in the client-server and AS APIs. (#3658)
• Fix the rendering of the responses for various API endpoints. (#3674)

🔗Server-Server API

New Endpoints

• Add the Space Hierarchy API (GET /_matrix/federation/v1/hierarchy/{roomId}) as per MSC2946. (#3610, #3660)

Backwards Compatible Changes

• Add support for restricted rooms as per MSC3083, MSC3289, and MSC3375. (#3387)

Spec Clarifications

• Fix various typos throughout the specification. (#3527)
• Clarify that GET /_matrix/federation/v1/event_auth/{roomId}/{eventId} does not return the auth chain for the full state of the room. (#3583)
• Fix the rendering of the responses for various API endpoints. (#3674)

🔗Application Service API

Spec Clarifications

• Distinguish between "federation" event format as exchanged by the Federation API, and the "client" event formats as used in the client-server and AS APIs. (#3658)
• Fix the rendering of the responses for various API endpoints. (#3674)
• Correct the documentation for the response value for GET /_matrix/app/v1/thirdparty/protocol/{protocol}. (#3675)

🔗Identity Service API

Backwards Compatible Changes

• Add the room_type to stored invites as per MSC3288. (#3610)

Spec Clarifications

• Fix the rendering of the responses for various API endpoints. (#3674)

🔗Push Gateway API

Spec Clarifications

• Fix the rendering of the responses for various API endpoints. (#3674)

🔗Room Versions

Backwards Compatible Changes

• Add Room Version 8 as per MSC3289. (#3387)
• Add Room Version 9 as per MSC3375. (#3387)

Spec Clarifications

• Fully specify room versions to indicate what exactly is carried over from parent versions. (#3432, #3661)
• Clarifications to sections on event IDs and event formats. (#3501)
• Remove a number of fields which were incorrectly shown to form part of the unsigned data of a Federation PDU. (#3522)
• Fix heading order of room version specifications to be consistent. (#3683)
• Add missing "Signing key validity period" section to room version 6. (#3683)
• Fix auth rules to allow membership of knock -> leave in v7, v8, and v9. (#3694)

🔗Appendices

Backwards Compatible Changes

• Describe "Common Namespaced Identifier Grammar" as per MSC2758. (#3171)
• Describe the matrix: URI scheme as per MSC2312. (#3608)

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

🔗Deprecation of the webclient listener

A long time ago, Synapse used to serve a very basic web Matrix client (named "console") that could be used to connect to the homeserver. Server administrators could chose to make it available to their users by configuring a webclient listener.

This web client was removed in Synapse 0.34 back in 2018, but the webclient listener stayed, instead allowing server admins to serve the web client of their choice (or redirect to it) through the web_client_location configuration file.

Synapse 1.53 will remove the webclient listener, as well as the ability to set web_client_location to a static directory (instead of a HTTP(S) URL). See the upgrade notes for more information.

🔗Aggregations and sync

The concept of server-side aggregation in Matrix is defined in MSC2675 and is the ability for homeservers to extend the information included in an event using other events that relate to it. This allows, for example, clients to quickly retrieve the reactions associated with a given message, or its latest edit.

This release includes a number of notable performance improvements to calculating aggregations when responding to /sync requests. We continue to measure and investigate potential performance improvements in this area, which should end up greatly benefiting /sync response times.

🔗FOSDEM

FOSDEM, one of the biggest gatherings around free and open-source software in the world, is happening next week! Just like last year, the conference will happen online and will be hosted on Matrix. And just like last year, it will be packed with super interesting Matrix-related (but not only) talks.

One new addition this year is the presence of a whole devroom dedicated to Matrix. It will be hosted on February 6th, and you can already find its whole schedule of talks right here.

The Synapse team will be giving a couple of talks during the day: Events for the Uninitiated by Shay at 11:10, and Beyond the Matrix: Extend the capabilities of your Synapse homeserver by yours truly at 16:40 (all times CET). Come say hi! 🙂

🔗Everything else

This release includes a couple of spaces-related bug fixes, specifically related to the /_matrix/client/v1/room/{roomId}/hierarchy API. One of them in particular targets a bug in spaces that include more than 50 rooms, and should make it much easier to look for a specific room inside a space.

The synapse_review_recent_signups script, which allows homeserver administrators to review recent signups (e.g. in the event of a spam attack), was also improved with an option to exclude virtual users belonging to an application service from the results. See synapse_review_recent_signups --help for more information.

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, br4nnigan, Philippe Daouadi, Daniël Sonck and AndrewFerr.

Welcome all for the first Synapse release of 2022: Synapse 1.50!

Note that, as per our platform dependency deprecation policy, Synapse no longer supports Python 3.6 and PostgreSQL 9.6 as of this version. As a result, we have also stopped shipping Debian packages for Ubuntu 18.04 LTS (Bionic Beaver), as it ships with Python 3.6.

As a reminder, please note that Ubuntu 21.04 (Hirsute Hippo) reaches its own end of life on January 20, 2022. Past this date we will stop producing new packages for Ubuntu 21.04.

🔗Encrypted application services

Application services (sometimes called "appservices"), are privileged processes that can interact with a Matrix homeserver in a way a normal user cannot. This is especially useful for bridges, as it allows them to register and puppet multiple users on the homeserver to replicate activity from other platforms.

One of the main shortcomings of application services currently is that they do not support end-to-end encryption. This means that messages sent through a bridge are never encrypted and always visible by the homeserver.

We've recently started work to tackle this issue in the form of MSC3202. A first part of implementing this MSC (allowing application services to masquerade as specific devices) has landed in this release of Synapse; work is still ongoing towards a full implementation, so watch this space!

🔗Improved reliability on device list updates

While working on this release, we identified a long-standing bug that could prevent Synapse from sending device lists update over federation if the server had a high number of active users and/or users with a lot of devices connected to their account.

This bug was introduced back in Synapse 1.0.0, and meant that the homeserver would miss some device list updates when communicating with other homeservers if the amount of updates to send was too high. In practice, this means users on remote homeservers could see outdated device information for other users (including outdated device verification statuses).

Synapse 1.50 includes a fix to this bug. This should contribute towards making the propagation of device list updates more reliable.

🔗Everything else

This release introduces support for MSC3419, which allows guest users to send arbitrary state events into a room. This will be especially useful to the ongoing work on group VoIP calls, which involves having users send new state events into the room to signal their participation in a call.

We've also stabilised identifiers for cross-signing and fallback keys now that MSC1756 and MSC2732 have been merged into the Matrix spec.

On the documentation side of things, the page on setting up and configuring a TURN server has been updated to feature instructions on how to deal with NATs. This is a much welcome addition as configuring TURN is something a lot of Synapse admins struggle with!

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 Dirk Klimpel, Donny Johnson and AndrewFerr.

Note: An issue preventing client logins (#11763) was identified immediately following the release of Synapse 1.50.0. We released Synapse 1.50.1 the same day with a fix for this issue.

Synapse 1.49.0 is out now!

🔗Platform deprecations

Synapse 1.49.0 is the last version of Synapse to officially support Python 3.6 and PostgreSQL 9.6. This follows our platform dependency deprecation policy.

As a consequence of this, Synapse 1.49.0 is the last version of Synapse to support Ubuntu 18.04 LTS (Bionic Beaver), as it ships with Python 3.6.

On the topic of supported Ubuntu releases, please note that Ubuntu 21.04 (Hirsute Hippo) reaches its own end of life on January 20, 2022. Past this date we will stop producing new packages for Ubuntu 21.04.

🔗Improved documentation

Up until now, a lot of very useful information was stored on the Synapse repo's wiki, which wasn't well advertised nor well reviewed.

With this release, we have migrated most of this information to Synapse's documentation website, so all the information you need to set up, maintain and troubleshoot a Synapse instance lives at the same place. Included in these new pages are the server admin FAQ and a guide to Synapse's Grafana dashboard.

The media repository documentation has also been updated with a lot of details about how Synapse stores media files.

🔗Refresh tokens

When a Matrix client needs to authenticate a request to a homeserver, it uses what is called an access token. Sometimes server administrators might not want a user's access token to live forever (e.g. for security reasons). To address this concern, MSC2918 introduces the concept of refresh tokens to Matrix.

Initial support for refresh tokens in Synapse was introduced in version 1.38.0. Synapse 1.49.0 finalises and stabilises this implementation, allowing any client that supports this feature to use it as it is currently described in the related MSC.

🔗Everything else

This release introduces the last changes needed to Synapse for basic threading support. It also introduces support for MSC3030, which allows clients to jump to a specific date in a room's history (expect a sneak peek of this in the next episode of Matrix Live!).

Another interesting point is the addition of a couple of admin APIs for federation. More specifically, they allow you to visualise all of the other homeservers your Synapse instance has been interacting with, as well as how successful the last attempts at communicating with them have been.

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 Dirk Klimpel, Maximilian Bosch and Tulir Asokan.

🔗Till next year

This is the last release of Synapse of 2021! The Synapse team will take a break for the holidays, pushing the next release of Synapse (1.50.0) to January 11, 2022.

We'd like to thank everyone who has been using Synapse, contributing to it, and/or supporting us for the past year, and we hope to see you again in 2022! 🎆

Synapse 1.48.0 is out now!

NOTE: Synapse 1.49, due out on December 14th, will be the last release of Synapse to support Python 3.6 or PostgreSQL 9.6 per our platform dependency deprecation policy. Accordingly, we will remove support for Ubuntu 18.04 LTS (Bionic) at the same date, as it ships with Python 3.6.

🔗Password resets and identity servers

This release removes the long-deprecated trust_identity_server_for_password_resets configuration option. This option was initially deprecated in Synapse 1.4.0 back in October 2019.

Admins of servers still using this configuration option will need to update their Synapse configuration to send password resets through an SMTP server directly rather than relying on identity servers to send them on their behalf.

🔗New admin APIs and improved alignment with Matrix 1.1

This release also introduces a handful of new admin APIs, allowing administrators to un-shadow-ban users, block a room, and run specific background updates (but we'll talk about this last one a bit later on). The delete room API has also been updated to be able to run in the background or to block a room pre-emptively, even if the server doesn't know about it yet.

This release also brings Synapse into greater alignment with version 1.1 of the Matrix specification by adding support for API paths beginning /_matrix/client/v3 and /_matrix/media/v3.

🔗Background updates

When Synapse updates from one version to another, it might need to run large scale updates on its database. In order to avoid blocking startup for too long while waiting for these updates to run, Synapse runs them in the background after starting.

Lately the Synapse team has been doing some work to improve the performance of these background updates. More specifically, this release includes a performance fix for a background update introduced in Synapse 1.47.0, as well as a new admin API to let admins rerun specific updates.

Future Synapse updates will also include module capabilities and more configuration options for controlling background updates.

🔗Everything else

This release also includes some improved support of MSC3440 to help threading. It also adds support for the stable identifiers from MSC2778, bringing Synapse closer to supporting end-to-end (or end-to-bridge) encryption support for application services.

We also now publish a Docker image, matrixdotorg/synapse:develop, which tracks the development head of Synapse.

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 Dirk Klimpel, Stanislav Motylkov, Tulir Asokan and Neeeflix.

Today we are releasing Synapse 1.47.1, a security update based on last week's release of Synapse 1.47.0. This release patches one high severity issue affecting Synapse installations 1.47.0 and earlier using the media repository. An attacker could cause these Synapses to download a remote file and store it in a directory outside the media repository.

Note that:

• This only affects homeservers using Synapse's built-in media repository, as opposed to synapse-s3-storage-provider or matrix-media-repo.
• Attackers cannot control the exact name or destination of the stored file.

To quote from the advisory:

🔗GHSA-3hfw-x7gx-437c / CVE-2021-41281: Path traversal when downloading remote media.

🔗Impact

Synapse instances with the media repository enabled can be tricked into downloading a file from a remote server into an arbitrary directory, potentially outside the media store directory.

The last two directories and file name of the path are chosen randomly by Synapse and cannot be controlled by an attacker, which limits the impact.

Homeservers with the media repository disabled are unaffected. Homeservers configured with a federation whitelist are also unaffected.

The advisory has full details, including workarounds.

This issue was discovered and fixed by our internal security team.

Please update at your earliest convenience.

Synapse 1.47.0 is out now!

NOTE: We anticipate publishing a security release, Synapse 1.47.1, on the coming Tuesday, the 23rd of November.

Synapse 1.47.1 will contain a fix for a high severity issue.

Synapse 1.47.0 features additions to the admin and module APIs, a plethora of fixes for long-standing bugs, and a raft of internal improvements. Server administrators should note that this release removes a deprecated API for deleting a room and deprecates a module callback. Consult the upgrade notes for more details.

🔗New admin and module APIs

Administrators can now search for rooms by their ID or alias. We hope this will be particularly useful for projects like synapse-admin! We've also exposed an API to allow admins to control Synapse's background updates. And while it's not strictly an API change, there's a small patch which makes it easier for homeservers to redirect matrix traffic to port 443.

Authors of pluggable modules have some new toys to play with. There's a way to listen for new events; a means to retrieve room state and the ability to edit a user's membership of a room.

🔗Bug Fixes and Refactors

We fixed a variety of different bugs in this release, many of which were long-standing. It's good to see them dealt with! Worth mentioning in particular:

• Improvements to the handling of the device_inbox table, which trim redundant data to reduce database bloat.
• Fixes related to restarting workers, to ensure a more reliable upgrade process.
• Fix being unable to join certain v1 rooms, e.g. #NextCloud:matrix.org, whose state contained floating point numbers.
• Fix serialisation and duplication errors when sending ephemeral events to application services.

Additionally, work continues on improving type-checking coverage, both in Synapse and in Sygnal.

🔗Sydent 2.5.1

This week also saw the release of Sydent 2.5.1, the reference implementation of a Matrix Identity Server. This is a minor release which mainly tidies up error handling to reduce the amount of noise in logs. It should also make it easier for us to diagnose some outstanding bugs which remain to be squashed.

🔗Everything Else

In the background, we're still working away at implementing MSC3440 to facilitate threading. Early tests are promising. We're also exploring MSC2775 as a means to speed up room joins. Both will be long term projects that should hopefully reap major rewards for the Matrix ecosystem. Lastly, there's support for MSC3228 to allow identity servers to provide bespoke invites to spaces. We mentioned this last time in Sydent release notes; now we've got support for it on the Synapse side.

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 Dirk Klimpel, JohannesKleine, l00ptr, Nick Barrett, rogersheu, Samuel Philipp, Skyler Mäntysaari and Sumner Evans.

Hey all,

Once again it's been a little while since we've done a spec release (sorry; we're aiming for quarterly releases from here on out), but this time we have some pretty big news: we've got an all-new spec platform and a new versioning scheme. The new spec platform has been needed for a long time to make better sense of what Matrix is, and as part of getting that out the door we reduced the number of "Matrix versions" to just one.

Huge thanks to Will Bamberg for building it out for us, anoa for working out the deployment details, and everyone for testing it all. They talk at length about what this specification even is and about the platform itself on Matrix Live S6E19. It's the single greatest improvement to the spec we've seen to date.

The new versioning scheme presents the whole specification as a single document, making it easier to check compatibility between implementations and the spec itself. Previously, a grid would have to be drawn to show whether Server-Server r0.1.4 is compatible with Client-Server r0.6.1 - while obvious at release time, the historical context gets lost quite easily. Now, with a single version number, the entire specification is compatible across a single version number: servers implementing Matrix 1.1 will be compatible with clients implementing v1.1, and vice versa. For the specification itself, this means we no longer have to carefully point and update links between the APIs, as they'll instead be versioned together.

Changing the versioning of the specification does have an impact on the Client-Server API in particular, however. You may have noticed that Client-Server APIs are currently versioned at "r0". By removing rX.Y.Z versioning, all of the endpoints suddenly don't have a version to reference. All endpoints across the specification are now versioned individually to allow for breaking changes at the endpoint level. They no longer require the whole specification to be listed as a breaking change: a v1 endpoint can get additions/changes which are backwards compatible, but if we need to change format (for example) then it'll get bumped up to v2, leaving v1 in its last known state.

For the Client-Server API, a slight complication is that v1 and v2 (alpha) are already versions familiar to those that have been around for a while - to avoid confusing those people, existing Client-Server API endpoints will start at v3. New endpoints introduced after v1.1 will start at v1 instead.

It's been well over a year since the last release, which means there's a whole lot of features and changes to cover. Here we'll try to cover the things most clients/servers will have to worry about, but we do still recommend reading through the changelog included below. Overall, 28 MSCs have been merged through this release, but some have had to be excluded in the interest of getting the spec release out there. Many of them are expected to be in the next anticipated release (which should hopefully be next quarter).

🔗Clients: There's a lot of stuff

In Matrix 1.1, client developers get all sorts of new features to play with. Clients which support end-to-end encryption should explore key backups, cross-signing, SSSS, and breaking changes to verification. Quite a lot of this stuff has existed for a while, but has made it into the specification formally now. As an added bonus, the emoji for SAS verification have been translated (contribute here).

Knocking has also landed in the spec (thanks Sorunome for leading the charge on this!), opening up the ability for rooms to optionally allow people to request invites to join. This can be helpful for semi-private rooms where it can be easier to approve/deny requests compared to finding someone's MXID and manually inviting them. This does require a v7 room to work, however.

Thanks again to Sorunome, Message Spoilers have been officially included in Matrix. People can now safely discuss the ending to the latest movie without being banned for spoilers. Though, as a new feature, there's a chance that the spoiler text still gets included in the message: clients should update as soon as possible to avoid their users accidentally getting banned for spoiling the conclusion to the Spaces saga ;)

There's a few other smaller improvements/additions, and of course the regular "various clarifications and bug fixes" to take a look at. For a sample checklist, check out element-web's issue on the subject.

🔗Servers: Knock knock, it's a new room version

Room version 7 has landed, bringing forth the ability for users to knock on rooms (requesting an invite to join). The changes are largely scoped to using the reserved keywords for join rules and membership, and are described through the auth rules. Thankfully, the changes over v6 are minimally invasive so should be quick to implement.

Additionally, the cross-signing bits have been included in the API responses and EDU definitions. Matthew's blog post from last year (it really has been that long...) describes cross-signing and the history of its implementation.

As per usual, there's also various specification errors corrected to aid understanding. Synapse has an exhaustive issue to detail what servers might need to do.

PS: Room versions 8 and 9 are also out there, but will be included in a future spec release.

🔗The full changelog

We haven't mentioned identity servers, bridges, etc in this post but they have changes too! Below is the whole changelog, the entire year and a bit of it. Thank you to everyone who has submitted MSCs, and congratulations on getting them released. If we forgot yours, please mention it in #matrix-spec:matrix.org so we can apologize and correct.

PS: The MSC process is how changes to Matrix are made, and you (yes, you) can propose those changes too. Check out the Matrix Live episode where Matthew talks about how this process works, and how we avoid blocking clients from implementing their proposals behind the relatively slow spec release cycles.

🔗Client-Server API

Breaking Changes

• Document curve25519-hkdf-sha256 key agreement method for SAS verification, and deprecate old method as per MSC2630. (#2687)
• Add m.key.verification.ready and m.key.verification.done to key verification framework as per MSC2366. (#3139)

Deprecations

• Deprecate starting verifications that don't start with m.key.verification.request as per MSC3122. (#3199)

New Endpoints

• Add key backup (/room_keys/*) endpoints as per MSC1219. (#2387, #2639)
• Add POST /keys/device_signing/upload and POST /keys/signatures/upload as per MSC1756. (#2536)
• Add /knock endpoint as per MSC2403. (#3154)
• Add /login/sso/redirect/{idpId} as per MSC2858. (#3163)

Removed Endpoints

• Remove unimplemented m.login.oauth2 and m.login.token user-interactive authentication mechanisms as per MSC2610 and MSC2611. (#2609)

Backwards Compatible Changes

• Document how clients can advise recipients that it is withholding decryption keys as per MSC2399. (#2399)
• Add cross-signing properties to the response of POST /keys/query as per MSC1756. (#2536)
• Document Secure Secret Storage and Sharing as per MSC1946 and MSC2472. (#2597)
• Add a device_id parameter to login fallback as per MSC2604. (#2709)
• Added a common set of translations for SAS Emoji. (#2728)
• Added support for reason on all membership events and related endpoints as per MSC2367. (#2795)
• Add a 404 M_NOT_FOUND error to push rule endpoints as per MSC2663. (#2796)
• Make reason and score parameters optional in the content reporting API as per MSC2414. (#2807)
• Allow guests to get the list of members for a room as per MSC2689. (#2808)
• Add support for spoilers as per MSC2010 and MSC2557, and color attribute as per MSC2422. (#3098)
• Add <details> and <summary> to the suggested HTML subset as per MSC2184. (#3100)
• Add key verification using in-room messages as per MSC2241. (#3139, #3150)
• Add information about using SSSS for cross-signing and key backup. (#3147)
• Add key verification method using QR codes as per MSC1544. (#3149)
• Document how clients can simplify usage of Secure Secret Storage as per MSC2874. (#3151)
• Add support for knocking, as per MSC2403. (#3154, #3254)
• Multiple SSO providers are possible through m.login.sso as per MSC2858. (#3163)
• Add device_id to /account/whoami response as per MSC2033. (#3166)
• Downgrade identity server discovery failures to FAIL_PROMPT as per MSC2284. (#3169)
• Re-version all endpoints to be v3 as a starting point instead of r0 as per MSC2844. (#3421)

Spec Clarifications

• Fix issues with age and unsigned being shown in the wrong places. (#2591)
• Fix definitions for room version capabilities. (#2592)
• Fix various typos throughout the specification. (#2594, #2599, #2809, #2878, #2885, #2888, #3116, #3339)
• Clarify link to OpenID Connect specification. (#2605)
• Clarify the behaviour of SSO login and UI-Auth. (#2608)
• Remove spurious room_id from /sync examples. (#2629)
• Reorganize information in Push Notifications module for clarity. (#2634)
• Improve consistency and clarity of event schema titles. (#2647)
• Fix schema issues in m.key.verification.accept and secret storage. (#2653)
• Reword "UI Authorization" to "User-Interactive Authentication" to be more clear. (#2667)
• Fix schemas for push rule actions to represent their alternative object form. (#2669)
• Fix usage of highlight tweak for consistency. (#2670)
• Clarify the behaviour of state for /sync with lazy-loading. (#2754)
• Clarify description of m.room.redaction event. (#2814)
• Mark messages as a required JSON body field in PUT /_matrix/client/r0/sendToDevice/{eventType}/{txnId} calls. (#2928)
• Correct examples of client_secret request body parameters so that they do not include invalid characters. (#2985)
• Fix example MXC URI for m.presence. (#3091)
• Clarify that event bodies are untrusted, as per MSC2801. (#3099)
• Fix the maximum event size restriction (65535 bytes -> 65536). (#3127)
• Update Access-Control-Allow-Headers recommendation to fit CORS specification. (#3225)
• Explicitly state that replacement_room is a room ID in m.room.tombstone events. (#3233)
• Clarify that all request bodies are required. (#3238, #3332)
• Add missing titles to some scheams. (#3330)
• Add User-Interactive Authentication fields to cross-signing APIs as per MSC1756. (#3331)
• Mention that a canonical alias event should be added when a room is created with an alias. (#3337)
• Add an 'API conventions' section to the Appendices. (#3350)
• Clarify the documentation around the pagination tokens used by /sync, /rooms/{room_id}/messages, /initialSync, /rooms/{room_id}/initialSync, and /notifications. (#3353)
• Remove the inaccurate 'Pagination' section. (#3366)
• Clarify how redacted_because is meant to work. (#3411)
• Remove extraneous mimetype from EncryptedFile examples, as per MSC2582. (#3412)
• Describe how MSC2844 affects the /versions endpoint. (#3420)
• Fix documentation errors around threepid_creds. (#3471)

🔗Server-Server API

New Endpoints

• Add /make_knock and /send_knock endpoints as per MSC2403. (#3154)

Backwards Compatible Changes

• Add cross-signing information to GET /user/keys and GET /user/devices/{userId}, m.device_list_update EDU, and a new m.signing_key_update EDU as per MSC1756. (#2536)
• Add support for knocking, as per MSC2403. (#3154)

Spec Clarifications

• Specify that GET /_matrix/federation/v1/make_join/{roomId}/{userId} can return a 404 if the room is unknown. (#2688)
• Fix various typos throughout the specification. (#2888, #3116, #3128, #3207)
• Correct the /_matrix/federation/v1/user/devices/{userId} response which actually returns "self_signing_key" instead of "self_signing_keys". (#3312)
• Explain the reasons why <hostname> TLS certificate is needed rather than <delegated_hostname> for SRV delegation. (#3322)
• Tweak the example PDU diagram to better demonstrate situations with multiple prev_events. (#3340)

🔗Application Service API

Spec Clarifications

• Fix various typos throughout the specification. (#2888)

🔗Identity Service API

New Endpoints

• Add GET /_matrix/identity/versions API as per MSC2320. (#3101)

Removed Endpoints

• The v1 identity service API has been removed in favour of the v2 API, as per MSC2713. (#3170)

Spec Clarifications

• Fix various typos throughout the specification. (#2888)
• Clarify that some identifiers must be case folded prior to processing, as per MSC2265. (#3167, #3176)
• Describe how MSC2844 affects the /versions endpoint. (#3459)

🔗Push Gateway API

Spec Clarifications

• Clarify where to get information about the various parameter values for the notify endpoint. (#2763)

Synapse 1.46.0 is out now and includes support for Ubuntu 21.10: Impish Indri.

This release includes a fix for a performance regression that surfaced in Synapse 1.44.

🔗Progress on Threading

While still disabled by default, we're beginning to land code in Synapse to support threaded discussions in Matrix. In particular, the m.thread event relationship defined in MSC3440 is now implemented behind a configuration flag.

There are still many open questions here, and MSC3440 has not yet been approved to merge into the Matrix spec, but it's a start. Threading is essential to Matrix's continued growth and adoption, and we're excited to provide server-side support to this effort.

🔗Bug Fixes and Refactors

This release is mostly comprised of bug fixes and improvements to static typing. Of note:

• The export-data admin command now works and is tested in CI. This command helps server administrators respond to GDPR Subject Access Requests.
• A weeks-long effort to refactor how Synapse validates the auth_events field of incoming PDUs has concluded, resolving a few corner cases which could incorrectly allow events into the room state which should instead be rejected.
• Further static type hints have been added to Synapse, improving our precise type coverage to 85% of all lines. Currently, 13% of the Python files in synapse/ are skipped during mypy runs. We'd like to cut this in half by the end of the year, as well as increasing overall precise coverage in the codebase.

🔗Sydent 2.5.0

This week also saw the release of Sydent 2.5.0, the reference implementation of a Matrix Identity Server. In addition to fixing bugs, Sydent 2.5.0 passes mypy --strict, uses Jinja2 for templates, and supports the room_type field from MSC3288 to better differentiate between invitations to rooms and invitations to Spaces.

🔗Everything Else

• The Admin API to create or modify accounts now accepts a user_type field, allowing for accounts to be set as belonging to bots or support staff.
• Password auth providers can now be implemented using the new pluggable extension module APIs.

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 aaronraimist, AndrewFerr, dklimpel, and Legogris.

Synapse 1.45.1 is out now! Python 3.10 and PostgreSQL 14 are now tested and supported by Synapse. Support for Python 3.6 and PostgreSQL 9.6 will be removed by the end of the year.

Note: This release may require changes to how media storage providers access your homeserver's configuration. See the Upgrade Notes for more information.

Note: Synapse 1.45.0 was released yesterday and changed how Synapse's monthly active user limits were calculated. Today's release of 1.45.1 reverts that change, but is otherwise identical to 1.45.0.

🔗Support for oEmbed Autodiscovery

Synapse can now automatically discover rich metadata when generating previews of links to sites which support oEmbed.

Before:

After:

Note that URL previews are generated server-side, and thus generally disabled in encrypted rooms to avoid leaking information about message content to your homeserver. You may need to adjust the room's settings to see the new oEmbed previews.

🔗Fixing Stuck Messages

This release of Synapse fixes a race condition which would occasionally prevent your sent events from syncing back down to all of your clients. This caused messages to look like they were stuck at the bottom of the room, waiting to finish sending, even though other users would receive and see them normally.

🔗Improved Privacy for Per-Room Nicknames

Matrix allows users to set their display names to be different things in different rooms. For example, you might use an alias in public rooms, but your real name in rooms shared with friends and family.

To make it easy to initiate conversations with people, each homeserver maintains a user directory with the Matrix ID, display name, and avatar of the users it sees. Previously, this directory would be updated with the most recent profile metadata that Synapse had seen for a user, even if it was only changed in a single room.

As of 1.45, Synapse only uses includes the default display name of local users in its user directory, ignoring room-specific nicknames or avatars. (#5677).

🔗Internals

This release includes numerous fixes and improvements to Synapse's internals.

• We've added countless static type annotations to Synapse (and related projects like Sydent), giving us greater confidence in its correctness and reducing maintenance costs. Several modules newly have all of their definitions typed, allowing us to require and enforce complete type coverage for all future edits therein.

• This release includes meaningful fixes and improvements to our OpenTracing and logging machinery, helping us better catch and eliminate bugs in Synapse. This work ultimately reduced matrix.org's Sentry event volume by an order of magnitude.

• Magic accessor methods have been removed from Synapse's Config class. Previously, Synapse would interpret references like config.send_federation by attempting to guess a reasonable full path, like config.worker.send_federation. As of Synapse 1.45, the full path must be specified directly. This prevents errors where values could be drawn from unexpected or incorrect sections of the server's configuration.

🔗Everything Else

We'd like to extend a special thanks to Fizzadar from Beeper for improving Synapse's update_synapse_database script (#10954) to allow schema changes to occur while Synapse is running. This is a great step toward reducing the downtime associated with upgrades.

These are just the highlights; please see the Upgrade Notes 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 AndrewFerr, dklimpel, Fizzadar, lukaslihotzki, and maxkratz.