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:
latesttag will be updated with the latest release, and new versioned tags, e.g.
v0.2.0, will preserve specific release versions
m.room.createevents are now validated properly when processing a
KindOldfor handling historic events without them becoming forward extremity candidates, i.e. for backfilled or missing events
/stateendpoint now correctly returns state after the leave event, if the user has left the room
/createRoomendpoint now sends cumulative state to the roomserver for the initial room events
/sendendpoint now correctly requests the entire room state from the roomserver when needed
QueryMissingAuthPrevEventsnow returns events that have no associated state as if they are missing
create-accountno longer relies on the device database (contributed by ThatNerdyPikachu)
/syncas if they are new when retrieving missing events from federated servers, causing them to appear at the bottom of the timeline in clients
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:
Debian packages and Docker images have been rebuilt using the latest versions of dependency libraries, including authlib 0.15.1. Please see bugfixes below.
Synapse 1.21.1 has landed!
Highlights of 1.21.1 include:-
Add experimental prometheus metric to track numbers of "large" rooms for state resolutiom. (#8425)
Add prometheus metrics to track federation delays. (#8430)
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:
This release fixes a regression in v1.21.0 that prevented debian packages from being built.
It is otherwise identical to v1.21.0.
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
could not serialize access due to concurrent updateerrors. (#8456)
.debs for. (#8475)
uk.half-shot.msc2778.login.application_serviceflow in the login API, which caused a compatibility problem with Element iOS. (#8440)
GET /_synapse/admin/v1/event_reportsto read entries of table
event_reports. Contributed by @dklimpel. (#8217)
uk.half-shot.msc2778.login.application_servicelogin type to allow appservices to login. (#8320)
enabledstate of removed push rules. (#7796)
canonicaljsonto version 1.4.0, to fix an unicode encoding issue. (#8262)
DEBUGwas enabled and no
contextfilter was applied. (#8278)
UnboundLocalErrorfrom occuring when appservices send a malformed register request. (#8329)
guest_accessin the fields that are checked for null bytes when updating
room_stats_state. Broke in v1.7.2. (#8373)
/syncif the synchrotron worker is restarted without restarting other workers. (#8374)
synapse_port_dbscript regarding the
/_synapse/clientto the reverse proxy documentation. (#8227)
server_nameconfig option in
prometheus_clientolder than 0.4.0. (#8426)
populate_stats_process_rooms_2background job and restore functionality to
PaginationConfig. (#8250, #8282)
StreamToken.room_keyto be a
metaclassto python 3 syntax. (#8326)
admin_patternshelper in additional locations. (#8331)
__future__imports related to Python 2 compatibility. (#8337)
super()calls to Python 3 syntax. (#8344)
async withsyntax. (#8383)
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:
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:
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:
Throughout 2020 there’s been a huge amount of stabilisation work and polish:
... 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:
In terms of comparison with Synapse, the main things you should get excited about are:
The provisos you should know about however are:
Architecture-wise, this is what Dendrite looks like under the hood today:
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:
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:
Synapse 1.20.0 is here!
Highlights of 1.20.0 include:-
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:
No significant changes since v1.20.0rc5.
Historically, the Synapse Admin API has been accessible under the
/_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.
In addition to the below, Synapse 1.20.0rc5 also includes the bug fix that was included in 1.19.3.
/versionsendpoint for whether new rooms default to using E2EE. (#8343)
Synapse 1.20.0rc4 is identical to 1.20.0rc3, with the addition of the security fix that was included in 1.19.2.
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.
/federation/v1/user/devices/API by only returning devices with encryption keys. (#8198)
Re-starting finished log context PUT-nnnnwarning when event persistence failed. (#8081)
client_secretparameter used in various endpoints. (#8101)
/syncrequests to fail with a 404 if you had a very old outstanding room invite. (#8110)
userstable from startup code. (#8271)
HTTP 308redirects due to an upstream library not supporting them. Contributed by Ryan Cole. (#8120)
/usersadmin API, which filters by user ID or displayname. Contributed by Awesome Technologies Innovationslabor GmbH. (#7377, #8163)
/submit_tokenrequests on incorrect session ID if
request_token_inhibit_3pid_errorsis turned on. (#7991)
get_current_tokeninto two since there are two different use cases for it. (#8113)
MultiWriterIdGeneratorto have the same interface. (#8161)
MultiWriterIdGenused by events stream. (#8164, #8179)
SlavedIdTracker.advancehave the same interface as
is_guestparameter from, and add safeguard to,
MessageHandler.get_room_data. (#8174, #8181)
LoginRestServlet's helper methods, and move them to
AuthHandlerfor easier reuse. (#8182)
wait_for_stream_positionto allow multiple waiters on same stream ID. (#8196)
MultiWriterIDGeneratorwork for streams that use negative values. (#8203)
orderfield from federation send queues. (#8245)
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:
Due to the issue below server admins are encouraged to upgrade as soon as possible. Bugfixes