Releases

142 posts tagged with "Releases" (See all Category)

Atom Feed

Synapse 1.23.0 released

18.11.2020 00:00 — Releases Dan Callahan

Reminder: On Monday, we will be announcing a denial of service vulnerability which affects Synapse versions prior to 1.20.0. If you have not upgraded recently, please do so.

Synapse 1.23.0 now available!

For Synapse admins, this release support generating structured logs via the standard logging configuration (#8607, #8685). This may require changing your synapse configuration; see the upgrade notes for more information.

We've also added many new Admin APIs, contributed by @dklimpel:

  • Add API to get information about uploaded media (#8647)
  • Add API for local user media statistics (#8700)
  • Make it possible to delete files that were not used for a defined time (#8519)
  • Split API for reported events into detail and list endpoints. This is a breaking change to #8217 which was introduced in Synapse v1.21.0. Those who already use this API should check their scripts (#8539)
  • Allow server admins to list users' notification pushers (#8610, #8689)

Lastly, Synapse 1.23.0 addresses some significant bugs, including regressions in the SQLite-to-PostgreSQL database porting script (#8729, #8730, #8755) and an issue which could prevent Synapse from recovering after losing its connection to its database (#8726). Synapse will also reject ACL modifications from clients which would otherwise cause a server to ban itself from a room (#8708).

Installation instructions are available on GitHub, as is the v1.23.0 release tag.

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 @chagai95 and @dklimpel.

The full changelog for 1.23.0 is as follows:

Synapse 1.23.0 (2020-11-18)

This release changes the way structured logging is configured. See the upgrade notes for details.

Note: We are aware of a trivially exploitable denial of service vulnerability in versions of Synapse prior to 1.20.0. Complete details will be disclosed on Monday, November 23rd. If you have not upgraded recently, please do so.

Bugfixes

  • Fix a dependency versioning bug in the Dockerfile that prevented Synapse from starting. (#8767)

Synapse 1.23.0rc1 (2020-11-13)

Features

  • Add a push rule that highlights when a jitsi conference is created in a room. (#8286)
  • Add an admin api to delete a single file or files that were not used for a defined time from server. Contributed by @dklimpel. (#8519)
  • Split admin API for reported events (GET /_synapse/admin/v1/event_reports) into detail and list endpoints. This is a breaking change to #8217 which was introduced in Synapse v1.21.0. Those who already use this API should check their scripts. Contributed by @dklimpel. (#8539)
  • Support generating structured logs via the standard logging configuration. (#8607, #8685)
  • Add an admin API to allow server admins to list users' pushers. Contributed by @dklimpel. (#8610, #8689)
  • Add an admin API GET /_synapse/admin/v1/users/<user_id>/media to get information about uploaded media. Contributed by @dklimpel. (#8647)
  • Add an admin API for local user media statistics. Contributed by @dklimpel. (#8700)
  • Add displayname to Shared-Secret Registration for admins. (#8722)

Bugfixes

  • Fix fetching of E2E cross signing keys over federation when only one of the master key and device signing key is cached already. (#8455)
  • Fix a bug where Synapse would blindly forward bad responses from federation to clients when retrieving profile information. (#8580)
  • Fix a bug where the account validity endpoint would silently fail if the user ID did not have an expiration time. It now returns a 400 error. (#8620)
  • Fix email notifications for invites without local state. (#8627)
  • Fix handling of invalid group IDs to return a 400 rather than log an exception and return a 500. (#8628)
  • Fix handling of User-Agent headers that are invalid UTF-8, which caused user agents of users to not get correctly recorded. (#8632)
  • Fix a bug in the joined_rooms admin API if the user has never joined any rooms. The bug was introduced, along with the API, in v1.21.0. (#8643)
  • Fix exception during handling multiple concurrent requests for remote media when using multiple media repositories. (#8682)
  • Fix bug that prevented Synapse from recovering after losing connection to the database. (#8726)
  • Fix bug where the /_synapse/admin/v1/send_server_notice API could send notices to non-notice rooms. (#8728)
  • Fix PostgreSQL port script fails when DB has no backfilled events. Broke in v1.21.0. (#8729)
  • Fix PostgreSQL port script to correctly handle foreign key constraints. Broke in v1.21.0. (#8730)
  • Fix PostgreSQL port script so that it can be run again after a failure. Broke in v1.21.0. (#8755)

Improved Documentation

  • Instructions for Azure AD in the OpenID Connect documentation. Contributed by peterk. (#8582)
  • Improve the sample configuration for single sign-on providers. (#8635)
  • Fix the filepath of Dex's example config and the link to Dex's Getting Started guide in the OpenID Connect docs. (#8657)
  • Note support for Python 3.9. (#8665)
  • Minor updates to docs on running tests. (#8666)
  • Interlink prometheus/grafana documentation. (#8667)
  • Notes on SSO logins and media_repository worker. (#8701)
  • Document experimental support for running multiple event persisters. (#8706)
  • Add information regarding the various sources of, and expected contributions to, Synapse's documentation to CONTRIBUTING.md. (#8714)
  • Migrate documentation docs/admin_api/event_reports to markdown. (#8742)
  • Add some helpful hints to the README for new Synapse developers. Contributed by @chagai95. (#8746)

Internal Changes

  • Optimise /createRoom with multiple invited users. (#8559)
  • Implement and use an @lru_cache decorator. (#8595)
  • Don't instantiate Requester directly. (#8614)
  • Type hints for RegistrationStore. (#8615)
  • Change schema to support access tokens belonging to one user but granting access to another. (#8616)
  • Remove unused OPTIONS handlers. (#8621)
  • Run mypy as part of the lint.sh script. (#8633)
  • Correct Synapse's PyPI package name in the OpenID Connect installation instructions. (#8634)
  • Catch exceptions during initialization of password_providers. Contributed by Nicolai Søborg. (#8636)
  • Fix typos and spelling errors in the code. (#8639)
  • Reduce number of OpenTracing spans started. (#8640, #8668, #8670)
  • Add field total to device list in admin API. (#8644)
  • Add more type hints to the application services code. (#8655, #8693)
  • Tell Black to format code for Python 3.5. (#8664)
  • Don't pull event from DB when handling replication traffic. (#8669)
  • Abstract some invite-related code in preparation for landing knocking. (#8671, #8688)
  • Clarify representation of events in logfiles. (#8679)
  • Don't require hiredis package to be installed to run unit tests. (#8680)
  • Fix typing info on cache call signature to accept on_invalidate. (#8684)
  • Fail tests if they do not await coroutines. (#8690)
  • Improve start time by adding an index to e2e_cross_signing_keys.stream_id. (#8694)
  • Re-organize the structured logging code to separate the TCP transport handling from the JSON formatting. (#8697)
  • Use Python 3.8 in Docker images by default. (#8698)
  • Remove the "draft" status of the Room Details Admin API. (#8702)
  • Improve the error returned when a non-string displayname or avatar_url is used when updating a user's profile. (#8705)
  • Block attempts by clients to send server ACLs, or redactions of server ACLs, that would result in the local server being blocked from the room. (#8708)
  • Add metrics the allow the local sysadmin to track 3PID /requestToken requests. (#8712)
  • Consolidate duplicated lists of purged tables that are checked in tests. (#8713)
  • Add some mdui:UIInfo element examples for saml2_config in the homeserver config. (#8718)
  • Improve the error message returned when a remote server incorrectly sets the Content-Type header in response to a JSON request. (#8719)
  • Speed up repeated state resolutions on the same room by caching event ID to auth event ID lookups. (#8752)

Dendrite 0.3.0 released

16.11.2020 17:44 — Releases Matthew Hodgson

Hi all,

Heads up that we just cut another beta release of Dendrite - now at 0.3.0!

This is a really fun release given almost all the changes are contributed from the wider community - so huge thanks to S7evinK, MayeulC and felix!

The main new feature is full Read Receipt support thanks to S7evinK, which makes an enormous perceptual improvement when using Dendrite - so especial thanks are due there :)

So, if you're interested in helping us test, please spin up a copy from https://github.com/matrix-org/dendrite and let us know how it goes - and if you're already running one, now is an excellent time to upgrade!

Full changelog (including 0.2.1, which we forgot to blog about) follows:

Dendrite 0.3.0 (2020-11-16)

Features

  • Read receipts (both inbound and outbound) are now supported (contributed by S7evinK)
  • Forgetting rooms is now supported (contributed by S7evinK)
  • The -version command line flag has been added (contributed by S7evinK)

Fixes

  • User accounts that contain the = character can now be registered
  • Backfilling should now work properly on rooms with world-readable history visibility (contributed by MayeulC)
  • The gjson dependency has been updated for correct JSON integer ranges
  • Some more client event fields have been marked as omit-when-empty (contributed by S7evinK)
  • The build.sh script has been updated to work properly on all POSIX platforms (contributed by felix)

Dendrite 0.2.1 (2020-10-22)

Fixes

  • Forward extremities are now calculated using only references from other extremities, rather than including outliers, which should fix cases where state can become corrupted (#1556)
  • Old state events will no longer be processed by the sync API as new, which should fix some cases where clients incorrectly believe they have joined or left rooms (#1548)
  • More SQLite database locking issues have been resolved in the latest events updater (#1554)
  • Internal HTTP API calls are now made using H2C (HTTP/2) in polylith mode, mitigating some potential head-of-line blocking issues (#1541)
  • Roomserver output events no longer incorrectly flag state rewrites (#1557)
  • Notification levels are now parsed correctly in power level events (gomatrixserverlib#228, contributed by Pestdoktor)
  • Invalid UTF-8 is now correctly rejected when making federation requests (gomatrixserverlib#229, contributed by Pestdoktor)

How we fixed Synapse's scalability!

03.11.2020 00:00 — Releases Matthew Hodgson

Hi all,

We had a major break-through in Synapse 1.22 which we want to talk about in more detail: Synapse now scales horizontally across multiple python processes.

Horizontal scaling means that you can support more users and traffic by adding in more python processes (spread over more machines, if necessary) without there being a single bottleneck which all the traffic is passing through - as opposed to vertical scaling where you make things go faster overall by making the bottleneck go faster.

After many years of having to vertically scale Synapse (by trying to make the main process go faster) we’re now finally at the point where you can configure Synapse so that messages no longer flow through the main process - eliminating the bottleneck entirely. What’s more, the Matrix.org homeserver has now been successfully running in this config and enjoying the massive scalability improvements for the last 2 weeks! Huge kudos goes to Erik and the wider Synapse team for pulling this off.

Some readers might wonder how this ties in with Dendrite entering beta, given one of Dendrite’s design goals is full horizontal scalability. The answer is that we’re very much using Dendrite for experimentation and next-gen stuff at the moment (currently focused more on scaling downwards for P2P rather than scaling upwards for megaservers) - while Synapse is the stable and long-term supported option.

So, that’s the context - now over to Erik with more than you could possibly ever want to know about how we actually did it...

Background

Synapse started life off back in 2014 as a single monolithic python process, and for quite a while we made it scale by adding more and more in-memory caches to speed things up by avoiding hitting the database (at the expense of RAM). It looked like this:

Eventually the caches stopped helping and we needed more than one thread of execution in order to spread CPU across multiple cores. Python’s Global Interpreter Lock (GIL) means that Python can mainly only use one CPU core at a time, so starting more threads doesn’t help with scalability - you have to run multiple processes.

Now, the vast majority of the work that Synapse does is related to “streams”. These are append only sequences of rows, such as the events stream, typing stream, receipts stream, etc. When a new event arrives (for example) we write it to the events stream, and then notify anything waiting that there has been an update. The /sync endpoint, for instance, will wait for updates to streams and send them down to long-polling Matrix clients.

Streams support being added to concurrently, so have a concept of the “persisted up-to position”. This is the point where all rows before that point have finished persisting. Readers only read up to the current “persisted up-to position”, so that they don’t skip updates that haven’t finished persisting at that point. (E.g. if two events A and B get assigned positions 5 and 6, but B finishes persisting first, then the persisted up to position will remain at 4 until A finishes persisting and then it jumps to 6).

To split any meaningful amount of work into separate processes, we need to add a mechanism where processes can be told that updates to streams have happened (otherwise they’d have to repeatedly poll the DB, which would be deeply inefficient). The architecture ended up being one where we had the “main” process that streams updates via a custom replication protocol (initially long-polling HTTP; later custom TCP) to any number of “worker” processes. This meant that we could move sync stream handling (and other read apis) off the main process and onto workers, but also that all database writes had to go through the single main process (as it was a star topology, the main process could talk to all workers but workers could only talk to the main process and not each other).

2020-11-03-synapse2.png

As an aside: cache invalidations also had to be streamed down the replication connections, which has the side effect that we could only cache things that would only be invalidated on the main process.

We continued to move more and more read APIs out onto separate workers. We also added workers in front of the main process that would e.g. handle the creation of the new events, authenticating, etc, and then call out to the main process with the event for it to persist the event.

Moving writes off the main process

Eventually we ran out of stuff to move out of the main process that didn’t involve writing to the DB. To write stuff from other processes we needed a way for the workers to stream updates to each other. The easiest and most obvious way was to just use Redis and its pub/sub support.

2020-11-03-synapse3.png

This almost allowed us to move writing of a particular stream to a different worker, except writing to streams generally also meant invalidating caches which in itself requires writing to a stream. We needed a way of writing to the cache invalidation stream from multiple workers at once.

Sharding the cache invalidation thankfully turned out to be easy, as workers would simply call the cache invalidation function whenever they get an invalidation notice over replication. In particular, the ordering of invalidations from different workers doesn’t matter and so there isn’t a need to calculate a single “persisted up-to position”. Sharding then just becomes a case of adding the name of the worker that is writing the update to the replication stream, and then workers reading from it can basically treat the cache stream the same as if they were multiple streams, one per worker.

This then unlocks the ability to move writing of streams off the main process and onto different workers - and so we added the “event persister” worker for offloading the main event stream off the main process:

2020-11-03-synapse4.png

Sharding the events stream

Eventually the worker responsible for doing nothing but persisting events started maxing out CPU. This meant that we had to look at sharding the events stream, i.e. writing to it from multiple workers.

This is more complicated than sharding the cache invalidation stream as the ordering of the events does matter; we send them down sync streams, in order, with a token that indicates where the sync stream is up to in the events stream. This means that workers need to be able to calculate a “persisted up-to position” when getting updates from different workers.

The easiest way of doing that is to simply set the persisted up-to position as the minimum position received over federation from all active writers. This works, except events would only be processed after all other writers have subsequently written events (to advance the persisted position past the point at which the event was written), which can add a lot of latency depending on how often events are written.

A refinement is to note that if you have a persisted up-to position of 10, then receive updates at sequential positions 11, 12, 13 and 14, you know that everything between 10 and 14 has finished persisting (as you received updates about them), and so can set the persisted up-to position to 14. Annoyingly, it’s not required that positions are sequential without gaps (due to various technical considerations), and so in the worst case this still has the same problems as the naïve solution.

To avoid these problems we change the persisted up-to position to be a vector clock of positions; tracking a vector of positions - one per writer. This still allows answering the query of “get all events after token X” (as events are written with the position and the name of the writer). The persisted up-to position is then calculated by just tracking the last position seen to arrive over replication from each writer.

This allows writing events from multiple workers, while ensuring that other workers can correctly keep track of a “persisted up-to position”. Then it's just a matter of inspecting the code to ensure that it does not assume that it is the only writer to the stream. In the case of writing to the events stream, we note that the function persisting events assumes it's the only writer for a given room, so when sharding we have to ensure that there are no concurrent writes to the same room. This is most easily done by sharding based on room ID, and ensuring that the mapping of room ID to worker does not change (without coordination).

The only thing left is to then encode the vector clock position into the sync tokens. We want to ensure that these tokens are not too long, as they get included as query string parameters (e.g. the since= parameter of /sync). By assigning persistent unique integer IDs to workers the vector clock can be persisted as a sequence of pairs of integers, which is relatively few bytes so long as we don’t have too many workers writing to the events stream. We can further reduce the size of the tokens by calculating an integer “persisted up-to position” as we did before, encoding that and only including positions for workers that are larger than the integer persisted upto position. (The idea here is that most of the time only a small number of workers will be ahead of the calculated persisted up-to position, and so we only need to encode those).

And this is what we have today:

2020-11-03-synapse5.png

The major limitation of the current situation is that you can’t dynamically add/remove workers which persist events, as the sharding by room ID is calculated at startup, and so changing it requires restarting the whole system. This could be replaced by any system that allowed coordination over which persister is allowed to write to a room at any given point. However this is likely tricky to get right in practice, but would allow dynamic auto scaling of deployments, or automatically recovering from a worker that gets wedged/dies.

Finally, it’s worth noting that sharding event persisters isn’t the only performance work that’s been going on - switching everything over to python 3 and async twisted has helped, along with lots of smaller optimisations on the hot paths, and further rebalancing workers (e.g. moving background jobs off the master process to dedicated workers). We’ve also benefited a lot from the maintainability of rolling out mypy typing throughout the codebase. And next up, we’ll be going back to speeding up the codebase as a whole - starting with algorithmic state resolution improvements! 🎉

Performance

So, how does it stack up?

Here’s the send time heatmap on Matrix.org showing the step change on Oct 16th when we rolled out the second event persister (full disclosure: this also coincides with moving background processes off the main Synapse process to a background worker). As you can see, we go from messages being spread over a huge range of durations (up to several seconds) to the sweet spot being 50ms or less - a spectacular improvement!

2020-11-03-synapse-heatmap.png

Meanwhile, here’s the actual CPU utilisation as we split the traffic from a single event persister (yellow) to two persisters (one yellow, one blue), showing the sharding beautifully horizontally balancing CPU between the two active/active worker processes:

2020-11-03-synapse-cpu.png

We’ve yet to loadtest to see just how fast we can go now (before we start hitting bottlenecks on the postgres cluster), but it sure feels good to have all our CPU headroom back on Matrix.org again, ready for the next wave of users to arrive.

Conclusion

So there you have it: folks running massive homeservers (50K+ concurrent users) like Matrix.org (and cough various high profile public sector deployments) are no longer held hostage by the bottleneck of the main synapse process and should feel free to experiment with setting up event persister workers to handle high traffic loads. Otherwise, if you can spread your users over smaller servers, that’s also a good bet (assuming they don’t have massively overlapping room membership, like we see on Matrix.org.)

The current worker documentation is up-to-date, although does assume you are already very familiar with how to administer Synapse. It’s also very much subject to change, as we keep adding new workers and improving the architecture. However, now is a pretty good time to get involved if you’re interested in large-scale Matrix deployments.

-- The Synapse Team

Synapse 1.22.0 released

27.10.2020 17:01 — Releases Dan Callahan

Synapse 1.22.0 now available!

This release focused on improving Synapse's horizontal scalability, including:

  • Support for running background tasks in separate worker processes.
  • Fixes to sharded event persisters, which were experimentally introduced in 1.21.0.
  • Fixing a message duplication bug with worker-based deployments. (#8476)

Synapse 1.22.0 also has a few other notable changes:

  • Defaulting to version 6 rooms, per MSC2788.
  • Initial support for three new experimental MSCs:
    • MSC2732: Supporting olm fallback keys
    • MSC2697: Supporting device dehydration
    • MSC2409: Allowing appservices to receive ephemeral events like read receipts, presence, and typing indicators.
  • Multi-arch Docker images, covering arm64 and arm/v7 in addition to amd64.

Installation instructions are available on GitHub, as is the v1.22.0 release tag.

Lastly, 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 @Akkowicz, @BBBSnowball, @maquis196, and @samuel-p.

The full changelog for 1.22.0 is as follows:

Synapse 1.22.0 (2020-10-27)

No significant changes.

Synapse 1.22.0rc2 (2020-10-26)

Bugfixes

  • Fix bugs where ephemeral events were not sent to appservices. Broke in v1.22.0rc1. (#8648, #8656)
  • Fix user_daily_visits table to not have duplicate rows per user/device due to multiple user agents. Broke in v1.22.0rc1. (#8654)

Synapse 1.22.0rc1 (2020-10-22)

Features

  • Add a configuration option for always using the "userinfo endpoint" for OpenID Connect. This fixes support for some identity providers, e.g. GitLab. Contributed by Benjamin Koch. (#7658)
  • Add ability for ThirdPartyEventRules modules to query and manipulate whether a room is in the public rooms directory. (#8292, #8467)
  • Add support for olm fallback keys (MSC2732). (#8312, #8501)
  • Add support for running background tasks in a separate worker process. (#8369, #8458, #8489, #8513, #8544, #8599)
  • Add support for device dehydration (MSC2697). (#8380)
  • Add support for MSC2409, which allows sending typing, read receipts, and presence events to appservices. (#8437, #8590)
  • Change default room version to "6", per MSC2788. (#8461)
  • Add the ability to send non-membership events into a room via the ModuleApi. (#8479)
  • Increase default upload size limit from 10M to 50M. Contributed by @Akkowicz. (#8502)
  • Add support for modifying event content in ThirdPartyRules modules. (#8535, #8564)

Bugfixes

  • Fix a longstanding bug where invalid ignored users in account data could break clients. (#8454)
  • Fix a bug where backfilling a room with an event that was missing the redacts field would break. (#8457)
  • Don't attempt to respond to some requests if the client has already disconnected. (#8465)
  • Fix message duplication if something goes wrong after persisting the event. (#8476)
  • Fix incremental sync returning an incorrect prev_batch token in timeline section, which when used to paginate returned events that were included in the incremental sync. Broken since v0.16.0. (#8486)
  • Expose the uk.half-shot.msc2778.login.application_service to clients from the login API. This feature was added in v1.21.0, but was not exposed as a potential login flow. (#8504)
  • Fix error code for /profile/{userId}/displayname to be M_BAD_JSON. (#8517)
  • Fix a bug introduced in v1.7.0 that could cause Synapse to insert values from non-state m.room.retention events into the room_retention database table. (#8527)
  • Fix not sending events over federation when using sharded event writers. (#8536)
  • Fix a long standing bug where email notifications for encrypted messages were blank. (#8545)
  • Fix increase in the number of There was no active span... errors logged when using OpenTracing. (#8567)
  • Fix a bug that prevented errors encountered during execution of the synapse_port_db from being correctly printed. (#8585)
  • Fix appservice transactions to only include a maximum of 100 persistent and 100 ephemeral events. (#8606)

Updates to the Docker image

  • Added multi-arch support (arm64,arm/v7) for the docker images. Contributed by @maquis196. (#7921)
  • Add support for passing commandline args to the synapse process. Contributed by @samuel-p. (#8390)

Improved Documentation

  • Update the directions for using the manhole with coroutines. (#8462)
  • Improve readme by adding new shield.io badges. (#8493)
  • Added note about docker in manhole.md regarding which ip address to bind to. Contributed by @Maquis196. (#8526)
  • Document the new behaviour of the allowed_lifetime_min and allowed_lifetime_max settings in the room retention configuration. (#8529)

Deprecations and Removals

  • Drop unused device_max_stream_id table. (#8589)

Internal Changes

  • Check for unreachable code with mypy. (#8432)
  • Add unit test for event persister sharding. (#8433)
  • Allow events to be sent to clients sooner when using sharded event persisters. (#8439, #8488, #8496, #8499)
  • Configure public_baseurl when using demo scripts. (#8443)
  • Add SQL logging on queries that happen during startup. (#8448)
  • Speed up unit tests when using PostgreSQL. (#8450)
  • Remove redundant database loads of stream_ordering for events we already have. (#8452)
  • Reduce inconsistencies between codepaths for membership and non-membership events. (#8463)
  • Combine SpamCheckerApi with the more generic ModuleApi. (#8464)
  • Additional testing for ThirdPartyEventRules. (#8468)
  • Add -d option to ./scripts-dev/lint.sh to lint files that have changed since the last git commit. (#8472)
  • Unblacklist some sytests. (#8474)
  • Include the log level in the phone home stats. (#8477)
  • Remove outdated sphinx documentation, scripts and configuration. (#8480)
  • Clarify error message when plugin config parsers raise an error. (#8492)
  • Remove the deprecated Handlers object. (#8494)
  • Fix a threadsafety bug in unit tests. (#8497)
  • Add user agent to user_daily_visits table. (#8503)
  • Add type hints to various parts of the code base. (#8407, #8505, #8507, #8547, #8562, #8609)
  • Remove unused code from the test framework. (#8514)
  • Apply some internal fixes to the HomeServer class to make its code more idiomatic and statically-verifiable. (#8515)
  • Factor out common code between RoomMemberHandler._locally_reject_invite and EventCreationHandler.create_event. (#8537)
  • Improve database performance by executing more queries without starting transactions. (#8542)
  • Rename Cache to DeferredCache, to better reflect its purpose. (#8548)
  • Move metric registration code down into LruCache. (#8561, #8591)
  • Replace DeferredCache with the lighter-weight LruCache where possible. (#8563)
  • Add virtualenv-generated folders to .gitignore. (#8566)
  • Add get_immediate method to DeferredCache. (#8568)
  • Fix mypy not properly checking across the codebase, additionally, fix a typing assertion error in handlers/auth.py. (#8569)
  • Fix synmark benchmark runner. (#8571)
  • Modify DeferredCache.get() to return Deferreds instead of ObservableDeferreds. (#8572)
  • Adjust a protocol-type definition to fit sqlite3 assertions. (#8577)
  • Support macOS on the synmark benchmark runner. (#8578)
  • Update mypy static type checker to 0.790. (#8583, #8600)
  • Re-organize the structured logging code to separate the TCP transport handling from the JSON formatting. (#8587)
  • Remove extraneous unittest logging decorators from unit tests. (#8592)
  • Minor optimisations in caching code. (#8593, #8594)

Dendrite 0.2.0 released

20.10.2020 19:35 — Releases Matthew Hodgson

Hi all,

It's been over a week since our next-generation homeserver Dendrite entered beta, and it's been a wild rollercoaster ride as the team has been frantically zapping all the initial teething issues that came up - mostly around room federation getting 'stuck' due to needing to fix bugs in how room state is managed. Huge huge thanks to everyone who has spun up a Dendrite to experiment and report bugs!

We're now in an impressively better place, and it's feeling way more stable now (but please don't trust it with your data yet). So we've skipped 0.1.x and jumped straight to 0.2.0.

Now would be a great time for more intrepid explorers to try spinning up a server from https://github.com/matrix-org/dendrite and see how it feels - the more feedback the better. And if you got scared off by weird bugs in 0.1.0, now's the right time to try it again!

Full changelog follows:

Dendrite 0.2.0 (2020-10-20)

Important

  • This release makes breaking changes for polylith deployments, since they now use the multi-personality binary rather than separate binary files
    • Users of polylith deployments should revise their setups to use the new binary - see the Features section below
  • This release also makes breaking changes for Docker deployments, as are now publishing images to Docker Hub in separate repositories for monolith and polylith
    • New repositories are as follows: matrixdotorg/dendrite-monolith and matrixdotorg/dendrite-polylith
    • The new latest tag will be updated with the latest release, and new versioned tags, e.g. v0.2.0, will preserve specific release versions
    • Sample Compose configs have been updated - if you are running a Docker deployment, please review the changes
    • Images for the client API proxy and federation API proxy are no longer provided as they are unsupported - please use nginx (or another reverse proxy) instead

Features

  • Dendrite polylith deployments now use a special multi-personality binary, rather than separate binaries
    • This is cleaner, builds faster and simplifies deployment
    • The first command line argument states the component to run, e.g. ./dendrite-polylith-multi roomserver
  • Database migrations are now run at startup
  • Invalid UTF-8 in requests is now rejected (contributed by Pestdoktor)
  • Fully read markers are now implemented in the client API (contributed by Lesterpig)
  • Missing auth events are now retrieved from other servers in the room, rather than just the event origin
  • m.room.create events are now validated properly when processing a /send_join response
  • The roomserver now implements KindOld for handling historic events without them becoming forward extremity candidates, i.e. for backfilled or missing events

Fixes

  • State resolution v2 performance has been improved dramatically when dealing with large state sets
  • The roomserver no longer processes outlier events if they are already known
  • A SQLite locking issue in the previous events updater has been fixed
  • The client API /state endpoint now correctly returns state after the leave event, if the user has left the room
  • The client API /createRoom endpoint now sends cumulative state to the roomserver for the initial room events
  • The federation API /send endpoint now correctly requests the entire room state from the roomserver when needed
  • Some internal HTTP API paths have been fixed in the user API (contributed by S7evinK)
  • A race condition in the rate limiting code resulting in concurrent map writes has been fixed
  • Each component now correctly starts a consumer/producer connection in monolith mode (when using Kafka)
  • State resolution is no longer run for single trusted state snapshots that have been verified before
  • A crash when rolling back the transaction in the latest events updater has been fixed
  • Typing events are now ignored when the sender domain does not match the origin server
  • Duplicate redaction entries no longer result in database errors
  • Recursion has been removed from the code path for retrieving missing events
  • QueryMissingAuthPrevEvents now returns events that have no associated state as if they are missing
  • Signing key fetchers no longer ignore keys for the local domain, if retrieving a key that is not known in the local config
  • Federation timeouts have been adjusted so we don't give up on remote requests so quickly
  • create-account no longer relies on the device database (contributed by ThatNerdyPikachu)

Known issues

  • Old events can incorrectly appear in /sync as if they are new when retrieving missing events from federated servers, causing them to appear at the bottom of the timeline in clients
  • Memory can explode when catching up after a federation outage.

Synapse 1.21.2 released, and security advisory.

15.10.2020 17:25 — Releases Richard van der Hoff
Last update: 15.10.2020 17:16

Hi folks,

Today we have released Synapse 1.21.2, which fixes a couple of minor bugs that crept into the previous release. Full details are below.

Separately, we are advising any administrators who have not yet upgraded to Synapse 1.21.0 or later to do so as soon as possible. Previous versions of Synapse were vulnerable to a cross-site-scripting (XSS) attack; the bug was fixed in Synapse 1.21.0 with PR #8444.

The changelog for 1.21.2 is as follows:

Synapse 1.21.2 (2020-10-15)

Debian packages and Docker images have been rebuilt using the latest versions of dependency libraries, including authlib 0.15.1. Please see bugfixes below.

Bugfixes

  • Fix rare bug where sending an event would fail due to a racey assertion. (#8530)
  • An updated version of the authlib dependency is included in the Docker and Debian images to fix an issue using OpenID Connect. See #8534 for details.

Synapse 1.21.1 released

13.10.2020 00:00 — Releases Neil Johnson

Synapse 1.21.1 has landed!

Highlights of 1.21.1 include:-

  • Add experimental support for sharding event persister. (#8294, #8387, #8396, #8419)

  • Add experimental prometheus metric to track numbers of "large" rooms for state resolutiom. (#8425)

  • Add prometheus metrics to track federation delays. (#8430)

  • Fix messages not being sent over federation until an event is sent into the same room. (#8230, #8247, #8258, #8272, #8322)

We've also made some improvements to SSO and added new admin APIs.

Get the new releases from any of the usual sources mentioned at https://github.com/matrix-org/synapse/blob/master/INSTALL.md. 1.21.1 is on github here

The changelog for 1.21.1 is as follows:

Synapse 1.21.1 (2020-10-13)

This release fixes a regression in v1.21.0 that prevented debian packages from being built.

It is otherwise identical to v1.21.0.

Synapse 1.21.0 (2020-10-12)

No significant changes since v1.21.0rc3.

As noted in v1.20.0, a future release will drop support for accessing Synapse's Admin API under the /_matrix/client/* endpoint prefixes. At that point, the Admin API will only be accessible under /_synapse/admin.

Synapse 1.21.0rc3 (2020-10-08)

Bugfixes

  • Fix duplication of events on high traffic servers, caused by PostgreSQL could not serialize access due to concurrent update errors. (#8456)

Internal Changes

  • Add Groovy Gorilla to the list of distributions we build .debs for. (#8475)

Synapse 1.21.0rc2 (2020-10-02)

Features

  • Convert additional templates from inline HTML to Jinja2 templates. (#8444)

Bugfixes

  • Fix a regression in v1.21.0rc1 which broke thumbnails of remote media. (#8438)
  • Do not expose the experimental uk.half-shot.msc2778.login.application_service flow in the login API, which caused a compatibility problem with Element iOS. (#8440)
  • Fix malformed log line in new federation "catch up" logic. (#8442)
  • Fix DB query on startup for negative streams which caused long start up times. Introduced in #8374. (#8447)

Synapse 1.21.0rc1 (2020-10-01)

Features

  • Require the user to confirm that their password should be reset after clicking the email confirmation link. (#8004)
  • Add an admin API GET /_synapse/admin/v1/event_reports to read entries of table event_reports. Contributed by @dklimpel. (#8217)
  • Consolidate the SSO error template across all configuration. (#8248, #8405)
  • Add a configuration option to specify a whitelist of domains that a user can be redirected to after validating their email or phone number. (#8275, #8417)
  • Add experimental support for sharding event persister. (#8294, #8387, #8396, #8419)
  • Add the room topic and avatar to the room details admin API. (#8305)
  • Add an admin API for querying rooms where a user is a member. Contributed by @dklimpel. (#8306)
  • Add uk.half-shot.msc2778.login.application_service login type to allow appservices to login. (#8320)
  • Add a configuration option that allows existing users to log in with OpenID Connect. Contributed by @BBBSnowball and @OmmyZhang. (#8345)
  • Add prometheus metrics for replication requests. (#8406)
  • Support passing additional single sign-on parameters to the client. (#8413)
  • Add experimental reporting of metrics on expensive rooms for state-resolution. (#8420)
  • Add experimental prometheus metric to track numbers of "large" rooms for state resolutiom. (#8425)
  • Add prometheus metrics to track federation delays. (#8430)

Bugfixes

  • Fix a bug in the media repository where remote thumbnails with the same size but different crop methods would overwrite each other. Contributed by @deepbluev7. (#7124)
  • Fix inconsistent handling of non-existent push rules, and stop tracking the enabled state of removed push rules. (#7796)
  • Fix a longstanding bug when storing a media file with an empty upload_name. (#7905)
  • Fix messages not being sent over federation until an event is sent into the same room. (#8230, #8247, #8258, #8272, #8322)
  • Fix a longstanding bug where files that could not be thumbnailed would result in an Internal Server Error. (#8236, #8435)
  • Upgrade minimum version of canonicaljson to version 1.4.0, to fix an unicode encoding issue. (#8262)
  • Fix longstanding bug which could lead to incomplete database upgrades on SQLite. (#8265)
  • Fix stack overflow when stderr is redirected to the logging system, and the logging system encounters an error. (#8268)
  • Fix a bug which cause the logging system to report errors, if DEBUG was enabled and no context filter was applied. (#8278)
  • Fix edge case where push could get delayed for a user until a later event was pushed. (#8287)
  • Fix fetching malformed events from remote servers. (#8324)
  • Fix UnboundLocalError from occurring when appservices send a malformed register request. (#8329)
  • Don't send push notifications to expired user accounts. (#8353)
  • Fix a regression in v1.19.0 with reactivating users through the admin API. (#8362)
  • Fix a bug where during device registration the length of the device name wasn't limited. (#8364)
  • Include guest_access in the fields that are checked for null bytes when updating room_stats_state. Broke in v1.7.2. (#8373)
  • Fix theoretical race condition where events are not sent down /sync if the synchrotron worker is restarted without restarting other workers. (#8374)
  • Fix a bug which could cause errors in rooms with malformed membership events, on servers using sqlite. (#8385)
  • Fix "Re-starting finished log context" warning when receiving an event we already had over federation. (#8398)
  • Fix incorrect handling of timeouts on outgoing HTTP requests. (#8400)
  • Fix a regression in v1.20.0 in the synapse_port_db script regarding the ui_auth_sessions_ips table. (#8410)
  • Remove unnecessary 3PID registration check when resetting password via an email address. Bug introduced in v0.34.0rc2. (#8414)

Improved Documentation

  • Add /_synapse/client to the reverse proxy documentation. (#8227)
  • Add note to the reverse proxy settings documentation about disabling Apache's mod_security2. Contributed by Julian Fietkau (@jfietkau). (#8375)
  • Improve description of server_name config option in homserver.yaml. (#8415)

Deprecations and Removals

  • Drop support for prometheus_client older than 0.4.0. (#8426)

Internal Changes

  • Fix tests on distros which disable TLSv1.0. Contributed by @danc86. (#8208)
  • Simplify the distributor code to avoid unnecessary work. (#8216)
  • Remove the populate_stats_process_rooms_2 background job and restore functionality to populate_stats_process_rooms. (#8243)
  • Clean up type hints for PaginationConfig. (#8250, #8282)
  • Track the latest event for every destination and room for catch-up after federation outage. (#8256)
  • Fix non-user visible bug in implementation of MultiWriterIdGenerator.get_current_token_for_writer. (#8257)
  • Switch to the JSON implementation from the standard library. (#8259)
  • Add type hints to synapse.util.async_helpers. (#8260)
  • Simplify tests that mock asynchronous functions. (#8261)
  • Add type hints to StreamToken and RoomStreamToken classes. (#8279)
  • Change StreamToken.room_key to be a RoomStreamToken instance. (#8281)
  • Refactor notifier code to correctly use the max event stream position. (#8288)
  • Use slotted classes where possible. (#8296)
  • Support testing the local Synapse checkout against the Complement homeserver test suite. (#8317)
  • Update outdated usages of metaclass to python 3 syntax. (#8326)
  • Move lint-related dependencies to package-extra field, update CONTRIBUTING.md to utilise this. (#8330, #8377)
  • Use the admin_patterns helper in additional locations. (#8331)
  • Fix test logging to allow braces in log output. (#8335)
  • Remove __future__ imports related to Python 2 compatibility. (#8337)
  • Simplify super() calls to Python 3 syntax. (#8344)
  • Fix bad merge from release-v1.20.0 branch to develop. (#8354)
  • Factor out a _send_dummy_event_for_room method. (#8370)
  • Improve logging of state resolution. (#8371)
  • Add type annotations to SimpleHttpClient. (#8372)
  • Refactor ID generators to use async with syntax. (#8383)
  • Add EventStreamPosition type. (#8388)
  • Create a mechanism for marking tests "logcontext clean". (#8399)
  • A pair of tiny cleanups in the federation request code. (#8401)
  • Add checks on startup that PostgreSQL sequences are consistent with their associated tables. (#8402)
  • Do not include appservice users when calculating the total MAU for a server. (#8404)
  • Typing fixes for synapse.handlers.federation. (#8422)
  • Various refactors to simplify stream token handling. (#8423)
  • Make stream token serializing/deserializing async. (#8427)

Dendrite is entering Beta!

08.10.2020 00:00 — Releases Matthew Hodgson

Hi all,

We’re very excited to announce that Dendrite, the next-generation Matrix homeserver from the core Matrix team, is at last exiting alpha development and entering beta testing!

The path we’ve taken to get here has been quite a curious one, and it’s worth recapping to give context on why it’s taken reality a little while to catch up with the dream. :)

The Dendrite project has its roots in 2016 as Dendron: an attempt to write a next-generation homeserver in Golang rather than Python, in order to benefit from Go’s stronger typing, ease of profiling (no twisted stack-shredding via deferredInlineCallbacks), multithreading and faster GC performance. The idea for Dendron was to do a strangler pattern rewrite of Synapse - where we’d insert Dendron in front of Synapse as a load balancer, and incrementally replace Synapse’s API endpoints with ones implemented by Dendron.

However, as the project started to progress, it became clear that this was going to end up with many of Synapse’s architectural choices being baked into the project - particularly the DB schema and data flow architecture, such that the new endpoints could interoperate with the existing Python ones. We got as far as putting Dendron live on matrix.org and moving some of the login/registration APIs over to it… but then work fizzled out due to Synapse demanding more urgent attention as traffic grew on Matrix.org, combined with concerns about whether Dendron was the right approach in general.

So, towards the end of 2016 (after the rush to launch Vector Riot Element that summer), we went back to the drawing board to devise Dendrite—“Dendron done right!”—as opposed to Dendron, which in retrospect was Dendrite done wrong. ;) The new vision was:

  • Build a massively horizontally scalable architecture, such that large Matrix deployments like matrix.org and big government deployments could run smoothly without the constant scalability headaches we were seeing at the time with Synapse
  • Do so by splitting the server into well-defined microservice components, each of which could independently horizontally scale, each with its own DB (if desired)
  • Connect the components together with a set of append-only logs via Kafka or similar, easily letting components shard and maintain their databases from the logs, allowing rolling upgrades, possibly schema upgrades, and all sorts of other niceties. The logs effectively become a primary source of truth rather than putting all the onus on a massive monolithic ever-growing database

Rather than Dendron’s top-down approach, instead Dendrite started bottom-up with the very hardest bit: gomatrixserverlib, a standalone Go library implementing the state resolution algorithms and performing federation requests (such that it might also someday be used as a general purpose way to add Matrix federation support to an existing Go codebase).

Then we started building out the various components to implement the various services, starting with the roomserver (the service which models the history and state of one or more rooms in the server), then the syncserver (the service which implements the /sync API to let clients receive messages), etc. We even implemented a simplified in-memory version of Kafka named naffka—useful for glueing together the microservice components when running them all within a single binary.

Things were looking pretty positive by the summer of 2017: we had the server sending/receiving messages, federating with Synapse, and looking tantalisingly close:

We just sent the first ever synapse->dendrite federated traffic, including full dendrite media API (thumbnailing, fed, etc)!!! :D :D :D pic.twitter.com/sBcM2jMAr6

— Matrix (@matrixdotorg) June 8, 2017

However, we then hit three fairly major obstacles:

  • Matrix lost its funding
  • In the ensuing uncertainty, the two lead developers (Mjark & Kegan) went to work elsewhere
  • Meanwhile, Matrix uptake was starting to explode and Synapse was failing to scale to handle the traffic on matrix.org (and elsewhere)

At first, having formed what would become New Vector (now Element) to keep the rest of the core team hired, we pushed to see if we could get Dendrite finished fast enough to replace Synapse, with Erik & richvdh jumping over from Synapse to pick up the remaining work. However, it became clear that we urgently needed a quicker solution to address all the overloaded Synapses out there, and so they swung back to focus on improving Synapse (taking inspiration from some of the design of Dendrite - e.g. offloading endpoints onto worker processes connected via replication streams, and using OpenTracing to debug traffic as it flows over the various services).

At this point, Dendrite maintenance was in effect valiantly taken over by the community, with Brendan and later Anoa keeping the ball going in 2017, joined by APWhitehat in GSoC 2018 and cnly in GSoC 2019. The fact that Dendrite is now here today is thanks in no small part to their work to keep the project alive in its “wilderness years” between Sept 2017 and Dec 2019.

Meanwhile, it became clear that we were overdue getting Matrix itself out of beta - and the last thing we wanted to do was to split and dilute the implementation work of Matrix 1.0 over both Synapse and Dendrite - so we consciously made the decision to focus all our effort on Synapse for solving the remaining bugs and challenges.

Then, in July 2019, Matrix and Synapse exited beta, and we finally started to see light at the end of the tunnel. In October we started dusting off Dendrite again - looking to use it as a relatively simple and flexible codebase for experimenting with Peer-to-Peer Matrix, not least because being Go it can compile to WebAssembly and run clientside, and because even though Dendrite was originally built with massive deployments in mind, it turns out the elastic scaling means it can also scale down pretty small too—as a part of the iOS P2P demo, we’ve even ran full Dendrite homeservers on iPhones embedded into Element iOS! :)

In Dec 2019, we finally got to the point where Element could fund full-time dedicated development on Dendrite once again, with Neil Alexander joining the project and focusing fulltime on getting Dendrite out of alpha and getting it working for P2P and embedded usage (adding libp2p as a federation transport, and adding SQLite support) - and in Jan 2020 we got Dendrite successfully running clientside in a WASM service worker (just in time for FOSDEM!). Then, in Feb 2020, Kegan returned to the project to work fulltime on Dendrite - and the race began in earnest to get Dendrite ready for beta!

Here’s a pretty picture courtesy of GitHub to visualise the progress:

020-10-08-dendrite-contributors.png

Throughout 2020 there’s been a huge amount of stabilisation work and polish:

  • Refactoring much of Dendrite’s foundation to make the codebase more maintainable
  • Created all-new user server, key server, signing key server microservices
  • Moving some work from existing microservices (ultimately superseding the former currentstateserver, publicroomsapi and typingserver microservices altogether)
  • Developing new testing infrastructure:
    • Complement - our brand new Golang Matrix integration test harness
    • Are We Synapse Yet - an aggregator which parses sytest/complement output to compare how close Dendrite is to passing
  • All the Matrix 1.0 work - particularly state res v2 & room version support
  • Making it work with more P2P transports for all the exciting P2P experiments
  • Supporting backfill and fetching missing events
  • Fixing up SQLite support to make it work as a first class citizen (with shared storage code where we can!)
  • Supporting both sending and rejecting invites (even over federation)
  • E2E encryption support (one-time keys, device lists, send-to-device support)
  • Improved federation sender logic (resend retries, backoffs, blacklisting, metrics, resetting backoffs when receiving transactions)
  • Handling both inbound and outbound redactions
  • User interactive authentication (and implemented on various ‘sudo’ endpoints e.g. deleting devices and changing passwords)
  • Respecting server ACLs
  • Rejecting / soft-failing events properly
  • Support for database schema upgrades

... which brings us at last to the present day (Oct 2020), as we declare Dendrite sufficiently stable that we consider it ready for beta testing!

In practice, this means **Dendrite is now ready for experimentation by adventurous Matrix sysadmins. It is NOT ready for production usage yet, but we need folks to test it and help us iron out the remaining bugs! **Please do not trust it with sensitive data yet, and we don’t recommend trying to run it at scale yet as we haven’t done any serious optimisation work yet.

That said, we do provide the following guarantees:

  • We’re providing versioned releases from here on in, beginning with 0.1.0
  • We don’t expect any major breaking changes to the config or architecture before 1.0
  • Ready for early adopters to try running Dendrite without experiencing ~daily breaking churn
  • The database schema is now stable and will upgrade itself going forwards - your database should now be here to stay! (assuming we don’t hit any nasty data loss bugs during beta)

In terms of comparison with Synapse, the main things you should get excited about are:

  • Dendrite aims to provide an efficient, reliable and scalable alternative to Synapse:
    • Efficient: A small memory footprint with better baseline performance than an out-of-the-box Synapse
    • Reliable: Implements the Matrix specification as written, using the same test suite as Synapse as well as a brand new Go test suite
    • Scalable: can run on multiple machines and eventually scale to massive homeserver deployments
  • This means significantly less memory usage than Synapse (depends on joined rooms, often between 50MB - 400MB resident memory) - although we haven’t tuned this at all yet!
  • All-new database model, where every microservice instance has its own database tables, letting them scale arbitrarily wide
  • The ability to efficiently use all your available CPU cores without needing to split into separate processes, thanks to Go and our extensive use of goroutines. No more Python global interpreter lock! :)
  • Future experimental MSCs are likely to land in Dendrite before Synapse (e.g MSC2753 Peeking via /sync and MSC2444 Peeking over Federation are already being prototyped (#1370 and #1391) in Dendrite rather than Synapse!)

The provisos you should know about however are:

  • We’re not feature complete yet: sytest reports 56% CS API coverage and 77% Federation coverage. NB: these are always going to be underestimates of how much Dendrite actually performs due to how the tests are spread out, in actuality it’s likely more 70% CS, 95% Fed.
  • No read receipts, membership lazy-loading, presence, push notifications, search, event context, key backups, cross-signing. See changelog for full limitations.
  • Not battle-tested in the wild by many people (there are probably only ~10 dendrites on the open network today!) - so there’s likely to be a broad spectrum of bugs at first.
  • Clients that require more exotic features, like lazy loading, may not behave properly yet
  • Please use Postgres rather than SQLite wherever possible—it’s faster and has fewer issues regarding concurrency (some requests on SQLite Dendrites may 500 with ‘database is locked’ - though we’ve worked hard to eliminate most of these)
  • Dendrite can run in either “monolith” or “polylith” mode. In monolith, all the microservices are linked into a single binary - and we recommend running in this configuration wherever possible for now. Monolith mode is extremely capable as it is and has fewer moving parts for things to go wrong and will be the right choice for the majority of beta deployments!
  • Whilst Dendrite is nearly 100% federation compatible, there may still be situations where it will split-brain and disagree with the current room state that Synapse has calculated. We expect these issues to resolve as we get more user feedback.

Architecture-wise, this is what Dendrite looks like under the hood today:

2020-10-08-dendrite-arch.svg

To get up and running, please install Go and head on over to the Get Started guide at https://github.com/matrix-org/dendrite#get-started to join the fun :)

In terms of where we’re going next:

  • Read receipts. It’s a major missing feature and impacts UX significantly.
  • 100% Federation coverage (according to sytest). It’s crucial that Dendrite instances play nicely with other servers. This will be the best metric we have for asserting that we are just as capable as Synapse at the fed level.
  • Optimisation—Dendrite has not been optimised yet for speed or resource utilisation!
    • We plan to add benchmarks which will stress test different microservices in the presence of many different scaling factors (number of users, number of rooms, size of room, number of devices per user, number of sync requests, etc). This will hopefully allow us to identify early on bottlenecks and slow algorithms
    • Good old fashioned pprof with known slow scenarios to see what’s consuming CPU/memory and fixing issues ad-hoc (which we’ve already done a bit of pre-beta). This may involve adding additional in-memory caches, with a healthy respect for the complexities it may introduce (which Synapse has been bitten by)
  • We plan to add first class feature flag support for experimental MSCs—experimentation is one thing which makes Dendrite notably different from Synapse, and supporting it more thoroughly going forwards will be important. This may mean adding additional hooks; potentially a dedicated microservice to cleanly separate experiments, we don’t know yet
  • P2P work will continue with vigour now we have a working, featureful, and relatively stable HS to embed and play with

Longer term, it’s pretty hard to say right now when we expect to exit beta (it took Synapse 5 years to exit beta, after all ;) - but obviously we’ll need Dendrite to have parity with Synapse and have no known serious bugs.

Finally: you’re probably wondering what this means for Synapse. Synapse is here to stay - with tens of thousands of deployments around the world serving tens of millions of users. The majority of the core team is still focused on improving and optimising Synapse, and we’ll be keeping improving it for the foreseeable.

However, we’ll certainly be experimenting with new stuff on Dendrite first - whether that’s P2P, portable accounts, new-style communities, peeking etc. We expect Synapse to be the stable long-term-supported solution, while Dendrite (particularly while in beta) will be the more unstable and experimental platform. In the longer term we’ll provide ways of migrating from Synapse to Dendrite however (probably via portable accounts), and perhaps in future new deployments may choose to use Dendrite - a bit like you might choose to use nginx rather than Apache for a new web server these days. But this will be a long transition—meanwhile we expect to see more and more next-generation homeservers like Conduit, Mascarene or Construct coming of age too.

So, there you have it. If you’re an intrepid sysadmin please spin up a Dendrite and start filing bugs! :)

— Matthew, Neil Alexander, Kegan and the whole Matrix team.

Here’s the official changelog:

Client-Server API Features

Account registration and management

  • Registration: By password only.
  • Login: By password only. No fallback.
  • Logout: Yes.
  • Change password: Yes.
  • Link email/msisdn to account: No.
  • Deactivate account: Yes.
  • Check if username is available: Yes.
  • Account data: Yes.
  • OpenID: No.

Rooms

  • Room creation: Yes, including presets.
  • Joining rooms: Yes, including by alias or ?server_name=.
  • Event sending: Yes, including transaction IDs.
  • Aliases: Yes.
  • Published room directory: Yes.
  • Kicking users: Yes.
  • Banning users: Yes.
  • Inviting users: Yes, but not third-party invites.
  • Forgetting rooms: No.
  • Room versions: All (v1 - v6)
  • Tagging: Yes.

User management

  • User directory: Basic support.
  • Ignoring users: No.
  • Groups/Communities: No.

Device management

  • Creating devices: Yes.
  • Deleting devices: Yes.
  • Send-to-device messaging: Yes.

Sync

  • Filters: Timeline limit only. Rest unimplemented.
  • Deprecated /events and /initialSync: No.

Room events

  • Typing: Yes.
  • Receipts: No.
  • Read Markers: No.
  • Presence: No.
  • Content repository (attachments): Yes.
  • History visibility: No, defaults to joined.
  • Push notifications: No.
  • Event context: No.
  • Reporting content: No.

End-to-End Encryption

  • Uploading device keys: Yes.
  • Downloading device keys: Yes.
  • Claiming one-time keys: Yes.
  • Querying key changes: Yes.
  • Cross-Signing: No.

Misc

  • Server-side search: No.
  • Guest access: Partial.
  • Room previews: No, partial support for Peeking via MSC2753.
  • Third-Party networks: No.
  • Server notices: No.
  • Policy lists: No.

Federation Features

  • Querying keys (incl. notary): Yes.
  • Server ACLs: Yes.
  • Sending transactions: Yes.
  • Joining rooms: Yes.
  • Inviting to rooms: Yes, but not third-party invites.
  • Leaving rooms: Yes.
  • Content repository: Yes.
  • Backfilling / get_missing_events: Yes.
  • Retrieving state of the room (/state and /state_ids): Yes.
  • Public rooms: Yes.
  • Querying profile data: Yes.
  • Device management: Yes.
  • Send-to-Device messaging: Yes.
  • Querying/Claiming E2E Keys: Yes.
  • Typing: Yes.
  • Presence: No.
  • Receipts: No.
  • OpenID: No.

Synapse 1.20.0 released

22.09.2020 19:30 — Releases Neil Johnson

Synapse 1.20.0 is here!

Highlights of 1.20.0 include:-

  • Shadow ban support.
  • Unread message counts in the sync response to help our client developers, this is a precursor to improving notification support.
  • No less than 28 async/await PRs, so we can finally share all the hard work.

Also take note that in a future release, we will be dropping support for accessing Synapse's Admin API using the /_matrix/client/* prefixes. More details follow in the changelog.

Get the new releases from any of the usual sources mentioned at https://github.com/matrix-org/synapse/blob/master/INSTALL.md. 1.20.0 is on github here, and 1.20.0rc4 is here.

The changelog for 1.20.0 is as follows:

Synapse 1.20.0 (2020-09-22)

No significant changes since v1.20.0rc5.

Removal warning

Historically, the Synapse Admin API has been accessible under the /_matrix/client/api/v1/admin, /_matrix/client/unstable/admin, /_matrix/client/r0/admin and /_synapse/admin prefixes. In a future release, we will be dropping support for accessing Synapse's Admin API using the /_matrix/client/* prefixes. This makes it easier for homeserver admins to lock down external access to the Admin API endpoints.

Synapse 1.20.0rc5 (2020-09-18)

In addition to the below, Synapse 1.20.0rc5 also includes the bug fix that was included in 1.19.3.

Features

  • Add flags to the /versions endpoint for whether new rooms default to using E2EE. (#8343)

Bugfixes

  • Fix rate limiting of federation /send requests. (#8342)
  • Fix a longstanding bug where back pagination over federation could get stuck if it failed to handle a received event. (#8349)

Internal Changes

  • Blacklist MSC2753 SyTests until it is implemented. (#8285)

Synapse 1.20.0rc4 (2020-09-16)

Synapse 1.20.0rc4 is identical to 1.20.0rc3, with the addition of the security fix that was included in 1.19.2.

Synapse 1.20.0rc3 (2020-09-11)

Bugfixes

  • Fix a bug introduced in v1.20.0rc1 where the wrong exception was raised when invalid JSON data is encountered. (#8291)

Synapse 1.20.0rc2 (2020-09-09)

Bugfixes

  • Fix a bug introduced in v1.20.0rc1 causing some features related to notifications to misbehave following the implementation of unread counts. (#8280)

Synapse 1.20.0rc1 (2020-09-08)

Removal warning

Some older clients used a disallowed character (:) in the client_secret parameter of various endpoints. The incorrect behaviour was allowed for backwards compatibility, but is now being removed from Synapse as most users have updated their client. Further context can be found at #6766.

Features

  • Add an endpoint to query your shared rooms with another user as an implementation of MSC2666. (#7785)
  • Iteratively encode JSON to avoid blocking the reactor. (#8013, #8116)
  • Add support for shadow-banning users (ignoring any message send requests). (#8034, #8092, #8095, #8142, #8152, #8157, #8158, #8176)
  • Use the default template file when its equivalent is not found in a custom template directory. (#8037, #8107, #8252)
  • Add unread messages count to sync responses, as specified in MSC2654. (#8059, #8254, #8270, #8274)
  • Optimise /federation/v1/user/devices/ API by only returning devices with encryption keys. (#8198)

Bugfixes

  • Fix a memory leak by limiting the length of time that messages will be queued for a remote server that has been unreachable. (#7864)
  • Fix Re-starting finished log context PUT-nnnn warning when event persistence failed. (#8081)
  • Synapse now correctly enforces the valid characters in the client_secret parameter used in various endpoints. (#8101)
  • Fix a bug introduced in v1.7.2 impacting message retention policies that would allow federated homeservers to dictate a retention period that's lower than the configured minimum allowed duration in the configuration file. (#8104)
  • Fix a long-standing bug where invalid JSON would be accepted by Synapse. (#8106)
  • Fix a bug introduced in Synapse v1.12.0 which could cause /sync requests to fail with a 404 if you had a very old outstanding room invite. (#8110)
  • Return a proper error code when the rooms of an invalid group are requested. (#8129)
  • Fix a bug which could cause a leaked postgres connection if synapse was set to daemonize. (#8131)
  • Clarify the error code if a user tries to register with a numeric ID. This bug was introduced in v1.15.0. (#8135)
  • Fix a bug where appservices with ratelimiting disabled would still be ratelimited when joining rooms. This bug was introduced in v1.19.0. (#8139)
  • Fix logging in via OpenID Connect with a provider that uses integer user IDs. (#8190)
  • Fix a longstanding bug where user directory updates could break when unexpected profile data was included in events. (#8223)
  • Fix a longstanding bug where stats updates could break when unexpected profile data was included in events. (#8226)
  • Fix slow start times for large servers by removing a table scan of the users table from startup code. (#8271)

Updates to the Docker image

  • Fix builds of the Docker image on non-x86 platforms. (#8144)
  • Added curl for healthcheck support and readme updates for the change. Contributed by @maquis196. (#8147)

Improved Documentation

  • Link to matrix-synapse-rest-password-provider in the password provider documentation. (#8111)
  • Updated documentation to note that Synapse does not follow HTTP 308 redirects due to an upstream library not supporting them. Contributed by Ryan Cole. (#8120)
  • Explain better what GDPR-erased means when deactivating a user. (#8189)

Internal Changes

  • Add filter name to the /users admin API, which filters by user ID or displayname. Contributed by Awesome Technologies Innovationslabor GmbH. (#7377, #8163)
  • Reduce run times of some unit tests by advancing the reactor a fewer number of times. (#7757)
  • Don't fail /submit_token requests on incorrect session ID if request_token_inhibit_3pid_errors is turned on. (#7991)
  • Convert various parts of the codebase to async/await. (#8071, #8072, #8074, #8075, #8076, #8087, #8100, #8119, #8121, #8133, #8156, #8162, #8166, #8168, #8173, #8191, #8192, #8193, #8194, #8195, #8197, #8199, #8200, #8201, #8202, #8207, #8213, #8214)
  • Remove some unused database functions. (#8085)
  • Add type hints to various parts of the codebase. (#8090, #8127, #8187, #8241, #8140, #8183, #8232, #8235, #8237, #8244)
  • Return the previous stream token if a non-member event is a duplicate. (#8093, #8112)
  • Separate get_current_token into two since there are two different use cases for it. (#8113)
  • Remove ChainedIdGenerator. (#8123)
  • Reduce the amount of whitespace in JSON stored and sent in responses. (#8124)
  • Update the test federation client to handle streaming responses. (#8130)
  • Micro-optimisations to get_auth_chain_ids. (#8132)
  • Refactor StreamIdGenerator and MultiWriterIdGenerator to have the same interface. (#8161)
  • Add functions to MultiWriterIdGen used by events stream. (#8164, #8179)
  • Fix tests that were broken due to the merge of 1.19.1. (#8167)
  • Make SlavedIdTracker.advance have the same interface as MultiWriterIDGenerator. (#8171)
  • Remove unused is_guest parameter from, and add safeguard to, MessageHandler.get_room_data. (#8174, #8181)
  • Standardize the mypy configuration. (#8175)
  • Refactor some of LoginRestServlet's helper methods, and move them to AuthHandler for easier reuse. (#8182)
  • Fix wait_for_stream_position to allow multiple waiters on same stream ID. (#8196)
  • Make MultiWriterIDGenerator work for streams that use negative values. (#8203)
  • Refactor queries for device keys and cross-signatures. (#8204, #8205, #8222, #8224, #8225, #8231, #8233, #8234)
  • Fix type hints for functions decorated with @cached. (#8240)
  • Remove obsolete order field from federation send queues. (#8245)
  • Stop sub-classing from object. (#8249)
  • Add more logging to debug slow startup. (#8264)
  • Do not attempt to upgrade database schema on worker processes. (#8266, #8276)

Synapse 1.19.2 released

16.09.2020 00:00 — Releases Neil Johnson

Synapse 1.19.2 is a security patch. All federating instances should upgrade immediately.

Today we are releasing Synapse 1.19.2, which is a security patch release containing a fix to encountering invalid events over federation. We are also putting out a fourth release candidate for the upcoming Synapse 1.20.0 release with the same fix.

The bug prevents affected Synapse instances from joining rooms with invalid events. Server administrators running federating instances are strongly encouraged to update as soon as possible.

Those on Synapse 1.19.1 or earlier should upgrade to Synapse 1.19.2, while those who are running a release candidate of Synapse 1.20.0 should upgrade to 1.20.0rc4.

Get the new releases from any of the usual sources mentioned at https://github.com/matrix-org/synapse/blob/master/INSTALL.md. 1.19.2 is on github here, and 1.20.0rc4 is here.

The changelog for 1.19.2 is as follows:

Synapse 1.19.2 (2020-09-16)

Due to the issue below server admins are encouraged to upgrade as soon as possible. Bugfixes

  • Fix joining rooms over federation that include malformed events. (#8324)