Hi all,

Synapse 1.11 landed on Friday (sorry for running late on blogging the release notes!)

The main change is to introduce an experimental API MSC2432 for managing aliases for rooms on your local server. In Synapse 1.10 we removed support for m.room.aliases events, which were a way to try to track which aliases a room had on the room itself (but were vulnerable to abuse). In this release we've re-added the ability to query which aliases a given server has for the room, giving visibility for managing aliases, without having them spray all over the room state itself. Riot/Web 1.5.10 supports the new API, giving a way to manage aliases on your local server while we finish off the remaining work to improve alias safety & maintenance.

We've also changed the default power levels for new rooms so that room upgrades and ACLs require you to be an Admin (PL100), and invites in public rooms now require you to be a moderator (PL50).

Get the new release from github or any of the sources mentioned at https://github.com/matrix-org/synapse/blob/master/INSTALL.md.

🔗Synapse 1.11.0 (2020-02-21)

🔗Improved Documentation

• Small grammatical fixes to the ACME v1 deprecation notice. (#6944)

🔗Synapse 1.11.0rc1 (2020-02-19)

🔗Features

• Admin API to add or modify threepids of user accounts. (#6769)
• Limit the number of events that can be requested by the backfill federation API to 100. (#6864)
• Add ability to run some group APIs on workers. (#6866)
• Reject device display names over 100 characters in length to prevent abuse. (#6882)
• Add ability to route federation user device queries to workers. (#6873)
• The result of a user directory search can now be filtered via the spam checker. (#6888)
• Implement new GET /_matrix/client/unstable/org.matrix.msc2432/rooms/{roomId}/aliases endpoint as per MSC2432. (#6939, #6948, #6949)
• Stop sending m.room.aliases events when adding / removing aliases. Check alt_aliases in the latest m.room.canonical_alias event when deleting an alias. (#6904)
• Change the default power levels of invites, tombstones and server ACLs for new rooms. (#6834)

🔗Bugfixes

• Fixed third party event rules function on_create_room's return value being ignored. (#6781)
• Allow URL-encoded User IDs on /_synapse/admin/v2/users/<user_id>[/admin] endpoints. Thanks to @NHAS for reporting. (#6825)
• Fix Synapse refusing to start if federation_certificate_verification_whitelist option is blank. (#6849)
• Fix errors from logging in the purge jobs related to the message retention policies support. (#6945)
• Return a 404 instead of 200 for querying information of a non-existent user through the admin API. (#6901)

🔗Updates to the Docker image

• The deprecated "generate-config-on-the-fly" mode is no longer supported. (#6918)

🔗Improved Documentation

• Add details of PR merge strategy to contributing docs. (#6846)
• Spell out that the last event sent to a room won't be deleted by a purge. (#6891)
• Update Synapse's documentation to warn about the deprecation of ACME v1. (#6905, #6907, #6909)
• Add documentation for the spam checker. (#6906)
• Fix worker docs to point /publicised_groups API correctly. (#6938)
• Clean up and update docs on setting up federation. (#6940)
• Add a warning about indentation to generated configuration files. (#6920)
• Databases created using the compose file in contrib/docker will now always have correct encoding and locale settings. Contributed by Fridtjof Mund. (#6921)
• Update pip install directions in readme to avoid error when using zsh. (#6855)

🔗Deprecations and Removals

• Remove m.lazy_load_members from unstable_features since lazy loading is in the stable Client-Server API version r0.5.0. (#6877)

🔗Internal Changes

• Add type hints to SyncHandler. (#6821)
• Refactoring work in preparation for changing the event redaction algorithm. (#6823, #6827, #6854, #6856, #6857, #6858)
• Fix stacktraces when using ObservableDeferred and async/await. (#6836)
• Port much of synapse.handlers.federation to async/await. (#6837, #6840)
• Populate rooms.room_version database column at startup, rather than in a background update. (#6847)
• Reduce amount we log at INFO level. (#6833, #6862)
• Remove unused get_room_stats_state method. (#6869)
• Add typing to synapse.federation.sender and port to async/await. (#6871)
• Refactor _EventInternalMetadata object to improve type safety. (#6872)
• Add an additional entry to the SyTest blacklist for worker mode. (#6883)
• Fix the use of sed in the linting scripts when using BSD sed. (#6887)
• Add type hints to the spam checker module. (#6915)
• Convert the directory handler tests to use HomeserverTestCase. (#6919)
• Increase DB/CPU perf of _is_server_still_joined check. (#6936)
• Tiny optimisation for incoming HTTP request dispatch. (#6950)

Hi all,

We're just back from an incredible time at FOSDEM 2020 - Europe's biggest Free & Open Source Software conference. Huge huge thanks to everyone who came to our talks (sorry if you couldn't get in :/), came to talk to us at the stand, or flagged us down to give feedback, chase PRs, file bugs, or just say thanks. Thanks also to FOSDEM to accepting all of our talks this year, and to the FOSDEM organisers for pulling together yet another amazing event :)

We ended up with three talks:

• Making and Breaking Matrix's E2E Encryption
• The Path to Peer-to-Peer Matrix
• Crossing the Bifröst - Bridging All The Things with Matrix

We'll do a proper blog write-up on enabling E2E encryption by default, cross-signing, and all the other E2E encryption work that's been going on once we ship the stable release - but as of Saturday(!) it has landed on Riot/Web Develop, RiotX/Android (0.14.2) and Riot/iOS develop TestFlight, but we're still debugging and we need a bit longer before cutting the final releases.

So, until then, please take a look at the videos if you missed the livestream or weren't at the event!

The FOSDEM video recording lost the slides for the bridging talk - but luckily the presentation itself is a Matrix client and so you can view the slides yourself right here!.

Here's to FOSDEM 2021!

A few years ago, back when Matrix was originally implementing end-to-end encryption, we asked Moxie (the project lead for Signal) whether he’d ever consider connecting Signal (then TextSecure) to Matrix. After all, one of Matrix’s goals is to be an interoperability layer between other communication silos, and one of the reasons for us using Signal’s Double Ratchet Algorithm for Matrix’s encryption was to increase our chances of one day connecting with other apps using the same algorithm (Signal, WhatsApp, Google Allo, Skype, etc). Moxie politely declined, and then a few months later wrote “The ecosystem is moving” to elaborate his thoughts on why he feels he “no longer believes that it is possible to build a competitive federated messenger at all.”

At the time we didn’t respond via a blog post; instead we ended up talking it through a few times in person to see how misaligned we really were. The conclusion was that we agreed to disagree and Moxie said he’d be happy to be proved wrong, and wished us good luck. However, the subject has come up again thanks to Moxie’s talk on the same subject at 36C3 last week, and we keep getting asked to write a formal response on the Matrix side. So, here’s an attempt to do so. (Moxie didn’t want the 36C3 talk recorded, and I haven’t watched it, so this is responding to the original blog post).

From my perspective, the main points proposed in ‘The ecosystem is moving’ boil down to:

• Decentralised systems are harder to design and build than centralised ones, as coordination is harder if you don’t have a single authority to trust.

• Decentralised systems are harder and slower to evolve than centralised ones, as you can’t force participants to rapidly roll out (or even agree on) new features.

• Users in federated systems tend to coalesce around the best/biggest server that the bulk of people use - which means that server typically gets to see a disproportionate amount of communication metadata (who’s talking to who, and when), and has disproportionate power over the network, which could bully others away from running their own deployments.

• If users don’t trust their app provider, they can always go switch apps, which gives them freedom.

• Open systems are less secure because you have no control over the quality of the implementations - if anyone can bring their own client or server to the table, all it takes is one bad implementation to compromise everyone in the vicinity.

Now, all of these points are valid to some extent.

It’s absolutely true that decentralised systems are harder than centralised ones. Prior to Matrix we built centralised comms systems - we literally can do a side-by-side comparison for the same team to see how easily and fast we built our centralised comms system relative to Matrix. Empirically It took us around 6 times longer to get to the same feature-set with Matrix.

It’s also true that decentralised systems are harder to evolve than centralised ones - you can’t just push out a given feature with a single app update, but you have to agree and publish a public spec, support incremental migration, and build governance processes and community dynamics which encourage everyone to implement and upgrade. This is hard, but not impossible: we’ve spent loads of time and money on Matrix’s governance model and spec process to get it right. It’s still not perfect, but we haven’t seen much fragmentation so far, and when we’re pushing out a feature empirically we can and do go just as fast as the centralised alternatives. (E2E by default is a bit of a special case because we’ve had to go and reimplement many features users take for granted today in an E2E-capable manner, but we’re sprinting to get it done in the coming weeks). A bigger problem is that there are hundreds of spec change proposals which folks would like to see in the protocol, and finding a way to manage expectations and parallelise spec progress is hard - something we’re looking to improve in 2020 (although still figuring out how!)

It’s also fair that in a multi-server federated model, users naturally tend to sign up on the most prominent server(s) (e.g. the matrix.itmanbu.com homeserver in the case of Matrix). In practice, the matrix.itmanbu.com homeserver currently makes up about 35% of the visible Matrix network by active users. It’s also true that Matrix servers currently store metadata about who’s talking to who, and when, as a side-effect of storing and relaying messages on behalf of their users. And without an adequate protocol governance system in place, a large server could start pushing around smaller ones in terms of protocol behaviour. In practice, we’re looking into solving metadata protection in Matrix by experimenting with hybrid P2P / Client Server models - letting users store their metadata purely clientside if they so desire, and potentially obfuscating who’s talking to who via mixnets of blinded store & forward servers (more about this coming up at FOSDEM). Combined with nomadic accounts, this would let us eventually turn off the matrix.itmanbu.com server entirely and eliminate the pseudo-centralisation effect - the default ‘server’ would be the one running on your client.

It’s true that if a user doesn’t trust (say) Telegram, they are free to go switch to Signal or WhatsApp or whatever instead… at the massive expense of having to persuade all their friends to install yet another app, and fragmenting their conversation history across multiple apps.

Finally, it’s also true that because anyone can develop a Matrix client or server and connect to the global network, there’s a risk of bad quality implementations in the wild. There are many forks of Riot on the app stores - we simply can’t vouch for whether they are secure. Similarly there are Matrix clients whose E2E encryption is partial, missing, or unreviewed. And there are a wide range of different Matrix servers run by different people with different agendas in different locations, which may be more or less trustworthy.

HOWEVER: all of this completely ignores one critical thing - the value of freedom. Freedom to select which server to use. Freedom to run your own server (perhaps invisibly in your app, in a P2P world). Freedom to pick which country your server runs in. Freedom to select how much metadata and history to keep. Freedom to choose which apps to use - while still having the freedom to talk to anyone you like (without them necessarily installing yet another app). Freedom to connect your own functionality - bots, bridges, integrations etc. Freedom to select which identifiers (if any) to use to register your account. Freedom to extend the protocol. Freedom to write your own client, or build whole new as-yet-unimagined systems on top.

It’s true that if you’re writing a messaging app optimised for privacy at any cost, Moxie’s approach is one way to do it. However, this ends up being a perversely closed world - a closed network, where unofficial clients are banned, with no platform to build on, no open standards, and you end up thoroughly putting all your eggs in one basket, trusting past, present & future Signal to retain its values, stay up and somehow dodge compromise & censorship… despite probably being the single highest value attack target on the ‘net.

Quite simply, that isn’t a world I want to live in.

We owe the entire success of the Internet (let alone the Web) to openness, interoperability and decentralisation. To declare that openness, interoperability and decentralisation is ‘too hard’ and not worth the effort when building a messaging solution is to throw away all the potential of the vibrancy, creativity and innovation that comes from an open network. Sure, you may end up with a super-private messaging app - but one that starts to smell alarmingly like a walled garden like Facebook’s Internet.org initiative, or an AOL keyword, or Google’s AMP.

So, we continue to gladly take up Moxie’s challenge to prove him wrong - to show that it’s both possible and imperative to create an open decentralised messaging platform which (if you use reputable apps and servers) can be as secure and metadata-protecting as Signal… and indeed more so, given you can run your server off the grid, and don’t need to register with a phone number, and in future may not even need a server at all.

--Matthew

(Comments over at HN)

Hi all,

We've just released Synapse 1.7.3 - an important bug fix to address a class of failures due to malformed events. We've seen this in the wild over the last few days, so we'd recommend updating as soon as possible, especially if you are having problems federating.

Get the new release from github or any of the sources mentioned at https://github.com/matrix-org/synapse/blob/master/INSTALL.md.

The changelog since 1.7.2 is:

🔗Synapse 1.7.3 (2019-12-31)

This release fixes a long-standing bug in the state resolution algorithm.

🔗Bugfixes

• Fix exceptions caused by state resolution choking on malformed events. (#6608)

Hi all,

Every year we do an annual wrap-up and retrospective of all the things happening in the Matrix core team - if you’re feeling particularly curious or bored you can check out the 2015, 2016, 2017 and 2018 editions for context. The idea is to look at the bigger picture trends in Matrix outside of the weekly TWIM posts to get an idea of the stuff which we made progress on, and the stuff which still remains.

That said, it’s hard to know where to start - Matrix accelerated more than ever before in 2019, and there’s been progress on pretty much all battlefronts. So as a different format, let’s take the stuff we said we had planned for 2019 from the end of last year’s update and see what we actually achieved...

Continue reading…

Hi all,

We've just released Synapse 1.7.2 - a minor point release to address two regressions which snuck into 1.7.0 and 1.7.1. Sorry for the upgrade faff; hopefully we will be back to a saner release cadence shortly. Reminder that if you are on 1.7.0 or earlier you should upgrade asap as 1.7.1 contained security fixes.

Get the new release from github or any of the sources mentioned at https://github.com/matrix-org/synapse/blob/master/INSTALL.md.

The changelog since 1.7.1 is:

🔗Synapse 1.7.2 (2019-12-20)

This release fixes some regressions introduced in Synapse 1.7.0 and 1.7.1.

🔗Bugfixes

• Fix a regression introduced in Synapse 1.7.1 which caused errors when attempting to backfill rooms over federation. (#6576)
• Fix a bug introduced in Synapse 1.7.0 which caused an error on startup when upgrading from versions before 1.3.0. (#6578)

Hi all,

We’re incredibly excited that Mozilla just announced that they’ve selected Matrix as the successor to IRC as the communication platform for the public Mozilla community!! This comes off the back of a formal 1-month trial in September to evaluate various options side by side, and now New Vector will be helping Mozilla get their homeserver up and running on the Modular.im hosting platform over the coming weeks - and federating openly with the rest of the open global Matrix network! :)

We have always been massive fans of Mozilla: they have been an excellent role model as champions of the open web, open standards, not to mention open source - and it’s fair to say that Mozilla has been a major inspiration to how Matrix has evolved (Riot aspires to be to Matrix what Firefox is to the Web: a flagship open source app which provides an accessible friendly interface into an open standard network). It’s very reassuring to see that Mozillians from the trial recognise the alignment and have converged on Matrix as the way forward - it’s a massive win for the open web and standards-based communication in general.

It’s worth noting that we’ve also always been massive fans of IRC, and Matrix is unashamedly derivative of IRC in capabilities and culture, while broadening the scope to decentralised synchronisation and relaying of any kind of data. For context, the genesis of the team which eventually spawned Matrix was on a student IRC server ~20 years ago - and subsequently everything we’ve worked on (up to Matrix) was coordinated exclusively through IRC. We even used to give conference talks on how to run your project/company off IRC. I can’t really overstate how fundamental IRC is to our history - and we still keep our private IRC network online for old time’s sake (albeit bridged to Matrix). The very first protocol bridge we built for Matrix back in 2015 was for IRC - and Moznet and Freenode were the first public bridges we turned on. As of right now, /stats u on Moznet says that there are 4950 connected users, of which 1724 (so 35%) are actually Matrix users connected via the Moznet bridge - effectively using Matrix as a big decentralised IRC bouncer in the sky.

All of this is to say is that we deeply understand how dependent Mozilla has been on IRC over the years, and that we built Matrix to be a worthy successor which tries to capture all the best bits of IRC while providing much richer primitives (E2E encryption, openly federated decentralised chatrooms, arbitrary data sync, HTTP API, VoIP, etc). It’s also worth noting that even though Moznet is being turned off, matrix-ircd exists as a very promising project that exposes any Matrix homeserver as an ircd - so for all you IRC die-hards, Moznet can absolutely live on in the afterlife! (matrix-ircd is still alpha right now, but it’s a relatively modest amount of Rust and PRs are very welcome - if you grok IRC it should be a really really fun project to contribute to).

In other news, the trial in September was an amazing opportunity to gather feedback first-hand from a wide range of Mozillians as they gave Riot and Matrix a spin, often for the first time - and it was a lot of fun to take that feedback and rapidly act on it to improve the app. For instance, having direct expert feedback on our screenreader support meant that we were able to radically improve our accessibility, and we’ve kept up the momentum on this since the trial (regardless of the outcome) with Mozilla & Riot devs hacking together with the aim of making Riot the most accessible communication app out there without exception. Huge thanks to Marco Zehe for all his guidance (and PRs), as well as the rest of #a11y:matrix.itmanbu.com!

Meanwhile, Riot’s UX continues to mature in general. One of our two primary projects right now is to improve First Time User Experience (FTUE) - i.e. making our UX as smooth and polished and predictable as possible, especially as seen by new users. This project had just kicked off in September as the Mozilla trial began, and some of the major improvements to the Room Directory and Room Creation flow which subsequently landed in Riot/Web 1.5 were prioritised directly based on Mozillian feedback. Since the trial we’ve been focusing more on our other primary project (getting E2E Encryption enabled by default), but we will be back on FTUE asap - particularly to incorporate all the feedback we anticipate as Mozilla goes live! We are absolutely determined for Riot to have as good if not better UX than the likes of Slack or Discord. New Vector is also actively hiring more designers to come work fulltime on Riot’s UI and UX as we shift Riot’s focus from being developer-led to design-led - if this sounds interesting, please get in touch! And finally, everything is of course open source and PRs are genuinely appreciated to keep Riot heading in the right direction (please just check first if they change the UI/UX).

Finally, in case you’re dreading having to use a graphical chat client like Riot, the Mozilla instance will of course be accessible to any Matrix client that floats your boat - for instance, weechat-matrix also got a spurt of development to support Mozilla IAM single-sign-on so that commandline junkies can get their fix too. (It’s worth noting that weechat-matrix really is an incredibly fully featured and usable client - complete with full end-to-end encryption support. If you haven’t tried it, you’re missing out).

So, to conclude: it has been indescribably valuable to have the expertise and enthusiasm of the Mozilla community in contributing feedback and fixes to Riot (and even building new Matrix bots!). Huge thanks to everyone who invested their time and energy participating in the trial and for their trust in concluding that Matrix was the way forward. We see this as a massive responsibility and honour to help power the wider Mozilla community, and we will do everything we can to make it as successful as conceivably possible :)

To the future of an open web, with even more open communications!

Matthew, Amandine & the whole Matrix & Riot team :)

P.S. we’ve come a long way since Matrix was first proposed for Mozilla :D

Hi all,

Over the course of today we've been made aware of folks port-scanning the general internet to discover private Matrix servers, looking for publicly visible room directories, and then trying to join rooms listed in them.

If you are running a Matrix server that is intended to be private, you must correctly configure your server to not expose its public room list to the general public - and also ensure that any sensitive rooms are invite-only (especially if the server is federated with the public Matrix network).

In Synapse, this means ensuring that the following options are set correctly in your homeserver.yaml:

# If set to 'false', requires authentication to access the server's public rooms
# directory through the client API. Defaults to 'true'.
#
#allow_public_rooms_without_auth: false

# If set to 'false', forbids any other homeserver to fetch the server's public
# rooms directory via federation. Defaults to 'true'.
#
#allow_public_rooms_over_federation: false

For private servers, you will almost certainly want to explicitly set these to false, meaning that the server's "public" room directory is hidden from the general internet and wider Matrix network.

You can test whether your room directory is visible to arbitrary Matrix clients on the general internet by viewing a URL like https://sandbox.modular.im/_matrix/client/r0/publicRooms (but for your server). If it gives a "Missing access token" error, you are okay.

You can test whether your room directory is visible to arbitrary Matrix servers on the general internet by loading Riot (or similar) on another server, and entering the target server's domain name into the room directory's server selection box. If you can't see any rooms, then are okay.

Relatedly, please ensure that any sensitive rooms are set to be "invite only" and room history is not world visible - particularly if your server is federated, or if it has public registration enabled. This stops random members of the public peeking into them (let alone joining them).

Relying on security-by-obscurity is a very bad idea: all it takes is for someone to scan the whole internet for Matrix servers, and then trying to join (say) #finance on each discovered domain (either by signing up on that server or by trying to join over federation) to cause problems.

Finally, if you don't want the general public reading your room directory, please also remember to turn off public registration on your homeserver. Otherwise even with the changes above, if randoms can sign up on your server to view & join rooms then all bets are off.

We'll be rethinking the security model of room directories in future (e.g. whether to default them to being only visible to registered users on the local server, or whether to replace per-server directories with per-community directories with finer grained access control, etc) - but until this is sorted, please heed this advice.

If you have concerns about randoms having managed to discover or join rooms which should have been private, please contact [email protected].

Hi all,

This morning (06:11 UTC) it became apparent through mails to [email protected] that a security researcher was working through the TLS Certificate Transparency logs for *.matrix.itmanbu.com,*.riot.im and *.modular.im to identify and try to access non-public services run by New Vector (the company formed by the original Matrix team, which hosts *.matrix.itmanbu.com on behalf of the matrix.itmanbu.com Foundation, and develops Riot and runs the https://modular.im hosting service).

Certificate Transparency (CT) is a feature of the TLS ecosystem which lets you see which public certificates have been created and signed by given authorities - intended to help identify and mitigate against malicious certificates. This means that the DNS name of any host with a dedicated public TLS certificate (i.e. not using a wildcard certificate) is visible to the general public.

In practice, this revealed a handful of internal-facing services using dedicated public TLS certificates which were accessible to the general internet - some of which should have been locked to be accessible only from our internal network.

Specifically:

• kibana.ap-southeast-1.k8s.i.modular.im - a Kibana deployment for a new experimental Modular cluster which is being set up in SE Asia. The Kibana is in the middle of being deployed, and was exposed without authentication during deployment due to a firewall & config error. However, it is not a production system and carries no production traffic or user data (it was just being used for experimentation for hypothetical geography-specific Modular deployments). We firewalled this off at 07:53 UTC, and are doing analysis to confirm there was no further compromise, and will then rebuild the cluster (having fixed the firewall config error from repeating).
• AWX deployments used by our internal Modular platform, which were behind authentication but should not be exposed to the public net.
• Various semi-internal dev and testing services which should be IP-locked to our internal network (but are all locked behind authentication too).

Additionally, certain historical Modular homeservers & Riots (from before we switched to using wildcard certs, or where we’ve created a custom LetsEncrypt certificate for the server) are named in the CT logs - thus leaking the server’s name (which is typically public anyway in that server’s matrix IDs if the server is federated).

We’re working through the services whose names were exposed checking for any other issues, but other than the non-production SE Asia Kibana instance we are not aware of problems resulting from this activity.

Meanwhile, we’ll be ensuring that semi-internal services are only exposed on our internal network in future, and that Modular server names are not exposed by CT logs where possible.

TL;DR: You can list all the public non-wildcard TLS certs for a given domain by looking somewhere like https://crt.sh/?q=%25.matrix.itmanbu.com. This lets you find internal-sounding services to try to attack. In practice no production services were compromised, and most of our internal services are correctly firewalled from the public internet. However, we’re reviewing the IP locking for ones in the grey zone (and preventing the bug which caused an experimental Kibana to be exposed without auth).

We’d like to thank Linda Lapinlampi for notifying us about this. We’d also like to remind everyone that we operate a Security Disclosure Policy (SDP) and Hall of Fame at https://matrix.itmanbu.com/security-disclosure-policy/ which is designed to protect innocent users from being hurt by security issues - everyone: please consider disclosing issues responsibly to us as per the SDP.

Hi all,

We've released Synapse 1.4.1 as a small but important bugfix to 1.4.0.

This fixes a regression which crept in with our newly implemented "erase redacted data after N days" feature where some APIs would fail when hitting erased redactions - anyone on Synapse 1.4.0 will want to upgrade asap.

As always, you can get the new update here or any of the sources mentioned at https://github.com/matrix-org/synapse. Also, check out our Synapse installation guide page

The changelog since 1.4.0 follows:

🔗Synapse 1.4.1 (2019-10-18)

No changes since 1.4.1rc1.

🔗Synapse 1.4.1rc1 (2019-10-17)

🔗Bugfixes

• Fix bug where redacted events were sometimes incorrectly censored in the database, breaking APIs that attempted to fetch such events. (#6185, 5b0e9948)