Combating abuse in Matrix - without backdoors.

2020-10-19 — General — Matthew Hodgson

Hi all,

Last Sunday, the UK Government published an international statement on end-to-end encryption and public safety, co-signed by representatives from the US, Australia, New Zealand, Canada, India and Japan. The statement is well written and well worth a read in full, but the central point is this:

We call on technology companies to [...] enable law enforcement access to content in a readable and usable format where an authorisation is lawfully issued, is necessary and proportionate, and is subject to strong safeguards and oversight.

In other words, this is an explicit request from seven of the biggest governments in the world to mandate a backdoor in end-to-end encrypted (E2EE) communication services: a backdoor to which the authorities have a secret key, letting them view communication on demand. This is big news, and is of direct relevance to Matrix as an end-to-end encrypted communication protocol whose core team is currently centred in the UK.

Now, we sympathise with the authorities’ predicament here: we utterly abhor child abuse, terrorism, fascism and similar - and we did not build Matrix to enable it. However, trying to mitigate abuse with backdoors is, unfortunately, fundamentally flawed.

Backdoors necessarily introduce a fatal weak point into encryption for everyone, which then becomes the ultimate high value target for attackers. Anyone who can determine the secret needed to break the encryption will gain full access, and you can be absolutely sure the backdoor key will leak - whether that’s via intrusion, social engineering, brute-force attacks, or accident. And even if you unilaterally trust your current government to be responsible with the keys to the backdoor, is it wise to unilaterally trust their successors? Computer security is only ever a matter of degree, and the only safe way to keep a secret like this safe is for it not to exist in the first place.
End-to-end encryption is nowadays a completely ubiquitous technology; an attempt to legislate against it is like trying to turn back the tide or declare a branch of mathematics illegal. Even if Matrix did compromise its encryption, users could easily use any number of other approaches to additionally secure their conversations - from PGP, to OTR, to using one-time pads, to sharing content in password-protected ZIP files. Or they could just switch to a E2EE chat system operating from a jurisdiction without backdoors.
Governments protect their own data using end-to-end encryption, precisely because they do not want other governments being able to snoop on them. So not only is it hypocritical for governments to argue for backdoors, it immediately puts their own governmental data at risk of being compromised. Moreover, creating infrastructure for backdoors sets an incredibly bad precedent to the rest of the world - where less salubrious governments will inevitably use the same technology to the massive detriment of their citizens’ human rights.
Finally, in Matrix’s specific case: Matrix is an encrypted decentralised open network powered by open source software, where anyone can run a server. Even if the Matrix core team were obligated to add a backdoor, this would be visible to the wider world - and there would be no way to make the wider network adopt it. It would just damage the credibility of the core team, push encryption development to other countries, and the wider network would move on irrespectively.

In short, we need to keep E2EE as it is so that it benefits the 99.9% of people who are good actors. If we enforce backdoors and undermine it, then the bad 0.1% percent simply will switch to non-backdoored systems while the 99.9% are left vulnerable.

We’re not alone in thinking this either: the GDPR (the world-leading regulation towards data protection and privacy) explicitly calls out robust encryption as a necessary information security measure. In fact, the risk of US governmental backdoors explicitly caused the European of Court of Justice to invalidate the Privacy Shield for EU->US data. The position of the seven governments here (alongside recent communications by the EU commissioner on the ‘problem’ of encryption) is a significant step back on the protection of the fundamental right of privacy.

So, how do we solve this predicament for Matrix?

Thankfully: there is another way.

This statement from the seven governments aims to protect the general public from bad actors, but it clearly undermines the good ones. What we really need is something that empowers users and administrators to identify and protect themselves from bad actors, without undermining privacy.

What if we had a standard way to let users themselves build up and share their own views of whether other users, messages, rooms, servers etc. are obnoxious or not? What if you could visualise and choose which filters to apply to your view of Matrix?

Just like the Web, Email or the Internet as a whole, there is literally no way to unilaterally censor or block content in Matrix. But what we can do is provide first-class infrastructure to let users (and room/community moderators and server admins) make up their own mind about who to trust, and what content to allow. This would also provide a means for authorities to publish reputation data about illegal content, providing a privacy-respecting mechanism that admins/mods/users can use to keep illegal content away from their servers/clients.

The model we currently have in mind is:

Anyone can gather reputation data about Matrix rooms / users / servers / communities / content, and publish it to as wide or narrow an audience as they like - providing their subjective score on whether something in Matrix is positive or negative in a given context.
This reputation data is published in a privacy preserving fashion - i.e. you can look up reputation data if you know the ID being queried, but the data is stored pseudonymised (e.g. indexed by a hashed ID).
Anyone can subscribe to reputation feeds and blend them together in order to inform how they filter their content. The feeds might be their own data, or from their friends, or from trusted sources (e.g. a fact-checking company). Their blended feed can be republished as their own.
To prevent users getting trapped in a factional filter bubble of their own devising, we’ll provide UI to visualise and warn about the extent of their filtering - and make it easy and fun to shift their viewpoint as needed.
Admins running servers in particular jurisdictions then have the option to enforce whatever rules they need on their servers (e.g. they might want to subscribe to reputation feeds from a trusted source such as the IWF, identifying child sexual abuse content, and use it to block it from their server).
This isn’t just about combating abuse - but the same system can also be used to empower users to filter out spam, propaganda, unwanted NSFW content, etc on their own terms.

This forms a relative reputation system. As uncomfortable as it may be, one man’s terrorist is another man’s freedom fighter, and different jurisdictions have different laws - and it’s not up to the Matrix.org Foundation to play God and adjudicate. Each user/moderator/admin should be free to make up their own mind and decide which reputation feeds to align themselves with. That is not to say that this system would help users locate extreme content - the privacy-preserving nature of the reputation data means that it’s only useful to filter out material which would otherwise already be visible to you - not to locate new content.

In terms of how this interacts with end-to-end-encryption and mitigating abuse: the reality is that the vast majority of abuse in public networks like Matrix, the Web or Email is visible from the public unencrypted domain. Abusive communities generally want to attract/recruit/groom users - and that means providing a public front door, which would be flagged by a reputation system such as the one proposed above. Meanwhile, communities which are entirely private and entirely encrypted typically still have touch-points with the rest of the world - and even then, the chances are extremely high that they will avoid any hypothetical backdoored servers. In short, investigating such communities requires traditional infiltration and surveillance by the authorities rather than an ineffective backdoor.

Now, this approach may sound completely sci-fi and implausibly overambitious (our speciality!) - but we’ve actually started successfully building this already, having been refining the idea over the last few years. MSC2313 is a first cut at the idea of publishing and subscribing to reputation data - starting off with simple binary ban rules. It’s been implemented and in production for over a year now, and is used to maintain shared banlists used by both matrix.org and mozilla.org communities. The next step is to expand this to support a blendable continuum of reputation data (rather than just binary banlists), make it privacy preserving, and get working on the client UX for configuring and visualising them.

Finally: we are continuing to hire a dedicated Reputation Team to work full time on building this. This is a major investment in the future of Matrix, and frankly is burning money that we don’t really have - but it’s critical to the long-term success of the project, and perhaps the health of the Internet as a whole. There’s nothing about a good relative reputation system which is particularly specific to Matrix, after all, and many other folks (decentralised and otherwise) are clearly in desperate need of one too. We are actively looking for funding to support this work, so if you’re feeling rich and philanthropic (or a government wanting to support a more enlightened approach) we would love to hear from you at [email protected]!

Here’s to a world where users have excellent tools to protect themselves online - and a world where their safety is not compromised by encryption backdoors.

-- The Matrix.org Core Team

Comments at HN

This Week in Matrix 2020-10-16

2020-10-16 — This Week in Matrix — Ben Parsons

Matrix Live 🎙

In which I chat with Kitsune about the work done to get a Matrix URI schema agreed, and the state of the work.

See also, Open Tech Will Save Us #7 took place this week! Go watch.

Dept of Status of Matrix 🌡️

Meta-counting

As a crude measure of growth, Matthew commented about #twim:matrix.org:

I love that this room has ~700 people in it, spread over ~350 servers :D

That is something to love. Come join us in the room to share your news and see what's new from others.

Elokapina (Extinction Rebellion Finland) migrates to Matrix

kapina-jaywink told us:

In recent weeks the XR Finland community has been moving over from Wire to our own Matrix homeserver for encrypted secure chat. This was something that had been planned for a while but kicked off in recent weeks due to Wire suffering from serious encryption key delivery issues, causing messages for many to be unreadable in large groups. Currently we've migrated almost 300 rebels with more to come. Feedback has mostly been very positive, people generally like the Element clients 🤩 One of the interesting changes has been a huge uptick in the amount of discussion, which can be taken as a good sign. The plan is to next start bridging to some of the international XR chapters, for example those on Mattermost, Telegram and Slack. And maybe get them over to Matrix too eventually ;)
To aid in community management, we've started creating a bot called Bubo. Right now it mostly helps with maintaining rooms and allowing mass invites, but more features to help the community cooperate are coming. We were planning to utilize (actual) communities so it has some functionality for those, but decided then to wait for the communities rewrite. It doesn't yet have any releases, will update in coming weeks as features are added and releases made.

kapina-jaywink also

wants to clarify that XR is a decentralized movement and this does not mean other chapters will adapt Matrix - but we can hope and for sure here in Finland we'll be spreading the good experiences to other chapters ;)

Dept of Spec 📜

New Spec Website!

wbamberg told us:

We're working on a new platform for the specification docs, aimed initially at improving navigation and general usability.
The initial demo site is at https://adoring-einstein-5ea514.netlify.app/spec/ and the main tracking bug is at https://github.com/matrix-org/matrix-doc/issues/2822

Spec

anoa reported:

Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://matrix.org/docs/spec/proposals.
MSC Status
Merged MSCs:
No MSCs were merged this week.
MSCs in Final Comment Period:
No MSCs are in FCP.
New MSCs:
MSC2821: Testing Pushers
MSC2815: Proposal to allow room moderators to view redacted event content
MSC2813: Widget API error handling and validation
Spec Core Team
In terms of Spec Core Team MSC focus for this week, widgets are still the main focus: MSC2774 (widget URL template param), MSC2765 (widget avatars), and MSC2790 (modal widgets).

Dept of Servers 🏢

Dendrite / gomatrixserverlib

Dendrite is a next-generation homeserver written in Go

Neil Alexander reported:

We released our first beta last week and we've been busy taking feedback from the community and fixing problems as they have been reported to us. We will be cutting a v0.2.0 release candidate later today, which contains a significant number of important fixes and performance improvements.
We didn't publish a full changelog last week due to the beta announcement, therefore the following list includes changes from the last two weeks:
Database migrations are now ran automatically at startup
State resolution v2 performance has been improved dramatically on large state sets, seen to be running up to 20x faster in some rooms
Dendrite no longer runs state resolution over single trusted state snapshots
Monolith deployments with Kafka now work again (each component sets up connections independently to avoid duplicate consumers)
Dendrite now correctly rejects invalid UTF-8 - thanks to Lesterpig
Fully read markers are now handled - thanks to Lesterpig
The completed field is now returned properly for user-interactive auth - thanks to Lesterpig
The devices table now tracks last seen timestamps, IPs and user agents - thanks to S7evinK
A bug has been fixed in the reverse topological ordering algorithm which resulted in us giving up on inbound references after the first prev/auth event
A bug with concurrent map writes in the rate limiting in the client API has been fixed
Forward extremities and their previous events are now checked fully against the database
Typing events are now ignored if the sender domain doesn't match the origin
Duplicate redaction entries no longer result in database errors
Some bugs in /send have been fixed where the full room state wasn't requested properly before sending a new snapshot to the roomserver
The membership updaters now use database writers properly, which fixes some SQLite locking issues
The sync API no longer burns CPU processing unnecessary device key change notifications
QueryStateAfterEvents now resolves state from multiple snapshots properly
Cumulative room state is now sent to the roomserver when creating rooms locally
Missing auth events will now be retrieved from multiple servers in the room if necessary
Federation requests now have variable timeouts, allowing us to wait much longer for a remote server to process certain tasks
The /send endpoint now returns 500 errors far less often, reducing the frequency that other servers back off from sending to Dendrite
Backfill no longer uses the request context for persisting events, which was resulting in us failing to store those events sometimes
Invite stripped state from the sync API now includes the stripped invite itself, so that Element Web can display who sent the invite properly
The signing key fetch mechanism no longer gives up if it is unable to fetch specific keys
Handling of invalid display name or avatar URLs in membership events has been improved
Spec compliance has improved a little:
Client-server APIs: 56%, same as last week
Server-server APIs: 80%, up from 79% last week
As always, please feel free to join us in #dendrite:matrix.org for general Dendrite chat, and #dendrite-dev:matrix.org if you are interested in contributing!

Good grief that's a big update! For a video discussion of the status and future of Dendrite, check out Open Tech Will Save Us #7.

Matthew added:

my personal dendrite is now in roughly the same set of rooms as my personal synapse. Dendrite is idling at 180MB of RAM, Synapse is idling at 1.8GB of RAM :)

Conduit

Timo:

Hello everyone, this week we merged the federation branch into master. It's not ready to be used properly yet, but we're merging it as it seems stable enough for now. We also improved performance of the federation branch a lot by turning off debug logs.
Other news:
I opened two issues on element-ios which currently break register and login support on Conduit, making it completely unusable. Hopefully they can be resolved soon (https://github.com/vector-im/element-ios/issues/3736, https://github.com/vector-im/element-ios/issues/3737)
I'm working on an MSC for threading. It's still WIP, but you can take a look here: https://demo.codimd.org/s/SykbuAUwP
Thanks to everyone who supports me on Liberapay or Bitcoin!

Synapse

Neil offered:

Stonking week for Synapse as we landed sharded event persisters and deployed to matrix.org. This is the last significant component other than the main process to go through the sharding process and a major hurdle in horizontal scalability of Synapse.
Initial results look good with event persistence apdex improving, however we think there are still some significant performance improvements available through configuration and will continue to experiment.

2020-10-16-I-Plk-Screenshot2020-10-16at17.23.31.png

We also moved off background processes from the main process. This is significant because it means that while the main process is not shardable it really doesn’t do anything anymore other than orchestration.
Again the initial impact looks very promising and we will continue to tune. Having moved the background processes away it also makes profiling the main process that much easier.

Aside from all of that we continue to progress room knocking put out a 1.21.2 - a bug fix release though please please ensure you are running at least Synapse >= 1.21.0 since 1.21.0 contains a XSS security fix.
Next week we will carrying on tuning matrix.org and start to look at improving state resolution performance.

Synapse Deployment 📥️

Kubernetes

Ananace told us:

Just pushed the updated image tags and chart version for my K8s-optimized Synapse image for version 1.21.0, as well as a chart update for element-web 1.7.9

then later

And to expand on my previous update, got Synapse 1.21.2 up on the chart and K8s-optimized image.

YunoHost

Pierre said:

YunoHost is an operating system aiming for the simplest administration of a server, and therefore democratize self-hosting.
Synapse integration had been updated to 1.20.1 (1.21.0 available in branch testing)
Element Web integration had been updated to 1.7.8 (1.7.9 available in branch testing)

Dept of Bridges 🌉

Bridges increase their presence

Half-Shot told us:

Small bit of news I wanted to talk about from Bridge Island. My implementation for MSC2409 has been merged which means appservices / bridges can now listen in for incoming presence, typing and read receipt events! This means that the Slack bridge can now reliably send your typing status to Slack, and Bifrost can reliably bridge your everything to XMPP. The MSC is still in flux and could change, but for now this could really improve the native feeling of bridges :)
(Oh and I should mention anyone using matrix-appservice-bridge v2.2.0+ can use this behaviour for free)

mautrix-python implements Half-Shot's new features

Hot on his heels, Tulir announced:

I've been adding support for the MSCs Half-Shot implemented in Synapse to my bridges:
Enabling end-to-bridge encryption now uses appservice login (MSC2778), which means setting up the shared secret login module is no longer required for e2be.
mautrix-python has support for receiving ephemeral events via MSC2409 in a branch, which will be merged once Synapse v1.22 is released. After it's merged, /syncing with double puppets will no longer be necessary to bridge ephemeral events.
Both of these will also be implemented in mautrix-go/whatsapp soon.
Now I just need Half-Shot to make synapse send to-device events to appservices, after which bridges won't need any hacky /syncing at all.

Dept of Clients 📱

Hydrogen

Bruno offered:

Several releases this week (0.1.11 to 0.1.15) with lots of changes:
url-based navigation has landed! All navigation in the app is now done through urls, meaning you can also bookmark any UI state (e.g. grid configurations).
fixed 2 memory leaks (exposed now because you can unload your session without refreshing the page)
fixed an issue with libolm running out of memory if you send a message to more than 44 devices (see issue #150).
some logical additions now we have url navigation: restoring the last url when opening the app with the default route, and a button to close your session and go back to the picker.
the app now blocks concurrent access to the same session from different tabs (it just closes the session in the non-active tab). This will prevent multiple syncs tripping over each other writing to indexeddb (e.g. ConstraintErrors and friends).
updates are announced in the app (for now through a confirm dialog, but will use an in app notification once we have it)
fixes updates not installing on iOS, by having an update prompt. To get this update on iOS though, you'll need to unpin the app, and pinning it again. You'll need to login again after this. All future updates should be installable through the update prompt once you have 0.1.15 though, you won't have to do this again normally.
uses the hydrogen icon when pinning on iOS

I really recommend hitting https://hydrogen.element.io/ - what great progress!

Element Android

benoit reported:

We are currently preparing the release of the version 1.0.9 of Element Android, which contain searching messages in clear rooms and a lots of other improvements and new features.
The SDK 1.0.9 will also be released, with an updated readme, and a brand new sample app, written by Ganfra. It will help developers to start using the new SDK and can be found here: https://github.com/matrix-org/matrix-android-sdk2-sample. This sample app is able to let the user connects to an existing account on any homeserver with password login, display the room list, display a room timeline and send message to a room. a brand new sample app

YES! This is the best documentation

Element-iOS

Manu offered:

This week, we released 1.0.16 on the App Store (and TestFlight).

Konheko (Sailfish client)

Nico (@deepbluev7:neko.dev) offered:

I published the first preview of my Sailfish client called Konheko. While you can run Android applications on Sailfish, they usually are a subpar experience, since they really don't fit the platforms design and style and also usually don't properly send notifications.
So about a year ago I started working on a Matrix client for SailfishOS, but I never really made much progress. Well, last weekend I did, and so it can now send plain text messages as well as various forms of media messages, I made a basic application icon and I've been using it this week already (for unencrypted rooms).
It is still missing a lot of features, but if you want you can install it from OpenRepos. Sources are available here. Just be aware, that it currently stores all messages in RAM, so every restart will take forever to load your rooms and it may run out of RAM at some point. Storing messages in some database will come at some point. Also, a lot of menus may lead nowhere, since those are just placeholders for me atm.

SchildiChat Web/Desktop

SpiritCroc announced:

Recently, I tweaked Element-web to feature a few changes similar to SchildiChat for Android.
For now, it's probably best seen rather as a proof-of-concept than a finished product, as there are still some layout bugs, and no settings available for the added features (I know some people prefer separate lists for direct and group chats). I consider it usable though.
Particular changes compared to upstream Element-web include:
A common section for groups and direct chats in the overview
Message bubbles
Bigger items in the room overview
A different dark theme, similar to SchildiChat for Android
I don't know how much I will work on this in the future, but I figured it might be interesting to share either way. Maybe even someone with more web-development skills than me might want to help improving it :)
For further discussion, I have created #schildichat-web:matrix.org .
The current version of SchildiChat-Deskop is available for Desktop here, and I host the web variant here. If you want to build it yourself, check out this repo.

Element Web

Neil offered:

Element 1.7.9 has landed, highlights include
Many small fixes with edits and replies
Fixed a race during cross-signing key upload at registration time
Clarified when you have unsaved changes in profile settings
Aside from that has been pushing on with the widgets project. A picture says a thousand words, so here you go.

As you can see T3chguy was really pleased to have me interrupt him to take this picture. Expect the new design to merge next week.
Finally we will most likely ship a new release next week to fix some Jitsi bugs.

Dept of Ops 🛠

Wake-on-LAN bot

JCG announced:

I wrote a Wake-on-LAN bot to wake up hosts by sending a matrix message. It is configurable with multiple hosts and has a list of users per host who are allowed to wake it up. It's using the matrix-rust-sdk, source is available over at https://git.jcg.re/jcgruenhage/matrix-wol, and if anyone has questions, feel free to join #matrix-wol:jcg.re.

When I asked what this is used for:

I have stuff on my workstation that I need access to most of the time, but keeping it running uses too much power (but I did it anyway so far), this is so that I can suspend it when I leave but can still power it on when I need something from there on the got

Dept of Events and Talks 🗣️

Talking about Bridges and Bots in Matrix (German)

Oleg announced:

I was invited to the German Podcast MacMittwoch (no, it's not only about Macs) to talk about Bridges and Bots in Matrix. It was a very interesting and funny round.
Here is the recording:
https://macmittwoch.de/podcast/matrix_mit_bridges_und_bots

Dept of Interesting Projects 🛰️

matrix-emoji-upload

mewmew offered:

This is a script I've created for use with MSC2545. It allows easy uploading of emoji packs to Matrix rooms. Feel free to check it out on Gitea, or join the project room #matrix-emoji-upload:blob.cat if you have any questions/comments/issues.

n8n.io support

Matthew announced:

n8n.io (FOSS extendable workflow automation) just added Matrix support! https://n8n.io/integrations/n8n-nodes-base.matrix and https://github.com/n8n-io/n8n/pull/1046

Exciting! Yet the saga that followed only adds to the excitement!

First Oleg noticed a problem:

Could it be that only matrix.org as HS currently is supported?
I'm getting Matrix credentials are not valid! and I see the request to matrix.org on a traffic capture.

jaywink discovered the alarming truth:

the original PR mentions mantrixorg indeed: https://github.com/n8n-io/n8n/pull/1024 .. sounds like PR time for someone :)

Tulir, like a coiled spring, provided a PR:

well now it's a pull request https://github.com/n8n-io/n8n/pull/1065

...

oh nice it got merged already

Faelar noticed:

For those not following on github, n8n released a new version including the fix for homeserver

Oleg, who brings us back to the start said:

Just tested it.
It works! 🥳

Open Source!

Dept of Ping 🏓

Here we reveal, rank, and applaud the homeservers with the lowest ping, as measured by pingbot, a maubot that you can host on your own server. Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	imninja.net	466.5
2	midov.pl	531
3	mdpnd.ch	540
4	chatcloud.net	569
5	elcyb.org	801
6	fab.network	967
7	conduit.rs	1168
8	envs.net	1863.5
9	blob.cat	2660
10	aragon.sh	2743.5

That's all I know 🏁

See you next week, and be sure to stop by #twim:matrix.org with your updates!

Synapse 1.21.2 released, and security advisory.

2020-10-15 — Releases, Security — Richard van der Hoff

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

2020-10-13 — 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 occuring 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)

This Week in Matrix 2020-10-09

2020-10-09 — This Week in Matrix — Ben Parsons

Matrix Live 🎙

Dept of Status of Matrix 🌡️

Matrix in use at IETF and TeamSpeak

Matthew said:

IETF is trialling Matrix as a replacement to Slack and a complement to XMPP: https://mailarchive.ietf.org/arch/msg/tools-discuss/cUd9P35cj-nGsaioZ9HmMLmf1G4/

ALSO

Matthew commented:

looks like teamspeak is using Matrix (a Matrix endpoint was previously noticed at https://tschat-1.teamspeak.com/)

Nico (@deepbluev7:neko.dev) offered:

More info here: https://community.teamspeak.com/t/teamspeak-development-status-update/11419/36

Dept of Spec 📜

anoa told us:

Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://matrix.org/docs/spec/proposals
MSC Status
Merged MSCs:
MSC2788: Room version 6 as the default room version
MSC2414: Make reason and score parameters optional for reporting content
MSCs in Final Comment Period:
No MSCs are in FCP.
New MSCs:
[WIP] MSC2812: Role-based power/permissions
MSC2810: Consistent globs specification
[WIP] MSC2802: Flip The Table for Full Room Abstraction
Spec Core Team
In terms of Spec Core Team MSC focus for this week, we're going to be keeping the same three MSCs as last week, as their review is still a work in progress. As a reminder, those are MSC2774 (widget URL template parameters), MSC2765 (widget avatars), and MSC2790 (modal widgets).

Dept of Servers 🏢

Dendrite goes beta

Dendrite is a next-generation homeserver written in Go

kegan told us:

Dendrite has officially entered beta!
It aims to be an efficient, reliable and scalable alternative to Synapse.
We encourage early adopters to try it out starting with v0.1.0 in Monolith/Postgres mode.
Dendrite supports a large amount of the Matrix spec including:
All room versions
E2E encryption (but not cross-signing)
Federation
and many others!
We'll be hard at work in the coming weeks ironing out any issues that crop up as Dendrite enters the global
federation of Matrix servers. At present, Dendrite has not been optimised for memory/CPU usage, nor does it fully support sharding, so there is still much scope to improve the already impressive resource usage whilst
heading towards 100% spec compliance.
Spec compliance:
Client-Server APIs: 56%, same as last week
Server-Server APIs: 77%, same as last week

stefan announced:

I created an AUR package for dendrite. So it is easy to get it running on Arch Linux.

Conduit

Conduit is a Matrix homeserver written in Rust https://conduit.rs

timo told us:

This week I worked on a new feature: the Admin Room. This is a room that is automatically created for the first user of a new homeserver. This room will be used to send warnings to server admins in the future and can be used to control Conduit (like querying information, running cleanup, banning servers, hiding public rooms or restarting Conduit). Power levels can be used to control who in the room has access to which commands. The admin room will work over federation, so it's easy to help someone fix his server.
Other news:
Federation is now disabled by default and can be enabled in the config
Bug with typing notifications is fixed
Thanks to everyone who supports me on Liberapay or Bitcoin!

Synapse

Neil told us:

This week we put out v1.21.0rc3, which fixes a duplicate messages bug. We expect the full release to go out early next week.
After a long and sometimes painful journey we plan to run sharded event persisters on matrix.org from Monday. All being well we will start running background processes on their own worker to free up the main process. These two projects combined should noticeably improve performance of matrix.org and any large scale deployments.
Aside from that we are continuing to work on room knocking as a feature and have been considering ways to reduce load attributable to state resolution.
We will also dust off the notifications project.

Dept of Bridges 🌉

Gitter

Eric Eastwood told us:

The native Gitter <-> Matrix bridge is underway and we're working on virtual users which is the first piece to making the bridge feel native. You can see what this will look like in this ominous and exciting tweet: https://twitter.com/gitchat/status/1314252991705292800
There is also a GitLab epic you can track which breaks down some of the tasks and holds more details of what we're thinking of for the bridge.

🌈 Once more into the Bifrost

Half-Shot announced:

Asgardians rejoice, for Bifrost development resumed this week! We've worked extremely hard this week to improve general gateway performance, edge case bugs and basically plowing on with the project. A 0.2.0 release will shortly be due with the new changes, and matrix.org is already running the latest and greatest. You can checkout the project over at https://github.com/matrix-org/matrix-bifrost

Dept of Clients 📱

Fractal

Alexandre Franke reported:

Former Fractal GSoC intern Alejandro Dominguez 😎️ got his Integrate matrix-sdk (I) merge request in “Ready for review” state. That’s a +3910/-5439, 38 commits diff‼️ poljar, who is the main contributor of matrix-rust-sdk, already had a look and provided some insights, but given 😱️ the sheer size of the changeset, the moar 👀️ we can get on it the better.

fluffychat

krille offered:

FluffyChat now runs on native Linux desktop (x86).
You can download Linux tarballs from the CI and run them on any system which has sqlite3 installed (which all distros may have). If you have libolm3 installed, you can also use e2ee. Oh and by the way. Its NOT electron or any html5 stuff! Its a native Linux app. We are working on packaging solutions like snap and Flatpak. 😊

Vtx

CraftedCart offered:

I've started to make a Matrix client over the past few weeks, just as a hobby project for now, using Qt and a 'lil C++20! :D
There's not a whole lot to show right now - currently we've got password login, and a simple timeline that can show plain text or m.image thumbnails.
Source code's up at https://gitlab.com/CraftedCart/vtx

Nheko

Nheko is a desktop client using Qt, Boost.Asio and C++17. It supports E2EE (with the notable exception being device verification for now) and intends to be full featured and nice to look at

Nico (@deepbluev7:neko.dev) reported:

This week we finally cleaned up the remaining parts of Chethans GSoC work and merged it. This means Nheko now has partial support for cross-signing. You can either start the verification from another client or when viewing the profile of a user. There are a few things still missing though:
Nheko does not use the verification status at all at the moment. So while you can verify your master key and let others verify your master key, from Nhekos perspective there is not much benefit yet. You will however show up with a green checkmark in other clients.
While nheko supports verifying your own master key and after that will also let others verify your master key, it does not yet download the self and user signing keys. This means you won't be able to upload cross-signing signatures for your own devices and other users master keys yet. I'll see if I can implement in the next weeks or so (since literally only the private key download or sharing is missing).
Nheko can't bootstrap cross-signing yet. This means you need to bootstrap it from Element or another client once. That will probably take a bit until this is complete.
The UX is still WIP. Currently it shows a lot of unnecessary buttons, that are a bit confusing as well as not enough green checkmarks, so that needs some work.
Other things that happened in the mean time or are work in progress:
Decryption errors should be reduced by a bit now. This is still work in progress though. With device trust landed now, we should be able to do automatic key requests, sharing and key backup soon.
Lurkki is currently cleaning up the design of the built in video player.
manu_kamath is improving the design when showing images at the same time.
LorenDB has been updating our screenshots and working on an Esperanto translation.
trilene has been ever busy improving edge cases around the Voip support in Nheko.
So far Hacktoberfest seems to be going well with quite a few people trying to clean up some of the rougher edges in Nheko. If you are using Nheko and think some things could be better, why not try to fix it yourself? October is the perfect time for that!
Featurework of this cycle is also slowly nearing its end. Once cross-signing, voip and the new event store are stable, we plan to improve the UX a bit more as well as some other annoyances and maybe we can do a new release then! A nice and spooky Hacktober everyone!

David Mehren told us:

I just built nheko-git 0.7.2.r2021.517a126a-1 from the AUR and cross-signing works

Element Web

Neil offered:

This week we put out 1.7.9-rc.1 which is available at https://staging.element.io
Highlights include
Many small fixes with edits and replies
Fixed a race during cross-signing key upload at registration time
Clarified when you have unsaved changes in profile settings
Finally, the improved widget support is looking very exciting. Here is a design grab to give you an idea of what to expect. Note this is not a real Element screen shot, the base functionality is there, but the look and feel of the final version is subject to change.

Michael (t3chguy) added:

Element Web is currently transitioning the codebase over to TypeScript - track our progress at http://arewetsyet.bit.ovh/

Hydrogen

Bruno told us:

This week, Hydrogen gained better caching (and a little over-eager on Safari), room list filtering, a grid layout to show up to 6 rooms simultaneously (see screenshot) and work is well on its way for url-based navigation within the app.

also adding the screenshot on iOS that I didn't get in last week, showing the full range of display formats supported 🙂

The app also received some visual polish, thanks to Nad, our designer.

Element-iOS

Manu offered:

We blocked the last week release (1.0.14) because of 2 issues: Unable to decrypt errors and timeline not updating when coming from a notification.
1.0.15 fixes those issues and more. The release should be available in TF soon. Hopefully, we will be able to publish it on the App Store on Monday

Dept of VoIP 🤙

Matrix VoIP Tester

reivilibre said:

https://github.com/matrix-org/voip-tester/pull/18 (updated demo: https://test.voip.librepush.net)
This week, I have improved the scoring rubric, so that the verdict given to you by the tester more accurately reflects the likelihood of connection establishment.
I have also added more hints on what the verdicts mean.
Finally, I have added workarounds to support Chromium browsers that decided to break their WebRTC API so that they could pedantically rename ip to address. In any case, it now seems to be on par with Firefox.
The VoIP tester is now roughly 'usable' but please note that IPv6 support is totally untested (I don't have IPv6) — it is also suspected that some browsers won't try IPv6 anyway.
There are also some more features on the wish list, such as screenshot safety and extra help when things go wrong.
For discussion, feel free to join #voip-tester:librepush.net .

Dept of Encryption 🔐

Olm 🦎

uhoreg reported:

Versions 3.2.0 and 3.2.1 of libolm have been released. 3.2.0 supports fallback keys (MSC2732) in the C library and the JavaScript binding, and includes several JavaScript/TypeScript fixes and improvements. 3.2.1 was just a fix to the TypeScript definition file.

Dept of SDKs and Frameworks 🧰

Ruma

Ruma is a Rust project to create a comprehensive set of APIs for Matrix. Previously there was a Ruma homeserver project.

jplatte said:

This week, q-b implemented moderation policy events, bringing us to full compatibility with r0.6.1 of the client-server API. iinuwa added the only endpoint we were missing from the appservice API. Additionally, I improved Ruma's JSON canonicalization, making it both simpler and more efficient.
Due to two issues regarding future-compatibility, we're still a while away from our next set of releases, but we're working on it!

New library: ObjMatrix (Objective-C)

js introduced it with:

ObjMatrix (GitHub) is a new Matrix client library written in modern Objective-C for ObjFW. Because it uses ObjFW, it is not limited to Apple platforms, and instead is extremely portable and should run on basically everything.
This is currently in its very early stages and is intended to be suitable to develop bots and clients with very soon. Being suitable to develop bridges with it is another goal for later.
Since ObjFW also works on platforms that are usually hard to support or port software to (e.g. MorphOS), this will hopefully also bring clients for these less mainstream operating systems. I'm especially hopeful about MorphOS here, since ObjFW already runs quite well there (parts of it are included with the OS even!), and hardware on which MorphOS runs on is usually not powerful enough to run Element Web. And eventually, I will want to have a Matrix client on my Amiga, too 😉 (which this should enable).
This currently does not have a decicated Matrix room yet, so all discussions about it currently happen in #objfw:nil.im. So please feel free to join there and follow along development. And contributions are of course very welcome!

Dept of Ops 🛠

famedly.matrix ansible collection

JCG told us:

the famedly.matrix ansible collection has seen a release v0.2.0. Highlights since the last TWIM mention:
synapse_register: a new module for registering users using synapse's admin API.
matrix_member: another new module, for inviting/kicking/banning people to/from rooms.
updates to synapse and element have been merged into their roles
support deploying release candidates of synapse and element

Dept of Guides 🧭

Noteworthy Hub Guide

balaa told us:

We’ve put together a write up on how to deploy a Noteworthy Hub (transparent TLS proxy) in order to make it easy to run a federation capable matrix home server behind a firewall or NAT: https://noteworthy.tech/hub

Dept of Ping 🏓

Rank	Hostname	Median MS
1	helderferreira.io	487
2	heitkoetter.net	627
3	asra.gr	802
4	conduit.rs	1178
5	matrix.thedisco.zone	1275.5
6	shortestpath.dev	1803
7	lelux.net	2419
8	elcyb.org	2685
9	test.zemos.net	2800
10	blob.cat	2882

That's all I know 🏁

Thanks anoa for TCB* the last two weeks! Was fun to be the one to read TWIM for myself. :D

See you next week, and be sure to stop by #twim:matrix.org with your updates!

* Taking Care of Business

Dendrite is entering Beta!

2020-10-08 — 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:

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:

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: