We are happy to launch The Matrix Conference on Oct 15-18 in Strasbourg, France. Learn more about it, buy a ticket!

On Privacy versus Freedom

2020-01-02 — Privacy, ThoughtsMatthew Hodgson

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.org homeserver in the case of Matrix). In practice, the matrix.org 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.org 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)

Synapse 1.7.3 released

2019-12-31 — ReleasesMatthew Hodgson

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)

This Week in Matrix 2019-12-27

2019-12-27 — This Week in MatrixBen Parsons
Last update: 2019-12-27 23:52

🔗Dept of Status of Matrix 🌡

🔗36c3: Matrix Assembly is the place to be

If you're at 36c3 this weekend, come and find us! Use c3nav app to find our assembly, or just join #chaosevents:matrix.org to come chat

🔗Bundeswehr considering Matrix

Oleg said:

The German Army is considering using Matrix as "secure WhatsApp" for soldiers. (In German) https://www.heise.de/newsticker/meldung/Open-Source-Bundeswehr-baut-eigene-verschluesselte-Messenger-App-4623404.html

🔗Dept of Servers 🏢

🔗matrix-oauth

TravisR reported:

For those who want to integrate Matrix into their application with OAuth, there's now matrix-oauth ( #oauth:t2bot.io ). Ideally useful for "Login with Matrix" buttons, this is a relatively easy OAuth 2.0 provider to set up in front of your homeserver. In future it'll support more granular scopes to avoid having to give a real access token to the third party application.

A demo of matrix-oauth in action is available at https://demo.oauth.t2host.io/

🔗Dept of Bridges 🌉

🔗Amazon Alexa skill

TravisR offered:

Yelling at your Amazon Alexa to send a message to your Matrix contacts is now possible with matrix-alexa-skill ( #alexa:t2bot.io ). A hosted version using matrix-oauth is coming soon, assuming I can get the privacy policy and such over to Amazon to review in a timely manner, though you're more than able to self-host in a matter of minutes. Check out the README for more info - some experience with setting up complicated things is required.

🔗mx-puppet-bridge

sorunome offered:

mx-puppet-bridge got a new feature: protocol implementations can now specify custom commands that are invoked via the provisioning room!

🔗mx-puppet-discord

mx-puppet-discord received quite a few bug fixes and new features!

  • Fix echo back of edits
  • [User Tokens] being friends is enough now to DM each other!
  • fix multi-edits
  • [User Tokens] support group DMs
  • Implement ability to bridge guilds!
  • [User Tokens] add friends management

Description on how to use these features are found in the readme!

If you enjoy these projects, please consider to donate. Thank you!

🔗Dept of Clients 📱

🔗Spectral gains public room directory

Black Hat reported:

Public room directory and user directory support in Spectral is finally there!

spectral room directory

🔗Continuum, plus koma library

yuforia offered:

koma, a Kotlin library. Dominic Fischer (github: Dominaezzz) started working on the project last week and so far:

  • In preparation for multiplatform support, converted JVM code to agnostic Kotlin, using the library atomicfu

  • Added Github Actions configuration to run builds automatically

Continuum, desktop client based on Koma:

  • Generate room name from members when neither name nor aliases are configured

🔗Dept of Ops 🛠

🔗ma1sd 2.2.2 released

ma1uta announced:

ma1sd (fork of the mxisd) 2.2.2 released: https://github.com/ma1uta/ma1sd/releases/tag/2.2.2 Changes:

  • bugfix
  • added hash lookup for the ldap provider.

🔗Dept of Services 🚀

🔗kapsi.fi has set up a Matrix homeserver

Cos reported:

Finnish non-profit hosting service kapsi.fi has set up a Matrix homeserver for their members. Kapsi has around 5000 members and 20 volunteer administrators. Instructions for use (in FInnish) at https://www.kapsi.fi/palvelut/matrix.html

🔗Dept of Bots 🤖

🔗MatrixVideo2oggBot

@progserega:rsprim.ru reported:

Matrix bot for converting youtube video to voice.

Bot https://github.com/progserega/MatrixVideo2oggBot get youtube URL, download video, convert to ogg-vorbis audio and send it to user. Some times my friends give me youtube video-urls, but I do not have time for see it. But I have time when I go home in car. But on road network is not always good and at end of day battery is low and phone may be hot (when I connect to charger and play video) and freeze... Simple way for me - is convert youtube video to small size voice and download it to phone and play it as music in player playlist. Bot help to this. May be it help anybody also. 🙂

🔗Matrix in the News 📰

Andres offered:

Matrix gets a mention alongside other four decentralized protocols in one of the biggest argentinian newspapers (regarding Twitter's iniciative of decentralization). https://www.lanacion.com.ar/tecnologia/cinco-iniciativas-descentralizar-redes-sociales-dejar-depender-nid2317548

🔗Dept of Ping 🏓

RankHostnameMedian MS
1getflexedon.me211.5
2thinker.eu.org306
3maunium.net432
4dodsorf.as438
5lyseo.edu.ouka.fi455
6matrix.vgorcum.com562
7uraziel.de626
8tout.im640.5
9kapsi.fi650
10encom.eu.org862

🔗That's all I know 🏁

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

The 2019 Matrix Holiday Update!

2019-12-24 — General, Holiday SpecialMatthew Hodgson

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…

This Week in Matrix 2019-12-20

2019-12-21 — This Week in MatrixBen Parsons
Last update: 2019-12-20 18:29

🔗Dept of Status of Matrix 🌡

🔗Matrix selected for the public Mozilla community

You may well have read about it by now, but Mozilla (purveyor of popular web browsers and champion of the open web) selected Matrix to replace IRC for their comms! You can read their own announcement here. Please note that this doesn't have to mean the death of Moznet on IRC - if someone wants to pick up matrix-ircd and finish it off, we can keep exposing an IRC listener too! Huge thanks to everyone who participated in the Mozilla trial and placed their trust in Matrix :)

🔗A Glimpse of the Matrix

Florian reported:

Florian presented his poster A Glimpse of the Matrix:Scalability issues of a new message-oriented data synchronizationmiddleware at the 20th International Middleware Conference at UC Davis, California on 2019-12-11. The poster abstract describes measurements of the public Matrix federation and discusses scalability issues of the current message routing mechanism. Additional details can be found in the Extended Tech Report.

Those scientific publications were based on the data gathered by the DSN Traveller in 2018 which was part of Florian's master's thesis. The anonymized raw data was published in conjunction.

All related resources

pic.twitter.com/NYxbYllQ9F

— Middleware2019 (@middleware2019) December 12, 2019

🔗Accessibility in Riot/Matrix

Very thorough article on accessibility in Riot/Matrix, written partly in light of the Mozilla announcement. https://marcozehe.de/2019/12/20/how-to-get-around-matrix-and-riot-with-a-screen-reader/

🔗Dept of Servers 🏢

🔗Synapse v1.7.2

Neil told us:

We shipped 1.7.2 (and 1.7.1) - all admins are encouraged to upgrade asap, note 1.7.1 is a security release, and 1.7.2 fixes a back pagination bug introduced in 1.7.1. Aside from that we are looking at implementing MSC2260: Update the auth rules for m.room.aliases events and adding a per media quarantine API.

🔗Deploying Synapse

Several packaging projects have been updated to deploy the new version:

🔗Ruma

jplatte reported:

another blog post has appeared on the ruma website: https://ruma.dev/news/these-weeks-in-ruma-2019-12-14/

🔗cortex workers performance

Black Hat has been using his Rust cortex Synapse workers project. He reported:

I flexed on other homeservers by making getflexedon.me the fastest homeserver in the ping room, made possible with cortex.

Black Hat does point out that this is still in a testing phase, but it's great to see workers being created.

🔗Dept of Bridges 🌉

🔗famedly-email-bridge

sorunome said:

Some more work has been done on famedly-email-bridge! Now you can define email routes (e.g. [email protected] -> @bob:example.org) and optionally have conversations create a new thread room, instead of dumping them into the email room.

🔗zammad tickets bot

It might seem like Half-Shot hasn't made a new bridge in a while, but here he is:

I've started another bot project: https://github.com/half-shot/matrix-zammad. This currently splurts zammad tickets into Matrix rooms, and will eventually do a lot more.

🔗Dept of Clients 📱

🔗Continuum

yuforia said:

Continuum, client for the desktop:

  • Start using experimental asynchronous Flow as observable value for UI. Making use of Kotlin's coroutine features, it makes it possible to update values while avoiding switching to the main UI thread. It's also easier to cancel on-going HTTP requests when their values are no longer needed.

🔗Riot-iOS

Manu told us:

This week, we have been still working hard on verification by DM. We have started the implementation of cross-signing.

🔗RiotX v0.11.0 released

benoit said:

RiotX: We've released RiotX v0.11.0 on Thursday. It includes support to open (some of) matrix.to links, soft (and hard) logout, and lots of small UI/UX/crash fixes. For the first release of 2020, we will change the way we handle the initial sync, which can be a long task, by running it in a foreground service. Also the room profile screen should finally arrive.

🔗riot-web

Bruno reported:

this week I've been working on the new verification flow in the right panel. it's nearly there, but likely won't get merged today anymore.

🔗Dept of Ops 🛠

🔗Matrix Message github action

Nice and simple project for using Matrix messages in Github actions. See the code, or the marketplace page.

🔗Dept of Ping 🏓

RankHostnameMedian MS
1getflexedon.me312
2thinker.eu.org346
3tedomum.net384
4aime.lesmatric.es440
5dodsorf.as463
6bubu1.eu534.5
7lyseo.edu.ouka.fi558.5
8maunium.net563
9matrix.vgorcum.com654
10testmatrix.vgorcum.com751

🔗Final Thoughts 💭

It being the time of year that it is, some of us will be at 36c3 in a week or so, come chat in #chaosevents:matrix.org if you'd like to say "hi". (You can also say "Guten Tag", which is more fun!)

🔗That's all I know 🏁

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

Synapse 1.7.2 released

2019-12-20 — ReleasesMatthew Hodgson

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)

Welcoming Mozilla to Matrix!

2019-12-19 — In the NewsMatthew Hodgson

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.org!

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

Synapse 1.7.1 released

2019-12-18 — ReleasesRichard van der Hoff

Hi folks; today we are releasing Synapse 1.7.1.

This is a security release which fixes some problems which affected all previous versions of Synapse. We advise all admins whose servers are open to public federation to upgrade as soon as possible.

Full details follow, but the most important change improves event authorization, thereby preventing the ability to add certain events to a given room erroneously.

You can 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.0 follows:

🔗Security updates

  • Fix a bug which could cause room events to be incorrectly authorized using events from a different room. (#6501, #6503, #6521, #6524, #6530, #6531)
  • Fix a bug causing responses to the /context client endpoint to not use the pruned version of the event. (#6553)
  • Fix a cause of state resets in room versions 2 onwards. (#6556, #6560)

🔗Bugfixes

  • Fix a bug which could cause the federation server to incorrectly return errors when handling certain obscure event graphs. (#6526, #6527)

Synapse 1.7.0 released

2019-12-13 — ReleasesNeil Johnson

Hello people, it’s Synapse 1.7.0 time.

This release includes some long requested features, most notably the ability to automatically delete message data after a predefined period. For more details take a look at the config here ─ it should be pretty self explanatory.

Another significant change this release is to explicitly set room directories to be private by default. Previously it was possible to inadvertently configure the directory to be visible to arbitrary Matrix servers and the internet in general.

This means that for those admins who want their room directories to be publicly searchable (matrix.org for instance) they need to explicitly say so in the config. For more details see the upgrade notes and our blog post explaining the situation in greater detail.

We also have early support for ephemeral messages, as well as the ability to specify a reason when rejecting an invite (amongst other actions).

Aside from all of that, we want to let you know about some changes on the horizon. Currently Synapse runs Sqlite by default. This is great in that it gets new admins going quickly without needing to install and configure Postgres. The downside of using Sqlite is that it offers very poor performance, especially once a server tries to join the federation. In truth Sqlite is only really there to demonstrate the service, but for anything other than the most trivial cases it is essential to migrate to Postgres.

Over the past few months we’ve been working to improve the migration path to Postgres such that finally we feel confident to actively encourage admins to migrate. What’s more, in a future release we will forcibly prevent SQLite-backed servers federating unless the admin explicitly sets a config flag to show that they understand the trade-off they are making.

Overall we see these changes as something that will improve everyone’s experience of the matrix federation. We’ll talk more about this closer to the time, but please expect a change in the coming months and if you are running SQLite, consider this a nudge to get yourself migrated.

As ever, 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.6.1 follows:

🔗Synapse 1.7.0 (2019-12-13)

This release changes the default settings so that only local authenticated users can query the server's room directory. See the upgrade notes for details.

Support for SQLite versions before 3.11 is now deprecated. A future release will refuse to start if used with an SQLite version before 3.11.

Administrators are reminded that SQLite should not be used for production instances. Instructions for migrating to Postgres are available here. A future release of synapse will, by default, disable federation for servers using SQLite.

No significant changes since 1.7.0rc2.

🔗Synapse 1.7.0rc2 (2019-12-11)

🔗Bugfixes

  • Fix incorrect error message for invalid requests when setting user's avatar URL. (#6497)
  • Fix support for SQLite 3.7. (#6499)
  • Fix regression where sending email push would not work when using a pusher worker. (#6507, #6509)

🔗Synapse 1.7.0rc1 (2019-12-09)

🔗Features

  • Implement per-room message retention policies. (#5815, #6436)
  • Add etag and count fields to key backup endpoints to help clients guess if there are new keys. (#5858)
  • Add /admin/v2/users endpoint with pagination. Contributed by Awesome Technologies Innovationslabor GmbH. (#5925)
  • Require User-Interactive Authentication for /account/3pid/add, meaning the user's password will be required to add a third-party ID to their account. (#6119)
  • Implement the /_matrix/federation/unstable/net.atleastfornow/state/<context> API as drafted in MSC2314. (#6176)
  • Configure privacy-preserving settings by default for the room directory. (#6355)
  • Add ephemeral messages support by partially implementing MSC2228. (#6409)
  • Add support for MSC 2367, which allows specifying a reason on all membership events. (#6434)

🔗Bugfixes

  • Transfer non-standard power levels on room upgrade. (#6237)
  • Fix error from the Pillow library when uploading RGBA images. (#6241)
  • Correctly apply the event filter to the state, events_before and events_after fields in the response to /context requests. (#6329)
  • Fix caching devices for remote users when using workers, so that we don't attempt to refetch (and potentially fail) each time a user requests devices. (#6332)
  • Prevent account data syncs getting lost across TCP replication. (#6333)
  • Fix bug: TypeError in register_user() while using LDAP auth module. (#6406)
  • Fix an intermittent exception when handling read-receipts. (#6408)
  • Fix broken guest registration when there are existing blocks of numeric user IDs. (#6420)
  • Fix startup error when http proxy is defined. (#6421)
  • Fix error when using synapse_port_db on a vanilla synapse db. (#6449)
  • Fix uploading multiple cross signing signatures for the same user. (#6451)
  • Fix bug which lead to exceptions being thrown in a loop when a cross-signed device is deleted. (#6462)
  • Fix synapse_port_db not exiting with a 0 code if something went wrong during the port process. (#6470)
  • Improve sanity-checking when receiving events over federation. (#6472)
  • Fix inaccurate per-block Prometheus metrics. (#6491)
  • Fix small performance regression for sending invites. (#6493)
  • Back out cross-signing code added in Synapse 1.5.0, which caused a performance regression. (#6494)

🔗Improved Documentation

  • Update documentation and variables in user contributed systemd reference file. (#6369, #6490)
  • Fix link in the user directory documentation. (#6388)
  • Add build instructions to the docker readme. (#6390)
  • Switch Ubuntu package install recommendation to use python3 packages in INSTALL.md. (#6443)
  • Write some docs for the quarantine_media api. (#6458)
  • Convert CONTRIBUTING.rst to markdown (among other small fixes). (#6461)

🔗Deprecations and Removals

  • Remove admin/v1/users_paginate endpoint. Contributed by Awesome Technologies Innovationslabor GmbH. (#5925)
  • Remove fallback for federation with old servers which lack the /federation/v1/state_ids API. (#6488)

🔗Internal Changes

  • Add benchmarks for structured logging and improve output performance. (#6266)
  • Improve the performance of outputting structured logging. (#6322)
  • Refactor some code in the event authentication path for clarity. (#6343, #6468, #6480)
  • Clean up some unnecessary quotation marks around the codebase. (#6362)
  • Complain on startup instead of 500'ing during runtime when public_baseurl isn't set when necessary. (#6379)
  • Add a test scenario to make sure room history purges don't break /messages in the future. (#6392)
  • Clarifications for the email configuration settings. (#6423)
  • Add more tests to the blacklist when running in worker mode. (#6429)
  • Refactor data store layer to support multiple databases in the future. (#6454, #6464, #6469, #6487)
  • Port synapse.rest.client.v1 to async/await. (#6482)
  • Port synapse.rest.client.v2_alpha to async/await. (#6483)
  • Port SyncHandler to async/await. (#6484)

This Week in Matrix 2019-12-13

2019-12-13 — This Week in MatrixBen Parsons

🔗Matrix Live 🎙

🔗Dept of Status of Matrix 🌡

Matthew notes:

We'd like to welcome Twitter to the world of decentralised communication protocols after Jack Dorsey's announcement this week that Twitter is building a decentralised social media team. It seems that the constraints they're working with are to focus on decentralised reputation (supporting different content filtering algorithms), incentive models (presumably some kind of token) and avoiding consensus-based standards processes. It's worth noting that we've been working on decentralised reputation stuff in Matrix for a while now - of which MSC2313 - Moderation policies as rooms is the most concrete result so far, and it's great to see Twitter thinking about how to adopted different filtering mechanisms for their content. It sounds as if they're approaching this from a blockchain/incentives angle however, so it remains to be seen whether they'll be interested in our work - especially as Matrix doesn't have a microblogging client yet (but only because nobody has made one yet). We'll be trying to talk to them whatever to see if we can be of use, eitherway :)

🔗Dept of Spec 📜

🔗Spec

anoa said:

Here's your weekly update for what happened in spec land!

While it may look quiet from the state changes list, there's actually been a flurry of activity on MSC2376 and MSC2385 (for disabling URL previews on a per-message basis), MSC2380 (for a method of querying the metadata of a piece of media without downloading it) and MSC2346 (for showing metadata about the bridges that are currently active in the room)! Now's the time to jump in if you want to have your say!

Updates:

Merged MSCs

  • No MSCs were merged this week.

MSCs in Final Comment Period

  • No MSCs in FCP.

New MSCs

Spec Core Team:

The Spec Core Team is on the same track as last week with no specific 3 MSC focus, but working on bringing up a lot of MSCs across the board.

🔗Dept of Servers 🏢

🔗Synapse

Neil announced:

Synapse 1.7.0 is out, check out all the details here, admins can now specify message retention policies at a server and room level. We also changed the defaults for the room directory to be privacy preserving by default.

Next up we’re taking a look at support for redacting room alias events 1, 2 as well as porting Sydent to python 3.

🔗Deploying Synapse

Several packaging projects have been updated to deploy the new version:

🔗Dept of Clients 📱

🔗Fractal

Alexandre Franke told us:

We gained the ability to save spellcheck language per room, which makes me quite happy as I keep switching between English speaking and French speaking ones and was growing tired of those red underlines and having to switch manually every time.

Data is stored in /user/{}/rooms/{}/account_data/org.gnome.fractal.language.

🔗Continuum updates

yuforia said:

Continuum, Kotlin client for the desktop:

  • Updated to Kotlin Json and HTTP libraries, removed Moshi and Retrofit from dependencies

  • When there is an error when loading notifications, one can click to retry or view the cause

continuum

🔗nheko

Nico said:

nheko mostly fixed bugs regarding the new file encryption this week and did some organizational stuff:

  • We fixed a compliance issue, where Riot couldn't decrypt our media
  • You can now actually see your encrypted images, when you sent them
  • We fixed some tests regarding our session key export
  • We fixed our coverage of our automated tests
  • We did some prepwork for device verification
  • A few minor usability fixes and code cleanups

🔗RiotX v0.10.0

benoit told us:

RiotX v0.10.0 has been released on Tuesday, with some bug fixes and a new Breadcrumbs drawer to switch between rooms super super fast. Give it a try! Now we are implementing workflow when the access token get invalidated, with SoftLogout support. Also, we are still working on improving the initial sync management, which can be a long task on big account, and that causes some problem with the current implementation. Among various other subjects: matrix.to support, room profile screen, verification in DM, cleanup dependencies to reach the F-Droid store, we are quite busy!

🔗Riot-iOS 0.10.4

Manu reported:

This week, we released Riot-iOS 0.10.4 with a couple of hot fixes on device verification. In parallel, we have been still working on verification by DM both on UI and SDK sides. As a collateral effect, the aggregation of m.reference has been implemented in the SDK. This means the SDK is now ready for message threading !

🔗Riot Web + Cross-Signing

Ryan said:

Cross-signing keys and secret storage can be created in Settings for advanced users with the cross-signing feature flag enabled in labs, though please keep in mind that these features are still in development. More work is still needed to change to verifying users instead of devices. More accessibility fixes have landed as well.

Matthew added:

as part of all the work around cross-signing, we're shifting device verification to happen in the context of DMs so verification is done per-user rather than per-device, and so you can track your verification history and generally massively improve the UX. valere made a great video of how this is shaping up between RiotX and Riot/Web...

Check out the video here

🔗Dept of Ops 🛠

🔗ma1sd 2.2.1 released

ma1uta said:

Release 2.2.0 of the ma1sd (fork mxisd) https://github.com/ma1uta/ma1sd/releases/tag/2.2.0 Changes:

  • support of the MSC2140 (hash lookup)
  • support of the MSC2134 (API v2)

and then...

ma1sd hotfix 2.2.1 released with a lot of bugfixes. Also the v2 API (MSC2140) was disabled by default because it breaks backward compatibility in lookup behaviour.

🔗Dept of Bots 🤖

🔗Matrix bot functionality in Python

Cos reported:

I have created a modular bot for writing Matrix bot functionality in Python easily. It already has bunch of modules ranging from weather to calendar integration and more will come. Even the location bot from last week's TWIM is now implemented as a module. I hope you find it useful. PR's of new modules are always welcome. https://github.com/vranki/hemppa

🔗Mlrdb, LDAP sync bot, announced

@dalang:mc.kircheneuenburg.de offered:

A Bot to sync LDAP groups to matrix rooms. Rooms will be created automatically and group member changes are reflected in the matrix rooms. The bot is currently in beta and documentation will be added in the next weeks. New features for simple integration will be added soon. Have a look at the repo: https://git.sr.ht/~davidlang/mlrbd

🔗Dept of Interesting Projects 🛰

🔗mautrixfs - Matrix client as a FUSE filesystem

Tulir offered:

I've started a new project: mautrixfs is a Matrix client as a FUSE filesystem. It's very WIP and currently only supports reading events by ID. I'm hoping to have something more useful in a week or two.

tulir later added:

for media uploads, I just realized that my asynchronous uploads MSC would make it significantly easier to implement. It could have a file you read to allocate a mxc uri and then you could simply write the data to the file corresponding to that mxc uri

🔗Matrix in the News 📰

Cos offered:

Finnish computer culture paper magazine Skrolli published two articles spanning 5 pages about Matrix in latest edition. For non-subscribers the digital edition readable with mobile app is free for limited time. Read more (in Finnish) at https://skrolli.fi/

skrolli article

🔗Dept of Ping 🏓

RankHostnameMedian MS
1aime.lesmatric.es405.5
2linuxgl.ch424
3dodsorf.as481.5
4pixie.town527
5naido.org589
6kriek.org634
7matrix.vgorcum.com685
8aryasenna.net696.5
9thinker.eu.org727
10bubu1.eu749.5

🔗That's all I know 🏁

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