A few weeks ago we found ourselves in Brussels to participate in the second stakeholder workshop for the Digital Markets Act (DMA).

The DMA is new antitrust/competition regulation from Europe which came into force in November, whose objective is to make digital markets more competitive by forcing gatekeepers (i.e. large tech companies) to reconsider some of their anti-competitive or self-preferencing practices. Gatekeepers are defined as companies which have a clear position of influence in a given market (based on revenue / market cap / number of users thresholds), and “an entrenched and durable position”. The process for designating which companies count as gatekeepers will start in May 2023.

The DMA touches upon different key topics, from self-preferencing behaviour to app store management practices - but most importantly includes interoperability for “number-independent interpersonal communication services” (NIICS), otherwise known as chat and voice/video calling and conferencing services (social media was left out for now).

This particular workshop was focused on the latter: interoperability between messaging services, with the aim of getting the different stakeholders of the industry in the same place to discuss how the legislation could be implemented. The whole idea is to figure out a practical way in which WhatsApp could interoperate with iMessage, Google Messages and others, creating an interoperable communication network where users are no longer locked into communication silos and pick their preferred service provider without compromising on who they can talk to. \

About 900 people participated online, and around 80 people were present in person: the maximum the room could hold. It was particularly fun to see representatives from the whole industry turning up in person, including folks from XMPP, MIMI (the new IETF working group on messaging interoperability), MLS, us from Matrix obviously (alongside Matrix ecosystem representatives from Beeper and NeoChat!) - all together with the Body of European Regulators for Electronic Communications (BEREC), civil society representatives (like the Federation of German Consumer Organisations (VZBV) and European Digital Rights (EDRi)), mobile network operators, local network agencies, and obviously some of those who are likely to be designated as gatekeepers, such as Meta, Apple and Google.

So what was discussed?

All of the workshop proceeds were livestreamed and archived by European Commission’s webcasting service and released under the terms of the Creative Commons Attribution 4.0 International (CC BY 4.0) licence, so we’ve taken the liberty of republishing them split up into chapters so that folks can quickly refer to the discussion.

Panel 1: Introduction to horizontal interoperability between messaging services: goals, challenges and potential solutions

The first panel focused on setting up the scene and highlighting the challenges expected during the implementation phase, featuring Simonetta Vezzoso (Professor of Economics at The University of Trento), Chiara Caccinelli (Co-chair - Digital Markets WG at BEREC), Suzanne Blohm (Policy officer at Verbraucherzentrale Bundesverbands (VZBV)) and Jan Penfrat (Senior Policy Advisor at EDRi). There was a lot of emphasis around the risks of gatekeepers dragging their feet, or choosing the solution which makes it harder for SMEs or self-hosters to interoperate, as well as the challenge of introducing the new paradigm of interoperability for messaging without losing the usability aspect - see below for the full scope:

• 00:00 Welcome to the second DMA stakeholder workshop about interoperability between messaging services
• 08:03 Introduction of the panelists
• 09:26 What is the Article 7 of the Digital Markets Act (Simonetta Vezzoso)
• 26:35 Interoperability already exists in the EU, what can we learn from it (Chiara Caccinelli)
• 40:43 End user perspective and behaviour, benefits of the DMA Article 7, Challenges (Suzanne Blohm)
• 49:30 Benefits for end users, and an existing technical stack to build from (Jan Penfrat)
• 59:21 What the UI could look like (Jan Penfrat)
• 01:03:07 Question - Do users need an account on each network, or is it a true federation? (XMPP Foundation)
• 01:05:19 Question - What rule do you see for Telcos and for messaging services they provide?
• 01:10:07 Question - Does the term "user" include people running their own server/service? (Open Source Initiative)
• 01:14:50 Question - How to check the gatekeeper is not giving a suboptimal solution? (online question)
• 01:18:04 Question - Does user consent limit the power of Article 7? (Viber)
• 01:22:36 Question - Gatekeepers don't have an incentive to make appealing UIs for interoperability and might try to scare users away. Will it be addressed? (NLNet)
• 01:24:08 Question - People usually dislike popups, how to strike the balance between warning and upsetting them? (online)
• 01:27:51 Question - Have you been thinking about reputation models?
• 01:29:53 Question - Different apps use different E2EE protocols to differentiate. Could article 7 kill that differentiation? (online)
• 01:38:48 Question - What will be the paradigm of non discrimination?
• 01:33:10 Question - What about interoperability of RCS and Apple iMessage? (Orange)
• 01:34:44 Question - Do you take into account that there are not only company-run services, but also Open Source components? (Process One)
• 01:35:55 Question - What are the implications for non European users? (Beeper)
• 01:39:25 Question - Does the DMA only mandate interoperability for European users, even on a same platform? (XMPP)
• 01:40:36 Question - Will the interoperability be opt-in or opt-out? (Matrix)
• 01:41:50 Question - How avoid the standardisation to be taken over by commercial interests? (online)
• 01:43:43 Question - What will the timing look like for the DMA? (Cisco)
• 01:48:13 Question - What could be reasonable requirements for smaller services? (online)
• 01:49:00 Question - Where should gatekeeper gather to start discussion how interoperability will look like in practice? (OpenXchange)
• 01:51:11 Question - What about account portability, for users switching from one platform to another? (University of Rome)
• 01:54:53 Question - Is contact information part of the data gatekeepers need to share? (XMPP)
• 01:56:12 Closing

Panel 2: Exploring the technical aspects of interoperability (Part 1): end-to-end encryption, security of the service

Then, after a quick lunch, the second panel went into the nitty gritty of how end-to-end encrypted interoperable messaging (1:1 messaging is the first milestone to be delivered, hence the focus) could actually be implemented by the gatekeepers. The panel starred Paul Rösler from FAU Erlangen-Nürnberg, who gave a great overview of end-to-end encryption in general, Alissa Cooper from Cisco who explained the merits of open interoperable protocols, Eric Rescorla from Mozilla explaining the merits of standardisation, yours truly from Matrix explaining and demonstrating how one can actually use a standardised open protocol to interoperate without sacrificing privacy (effectively fleshing out our blog posts from last year) and then finally Stephen Hurley from Meta to explain how they are thinking about DMA obligations.

The panel ended up being a relatively exciting tour through the landscape of DMA practicalities, and it was a lot of fun to actually demonstrate a minimum viable prototype of client-side bridging thanks to Travis’s work packaging up standalone client-side bridges for WhatsApp and Google Chat (strictly for demonstration illustrative purposes only). The slides (and demo) were sadly a bit fuzzy on the recording, but you can see our slides below and grab everyone’s presentations from the European Commission website:

When DMA first became headline news last year, there was a lot of very vocal concern that it would somehow end up undermining end-to-end encryption (despite the legislation explicitly requiring that E2EE must be preserved when interoperating). Hopefully this session demonstrated that both the European Commission and the various panellists are dead serious about achieving interoperability without sacrificing privacy - whether that’s via the brute-force approach of client-side bridges, or the more sophisticated approach of client-side bridges which bridge to client-side APIs, or by incrementally or entirely adopting a true open standard protocol like Matrix, XMPP, or whatever MIMI comes up with.

You can see the whole panel split into the various sections below:

• 00:00 Opening
• 01:23 Introduction of the panellists
• Interoperable Messaging - Paul Rösler (FAU)
• 03:10 Interoperable end-to-end (E2EE) encryption options (Paul Rösler)
• 05:24 Requirements for interoperable E2EE (Paul Rösler)
• 09:22 Options for interoperable E2EE (Paul Rösler)
• 13:54 Confidentiality, Privacy & Abuse prevention (Paul Rösler)
• 19:07 Group Messaging (Paul Rösler)
• DMA Stakeholder Workshop: Interoperability - Eric Rescorla (Mozilla)
• 22:44 Learning from QUIC (Mozilla)
• 24:14 E2EE and interoperability (Mozilla)
• 25:50 Key Establishment in a E2EE interoperable system (Mozilla)
• 27:16 Message and media formats in a E2EE interoperable system (Mozilla)
• 28:30 Identity in a E2EE interoperable system (Mozilla)
• 30:49 Multiple gatekeeper scenarios (Mozilla)
• 31:41 Suggested framework for interoperability (Mozilla)
• DMA Stakeholder Workshop: Interoperability - Alissa Cooper (Cisco)
• 35:20 Discussing how the UX of a DMA compliant product can look like (Cisco)
• 36:38 The use case for enterprise interoperability (Cisco)
• 30:47 Approaches to DMA Compliance (Cisco)
• 43:57 Limits of the per-gatekeeper, in-house solution approach (Cisco)
• 48:19 Strengths of the consolidated (standardised) solution (Cisco)
• 50:00 Implications & requirements of the consolidated solution (Cisco)
• Implementing Interoperability for the DMA - Matthew Hodgson (Matrix)
• 52:03 Implementing Interoperability in practice for the DMA (Matrix)
• 53:00 A practical path to full interoperability (Matrix)
• 54:35 Defining the problem we're solving (Matrix)
• 55:15 Approach 1 Client-side bridging using server-side APIs (Matrix)
• 57:21 Approach 2 Client-side bridging using client-side APIs (Matrix)
• 58:48 Approach 3 Polyglot app, using a 3rd party protocol à la iMessage (Matrix)
• 01:00:06 Approach 4 Using an open protocol (Matrix)
• 01:00:42 Pros & Cons of each approach (Matrix)
• 01:01:55 DEMO of client-side bridging (Matrix)
• Meta's view on the DMA as seen from WhatsApp - Stephen Hurley (Meta)
• 01:06:45 Meta's view on the DMA as seen from WhatsApp (Meta)
• Questions
• 01:17:12 Matthew (Matrix) remind that not only the demo showed client-side bridging was possible, but iMessage has been doing it for years via SMS & iMessage
• 01:17:54 Meta has two IM platforms (Instagram and Facebook) that are not E2EE. What is Meta going to do about those platforms? (Beeper)
• 01:18:45 How to balance discoverability and privacy?
• 01:21:04 How to solve the problem of different E2EE protocols? (online)
• 01:24:48 Do some of the panellists think the best option is not a single standardised protocol? (OpenXchange)
• 01:33:46 Which measures by gatekeepers to preserve security integrity and privacy can be considered proportionate?
• 01:36:38 How many people have worked on the client-side demo?
• 01:38:56 Does it really matter that MLS is not "done"?
• 01:47:30 How will article 7 ensure private keys will never transit over the network? (online)
• 01:53:00 What about interoperability of features like custom emojis, removing messages, etc? (online)
• 01:57:42 What does the rest of the panel thinks about the guarantees they can provide when a message leaves a system? (XMPP)

Panel 3: Exploring the technical aspects of interoperability (II): data collection, identification of users, quality of interoperable services, system management, integrity of the service/prevention of misuse

Finally, we launched into the third and final session of the day - a second technical panel to dig into questions of identity, usability, data privacy, consent and anti-abuse in a DMA world. Relative to the second panel, there were more questions than answers here, as the panellists discussed whether users would need to consent or opt-in/opt-out of interoperability, and debated the various data privacy implications of DMA. The panel starred Stephen Hurley from Meta again, Lucas Verney from PEReN, Markus Klein from Bundesnetzagentur and Rohan Mahy from Wire introducing the MIMI working group at IETF.

• 00:00 Opening and panellists introduction
• Meta / WhatsApp
• 02:21 User Safety on WhatsApp
• 06:51 Consenting to interoperability
• 07:56 Objective criteria to assess whether a request is reasonable or not
• PEReN
• 09:00 PEReN is a French government digital expertise hub
• 10:12 Efficient design for effective interoperability
• 11:25 Reconciliation identity between services
• 13:40 Discoverability between platforms of different scales
• 16:27 Should fancy features (e.g. emoji reactions) be interoperable?
• 17:22 Quality of Service
• 19:02 Security goes beyond E2EE
• Bundesnetzagentur
• 20:26 Bundesnetzagentur views on the DMA
• Wire
• 26:39 Federation and Interoperability issues are similar
• 28:10 Standards-based interoperability and the MIMI working group
• 29:18 Identifiers, devices, handles
• 30:50 User introduction & discovery
• 31:30 Messaging content
• 34:06 Why MIMI picked MLS for E2EE?
• 35:54 Server to server transport mechanism
• 36:38 E2EE Cryptographic identity
• 39:00 MIMI's standardisation work provides a strong foundation for other features
• 40:25 Why is standardized interoperability beneficial?
• Questions
• 44:30 What about terms of service, minimum usage age enforcement etc?
• 48:03 How can identity be maintained separately from networks? How will differing policies of services be respected?
• 52:26 Does WhatsApp rely on the phone number as a primary identifier?
• 53:29 Some systems like Telegram have pseudonymous IDs. How would that work with platforms relying on e.g. phone numbers?
• 55:42 Should the service name be part of the identifier?
• 57:33 Can the DMA improve how authentication is handled?
• 59:51 What made the GDPR successful is the potential fines. What about the DMA?
• 01:03:48 How can interoperability be designed to stop leaking contact lists?
• 01:09:15 Are we doing cookie banners again?
• 01:15:57 Should we think about some integration with eIDAS for more trustworthy identities?
• 01:19:48 Are all the protocols like Matrix or MIMI free to use, or do they have a fee?
• 01:22:32 Are there really concerns about the DMA and security?
• 01:27:40 Does Meta expect to provide a EU-only and a global version of their messengers?
• 01:29:55 The views expressed here regarding consent are concerning when it comes to self-hosting
• 01:36:20 Closing

Conclusion

This was a fascinating opportunity to have a front-row seat at history being made, as the various key players finally got down to business on the practical implications of DMA interoperability.

We saw the full spectrum of options on the table, from Meta’s implications that they would simply open their existing API complete with the existing Double Ratchet Encryption, to the pragmatic approach of Matrix (“at first we’ll bridge, and then the players should gradually converge on an open standard”) to the more idealistic approach of MIMI (“everyone should natively adopt an entirely new open standard built on MLS”). The next step is to establish a reference implementation and approach, and in the end it seems likely that the approach that works will be the one which the gatekeepers can actually practically adopt within the punchy timeframes built into the legislation:

You can also check out Carl Schwan’s writeup (from NeoChat), as well as Eric Rescorla’s braindump on DMA interoperability that accompanies his talk.

We live in interesting times, and it’s fascinating to see Matrix’s vision of interoperable communication being cemented into regulation by the EU. Our view is that as long as the gatekeepers open their APIs and add support to model remote users in their systems, then at least the wider world can implement client-side bridges to crack the door of the gatekeepers open - and then as gatekeepers refresh their stacks and new players emerge, they’ll likely implement the common protocol (if it’s fit for purpose) rather than burn time reinventing the wheel on proprietary solutions. Meanwhile, the DMA provides welcome encouragement to ensure that open protocols like Matrix can rise to the challenge and fill the gap - whether that’s independently or as part of IETF’s MIMI initiative. May the best solution win!

Note: This was originally posted on https://blog.neko.dev/posts/matrix-year-in-review-2022.html , which also includes some small info boxes about each projects, which got lost in the translation.

As we send off 2022 with a bang, it makes sense to look back on what we did this year and where we want to go next year. In its holiday special post, the Matrix Foundation has been focusing on the core team's work. This post is focusing on the achievements of the community outside of the Matrix Foundation.

I tried to reach out to as many people I have seen do "stuff" on Matrix and have them write something they would see fitting for a year in review. Now, most people have better things to do between christmas and new years, so I hope you can excuse if some projects are missing. Also I probably forgot like half of the interesting people... HOWEVER! I hope you still enjoy what everyone wrote up. And don't forget to check out the official Matrix Holiday Update 2022 and of course read you weekly TWIM to keep up to date with any cool projects you find.

Nheko D-Bus API

A D-Bus API for the Nheko Matrix client compatible with KRunner and Rofi.

LorenDB tells us

As a dedicated user of all things KDE, I make heavy use of KRunner. Naturally, I wondered if KRunner could be extended to join Matrix. This idea led me to create a D-Bus API in nheko for use on Linux. While it currently only supports a few aspects of the full Matrix experience, this API allows external software to make use of some of nheko's functionality, including searching the room list, opening rooms, joining rooms, and creating DMs. Later, I also added support for setting status messages. Now you can write extensions for software such as KRunner or rofi. Alternately, you could make a plugin for your favorite game that sets your status message to let your friends know that you are busy (although no known plugins of this sort exist).

Community Moderation Effort

A collaborative effort to moderate Matrix communities and to fight spam.

Nico mentions

Some of you might have heard of us, but we are a few moderators of very different communities, who have banded together to fight spam and share the burden of moderating our communities. Different opinions are very hard to align, so we have one ban list we can agree on, that only includes the most annoying spam reasons: automated spam, crypto advertisements, gore posting and similar stuff. This actually works very well against spammers, that just join one room after the other to send the same content.

You can subscribe to this ban list here:#community-moderation-effort-bl:neko.dev

We are sometimes internally discussing moderation rules, tooling and recent events. In the long term we hope to improve the tooling situation as well as provide a second, stricter ban list, but we are also already very busy just moderating our own little communities, so don't expect much progress.

If you have a community that has been troubled by organized spam recently, maybe our ban list can help you. You might also be interested in contacting one of us to join the effort, just be aware that we are very careful in accepting new members. We hope you have a spam-free and enjoyable 2023!

Matrix Releasetracker

Release tracker that posts updates into Matrix rooms. ↗

Ananace contributes

The release tracking project that has been running basically non-stop since 2018 (barring a few periods of downtime due to complete database crashes), having tracked many millions of releases for at least five people from my personally hosted instance.

2022 saw the addition of plenty of additional release sources, as well as a complete refactor of the codebase to hopefully support even more sources going forwards. It now tracks loose repositories (signed tags, lightweight tags, and/or releases) on GitHub/GitLab/Gitea/plain git, as well as supporting the tracking of entire namespaces and user stars on GitHub/GitLab/Gitea.

2023 should hopefully see even more work roll in, with some code underway for tracking Docker images and Helm Chart updates, as well as rework of the bot component to have it offer more use.

Self-Host a Matrix Map Tile Server

FluffyChat implemented location sharing in Matrix last year. More recently, Element announced support for it. Interesting in Element's announcement is not only the mechanism for sharing a location data point, but also how their matrix clients would display a little map to the recipient and how they would support the case where the data for this map display could be self-hosted. This is a blogpost/guide to show how this could be done. ↗

JulianF mentions

I set up my own OpenStreetMap tiles server for secure location sharing with Matrix.

See this guide on my blog which explains why and how I did it, and the Ansible role, and the matrix discussion room #matrix-map-tile-server:foad.me.uk.

Matrix ClassDojo Bridge

This bridges ClassDojo teacher-to-parent messaging facilities to matrix. ↗

JulianF mentions

I began a project to bridge matrix to the teacher-parent messaging silo ClassDojo, which is popular especially in USA and UK schools.

Matrix ClassDojo Bridge

I am motivated by my loathing of being coerced into putting my private communications in yet another silo where I am restricted to accessing my messages and photos through the company's own products which subject me to advertising and engagement tactics ("Your child earned a point -- click to see what for!"), where I cannot easily keep my own copy of my own data ("Subscribe now to keep your memories!"), and all the other typical down-sides of a Big Tech silo.

This scenario is of course exactly where Matrix shines. An ideal fit for a school's messaging needs, scrapping the silo business model, putting the organisation in control of its own data and policies.

In the first half of 2022 I got as far as being able to do an offline demo -- manually running the fetching and bridging stages, with the teacher and class names, story text and photos bridged in the to-matrix direction.

My work on this was generously sponsored by my wife.

Since then, the project has been on hold, seeking further funding.

My next step plan for the bridge, when I can get back to it, is to adjust the bridged output to the matrix-for-social-media formats used in FUTO Circles (previously "Circuli") and MinesTRIX to present a familiar and beautiful display.

Aine's update

Aine, one of the people behind etke.cc gives an update about what happened in the project this year as well as their contributions to matrix-docker-ansible-deploy. ↗

Aine contributes

Ohh, I don't even know where to start and what include, to be honest 😁

The most notable changes were:

• etke.cc/scheduler brings control over maintenance service and running services to customers. It changed our internal workflows a lot
• multilingual support of etke.cc - website, guides, order processing, support. Initially we had 3 supported languages (English, German, Russian) and then dropped Russian
• a lot of new components in mdad, starting with cinny and Borg backup and finishing with postmoogle
• we developed several new bots and matrix-related tools

... Actually, a lot of things were done and much more is in progress, not sure if I can speak about upcoming changes

So, 2022 was awful, scary, heartbreaking (in a bad way), but it also was quite productive

Pauls Podcast (German tech podcast)

A German tech podcast, that talks a lot about Matrix, but also a few other miscellaneous topics. ↗

jaller94 shares

In the beginning of the year I started a hobby podcast. Most episodes cover Matrix topics, e.g. the release of Matrix Spec v1.2, the FOSDEM 2022 and the Matrix Community Summit in Berlin.

https://chrpaul.de/podcast/

Matrix dev room at FrOSCon 2022

Every year free and open source software is celebrated and talked about at the FroSCon conference near Bonn. There was a dev room dedicated to Matrix this year. ↗

jaller94 tells us

Every year free and open source software is celebrated and talked about at the FroSCon conference near Bonn.
Thousands of enthusiasts meet on a university campus for one weekend to listen to presentations, talk in dev rooms and inform themselves at booths.
One ecosystem and community not to miss is Matrix. We've had a dev room where plenty of developers, server admins and newcomers exchanged their ideas and wishes for the protocol, implementations and other aspects of Matrix.

Room link: #FrOSCon:fiksel.info

Thanks to the speakers who represented Matrix on stage! Thanks to Oleg for continually representing Matrix at FrOSCon each year! Thanks to Yan for joining me last minute and making the dev room 300% more awesome!

Bram's updates on Elm and activism

A Matrix SDK in Elm. ↗

Bram mentions

Experience as a digital activist

At the Matrix Community Summit 2022, I gave a talk on the struggles as a digital activist if trying to explain concepts like Matrix to politicians. The talk went very well!

I was really impressed by the knowledge and passion that many of the attendees at the Matrix Community Summit displayed, and I feel grateful to have had the opportunity to learn from and such an engaged and informed group of people. I am confident that the insights and perspectives shared at the summit will be invaluable to my activism moving forward, and I hope to have the chance to work with many of you in the future as we continue to strive for a more just and equitable world.

Implementing Matrix in Elm

For the past year, I have been looking for ways to implement a Matrix SDK in Elm. Elm is a functional programming language that promises to compile to lightweight JavaScript that raises zero runtime exceptions. This has been quite a learning process and I'm hoping to release a beta version early 2023.

From the past year of trying to build a functional language library, I've learned that:

• The Matrix spec is surprisingly easy to implement in a functional programming language;
• There are still a lot of ambiguities left in the Matrix spec that aren't that big of a deal for imperative programming languages, but can mess up your codebase if you're a functional programmer;
• There appears to be a need for some single-use clients that are very good at doing a single thing. (Sending automated messages to multiple clients, moderating permissions across multiple rooms, auto-sending policies, exploring unknown access tokens).
• A lot of SDK development still revolves heavily around Element and Synapse implementation. Some events weren't part of spec yet while already widely implemented because either of those two codebases supported it.
• The Elm compiler is VERY strict and unforgiving, which can be annoying at times but creates some very robust results. My hope is that rolling out client implementations will be relatively quick and easy as soon as the SDK implementation is ready.

Progress on the Elm SDK can be found over here but will be updated in TWIM as well. You can also view my side project of a custom event type directory over at https://matrix.directory

Nico's delight initiative

Random Matrix related updates from Nico.

Nico mentions

Nobody enjoys encountering bugs on a platform they use. So one of my goals for 2022 was to fix some of the bugs I hear often about in the hope it improves the reputation Matrix has. This often involves projects or functionality I don't personally use, but that I can still contribute to. I think I made some progress on it. For example I fixed a bug that prevented all calls using Element Web on servers, that were not Synapse. Similarly I opened a pull request to Element Android repo, where users would get pinged by replying to a user whose userid starts with a room ping like @roomba (however that sadly isn't merged yet). I also made various fixes to Synapse, especially related to notifications.

More long term I tried to push dehydrated devices forward (partially because of my day job) by implementing the second iteration of it: MSC3814: Shriveled Sessions as well as writing MSCs to one day get rid of reply fallbacks (by deprecating it and with support of MSC3664 allow for better control over notifications from replies. Similarly I pushed forward MSC3266: Room Summaries to improve the experience when joining rooms via knocking or restricted joins or just previewing rooms in general. (I implemented the federation parts of that MSC in Synapse as well as in several parts of Nheko).

My current work is on improving presence, since that has some fun edge cases. Fingers crossed that works out next year and I find a few more things to drive by fix. Do you have anything you have seen come up often? Maybe 2023 is the year to try to fix one of the bugs you encountered far too often? It is always easier to fix stuff, that has been annoying you, so why not try and make your own life on Matrix a little bit better? Most projects are pretty open to contributors and it also often teaches you some new skills, so there is nothing to lose but lots of time!

Valheim Matrix Bridge

A Valheim (the game) to Matrix bridge. ↗

Nico mentions

I built a Valheim Mod to bridge Matrix messages from and to Valheim, so that I didn't have to switch windows as often when playing with the other Nheko devs. You can find it here: https://nheko.im/nheko-reborn/valheimmatrix

Postmoogle

An Email to Matrix bridge. Postmoogle is an actual SMTP server that allows you to send and receive emails on your matrix server. It can't be used with arbitrary email providers, because it acts as an actual email provider itself, so you can use it to send emails from your apps and scripts as well. ↗

Aine reports

At etke.cc we love matrix, but have to use email as well, especially for some notification things and communication with customers. Let's face it: email ecosystem is awful, there is no really usable and nice looking email clients that allow you to collaborate and use "hivemind" to work on emails, there is no simple backend implementations that will just work with simple configuration, and you have to dig into all that stuff on your own to understand how it works and configure it...

So, we already had experience in bringing stuff into matrix and we decided to do the same for email, that's how Postmoogle was born.

Of course, there was email2matrix, but it's too hard to configure and it's intended only to receive messages.

Our "20 minutes adventure" to develop it was a hell ride with several weeks of nearly full-time working on it even on weekends, and during that time we literally studied SMTP protocol using RFCs, Wikipedia and source code of other mail servers (shoutout to Maddy - you guys did amazing work!).

It was a tough fight, but the result is satisfying - you can get an email server that handles 99% of usual email cases and uses matrix as frontend.

So, what's the result?

• we use Postmoogle for customer support
• we offer it to customers
• we have cases when people ditched regular email service (like gmail) and use postmoogle as the only email account

Of course, we have other ideas with it, but even now it's pretty satisfying results

Halcyon

Halcyon is a python matrix library made with the goal of being very easy to use, and requiring no local databases. ↗

gen3 mentions

Halcyon is a python matrix library made with the goal of being very easy to use, and requiring no local databases. 2022 brought a few key features that made it usable for general usage in unencrypted room (We reached milestone 2!).

• Query for room information, with automatic background updating in a local cache. (ex, get the room name, admin, moderators, etc)
• Improved polling for reduced server usage and for connection with slow internet
• Image sending functionality with automatic blurhash and thumbnail generation
• More examples
• More documentation!

Come chat with us in https://matrix.to/#/#halcyon:blackline.xyz
Find the library here: https://github.com/WesR/Halcyon

f0x' year of not-so-much Matrix

f0x gives an update about their Matrix (and not-so-much Matrix) projects.

f0x mentions

Looking back I realized I didn't do much with Matrix at all this year, besides actively using it as my main communication platform.
matrix-streamchat had some commits at the start of the year but got abandoned shortly after. I stopped streaming myself, and others I knew
mostly used Owncast which had it's own chat, which got some neat ActivityPub integration soon after too.

synapse-media-proxy also had very little changes, but that's quite good, because it's been very solidly running in production for more than a year now,
running all the Matrix media for https://pixie.town.

There's some stuff on the ops-side; worked on a refactor of my NixOS modules for Synapse with workers (not quite working yet). Moved all my bridges to a new NixOS host. (Barely)
maintained my matrix-appservice-irc fork, and got some nice clickfarm-supplied Haiku's
from a bot re-using an account because I still haven't gotten around to giving it it's own access token..

Successful registration for jamessemith70 ([email protected])
5, Frigid winter night—
7, even the thieves stay at home,
5, except for those two

In my non-Matrix time I've been working a lot on the frontend and settings interface for GoToSocial, FediFox Masto-api client and Masto-api compatible alternative frontend FediFox Shield. Article about the latter: https://cthu.lu/projects/fedifox-shield

Gwmngilfen's Matrix Year

Gwmngilfen gives an update about their work on Matrix in 2022.

Gwmngilfen tells us

While 2021 was a big year for me in Matrix, 2022 has been one of steady progress on various projects. Being a community architect, much of those projects are "communities on Matrix" rather than code, but hey! We need users 😀. So, here's what I've been up this year...

#space:ansible.com

Ansible started on it's Matrix journey last year but the arguments I made then have proven solid. The community has seen steady decline in the number of IRC users, but a steady rise in the number of Matrix users - enough to make a positive trend overall. As of last month, we're now at over 50% of unique MXIDs talking each day coming from Matrix vs IRC. That's a huge milestone to have reached in just over a year!

We also used Matrix as a key part of our message to the wider tech landscape as part of our Keynote at AnsibleFest. I don't want to make this too product-y, but you can check out that video here and also the interview my colleagues Adam and Carol here (that's worth a look, Adam crowbars Matrix into almost every sentence 😁)

Steady progress isn't eye catching, but I'm so pleased that the move has been a positive one, and I hope it continues in 2023.

#rlang:matrix.org

Since part of my work involves doing data science, I've also been trying to boost the presence of the Rstats world on Matrix. The community there is small so far, but we're super supportive and trying to build out our presence. My eventual goal is to make it big enough to be worth setting up a bridge to the larger Slack R4DS community (R for Data Science), but we're not there yet. If you use R at all, come see us!

ChatStat for data on your Matrix Rooms

The one Matrix project I did get done this year (although it hasn't been updated in ... a while) is an R library for producing reports on Matrix rooms. I use this for gathering data on the Ansible community regularly, and it comes in two parts. The first part is the API calls to get all the events for a set of rooms over a given time and arrange it in a nice rectangular format. The second part uses this tabular data to produce reports on when people talk, who talks the most, and so on. It's been very useful to me over the past few months to show how the trends I talk about above have developed.

Carolinacon in matrix

CarolinaCon is a yearly cybersecurity conference hosted out of North Carolina. Since 2004 CarolinaCon has been host to talks ranging from BioHacking, to developing OpenBSD, to Web app security, and beyond. Over the years we have run a wide range of events, mostly in person. The past two years we decided to run the conference online. ↗

gen3 mentions

whoami

CarolinaCon is a yearly cybersecurity conference hosted out of North Carolina. Since 2004 CarolinaCon has been host to talks ranging from BioHacking, to developing OpenBSD, to Web app security, and beyond. Over the years we have run a wide range of events, mostly in person. The past two years we decided to run the conference online.

How did we use matrix?

We decided to run a homeserver bridged with our discord. We wanted to take careful consideration to users who have never used matrix before, and offer some background information to enable them to use it even if they were feeling unsure. Along with running our own homeserver and element instance, We also made a Space that users can join to automatically see all the rooms available for the conference. When a user creates an account on our homeserver, they are automatically placed in a few key rooms such as the Space, #CTF, #general, and #announcements. Check it out on https://carolinacon.org/coms.html

We didn't want anyone to feel left out, so all rooms are mirrored. One challenge this faced was getting permissions to work properly with rooms such as #announcements. The usage of a Space was generally positive in terms of increasing room desirability in Matrix. It was also nice to be able to include the local 2600 room into our space, something that we couldn't do with Discord.

Stats

We already had a large userbase on discord, but still had good user interaction on both sides. 150 users interacted in the #general chat. Of those users, 113 were from discord. Of the 37 Matrix only users, we had 7 separate homeservers. Its really cool to see that people who where already on Matrix, decided to federate in. Almost all homeservers had more then one person join, which is good to see.

In the future as we go back to in an person conference, we will continue to run the an online portion. The community seemed to really enjoy it, and we consider it a success as we were able to increase our outreach to world wide. Check us out at https://carolinacon.org/ , we would love to chat!

Google-free push notifications with UnifiedPush and Ntfy

Using the UnifiedPush open standard, ntfy enables self-hosted (Google-free) push notifications. ↗

JulianF reports

In the interests of supporting Open Tech in general, I made a small contribution to matrix-docker-ansible-deploy: it can now install the ntfy push notifications server for you.

To explain what it's for: Using the UnifiedPush open standard, ntfy enables self-hosted (Google-free) push notifications. The notifications go from Matrix (and other) servers, to our self-hosted ntfy server, and then straight to our phone. Especially useful for users of Google-free Android phones, and others who want to reduce their dependence on big tech.

To set it up, see Setting up the ntfy push notifications server in the playbook docs.

Read about it on my blog: UnifiedPush notifications for your Matrix server with ntfy.

Paul's updates and blog posts

Paul shares what they did in 2022. ↗

Paul mentions

I haven't had much time, but I did write two tiny projects and small blog posts: https://paul.totterman.name/posts/matrix-menu-bot/ & https://paul.totterman.name/posts/remarkable-matrix/

Open Tech Will Save Us on PeerTube

Hosting of the Open Tech Will Save Us talks on PeerTube. ↗

JulianF mentions

https://wrily.foad.me.uk/open-tech-will-save-us-on-peertube -- I am publishing the Open Tech Will Save Us (OTWSU) talks on an Open Tech platform — namely on my own instance of Peertube. -- Thanks to Harald for doing it first. -- This article talks more about why, how, etc.

This Year in Trixnity

Trixnity is a multiplatform Matrix SDK written in Kotlin. You can write clients, bots, appservices and servers with it. This SDK supports JVM (also Android), JS and Native as targets for most modules. Ktor is used for the HTTP client/server and kotlinx.serialization for the serialization/deserialization. ↗

Benedict mentions

Trixnity made some huge steps towards a fully featured cross platform matrix SDK written in Kotlin.

Starting with version 1.0.0 in January I added support for cross signing, secrets and key backup.

Version 2.0.0 in April included a large refactoring. This allows you to share a lot code between server and client implementations of the Matrix APIs. For example you can now implement a server with Trixnity. Also Olm has been bundled into most release files, push rules are evaluated, there is a new better TimelineEvent retrieving API and many more. JS has been enabled for the last module, so Trixnity is now fully multiplatform capable. With v2.3.0 dependency injection has been added to Trixnity to make it even more configurable.

The next big release 3.0.0 was in November. We added support for realm as database backend (e. g. for iOS), allowed to exchange the MediaStore, calculate power levels and many more. Some APIs in trixnity-client has been purified, because I improved the StateFlowCache. The developer experience has increased even more with 3.1.0 in December. It adds a completely new Timeline abstraction.

Matrix Community Summit 2022 Berlin

The Matrix Community Summit 2022 in Berlin was a conference entirely focused on Matrix. ↗

jaller94 contributes

Where do I even begin? This has been such a great and fun event.
On the last days of August more than 60 Matrix enthusiasts from various countries met at c-base in Berlin.
We started with a Barcamp day for attendees to discuss spontaneous topics.
The highlight have been two days with 36 presentations and workshops on three stages.
Check out the schedule, if you want to contact some of the speakers: https://cfp.summit2022.matrixmeetup.de/matrix-summit-conference-2022/schedule/
Thanks to all attendees for the great conversations we've had! Thanks to all presenters for a schedule full of Matrix knowledge! Thanks to the c-base hackerspace for hosting us! Thanks to the sponsors for paying for the food and drinks!

For those who missed this in-person event or wish to revive some of the memories, we're publishing interviews with some community members as a podcast.
In total there are 2 English and 6 German episodes, the last one being published on Fri, 3rd Jan 2023.
https://anchor.fm/matrix-podcast0

Nheko

The motivation behind the project is to provide a native desktop app for Matrix that feels more like a mainstream chat app (Element, Telegram etc) and less like an IRC client. ↗

Nico reports

What a year, eh? I don't know if as much happened in your lives as did in mine, but certainly stuff happened! And that certainly was the case for Nheko too! There have been plenty of new and returning faces. Before I go into more detail what happened with Nheko, I'd like to prefix it with a thank you to some specific people, who noticeably contributed to Nheko in the last year on a regular basis:

• LorenDB, who while causing us a lot of trouble by breaking stuff, also tackles many of the more annoying issues and brings a lot of creativity to problems and their solutions.
• MaltE, who despite being usually busy, reworked most of our mobile UI and gave Nheko a pretty bubble mode.
• q234rty, who seems to have a solution to every issue and even upstreamed some of those patches to the KDE Qt collection, so that some of the annoying Wayland bugs won't bother many users anymore.
• Linerly, Priit and many of the other translators, who tirelessly keep our translations up to date, even if they have to re-translate whole paragraphs after I fixed a single comma...
• And many of the other contributors and the community, who report and fix issues as well as just make the whole journey more enjoyable!

Now with that out of the way, where are we going?

Nheko got plenty of new features, even though some of them I tried hard to avoid for a long time! For example you can now send confetti. I prefer to toggle that off, because I think it can be distracting, but it is undeniable, that it looks very fun and fun is very important!

Another one is threads. Nheko now supports them, but I would have liked for threads to work differently. Some features, like notification counts for each thread, we skip out on, since it seems very hard to support well. Instead we integrate threads into the timeline and you can filter them out. Ideally threads would behave like dynamic subrooms, with titles and listed below the room list entry, but that seems not doable with the current design of threads in the specification. So we chose a design, that is still useful, but doesn't run into such limitations.

Apart from that we really started investing into our communities support (which is how we call our UX for spaces). While showing communities as a filter is already useful, you can now also modify those filters. Nheko now shows you notification counts, suggests you to join the space for a community (if possible) and allows you to apply permission changes across the whole community.

Speaking of permissions, we invested a lot into improving our management and moderation tooling. With this you can now fine tune join rules for a room (with toggles for knocking, restricted joins and more), edit the permissions using a role-like interface, edit the addresses for a room, edit your sticker packs and more. You can also knock on rooms now, which is a way to request access to a room without it having to be public or manually messaging someone for an invite and we can now show policy lists.

Oh, one thing that definitely deserves a mention, we had our first official CVE! Now, you might think that is not worth celebrating, but it does feel like Nheko is growing up. Partially this is thanks to Github making it easy to file CVEs for security issues though. Who would have thought we ever would have our own CVE entry? We certainly need to improve our test coverage and hardening against such issues, though to be fair in this case I pretty much already wrote a comment about what the problem would be, but just didn't fix it properly... We however are also constantly improving our encryption in general, so hopefully it only becomes more secure from now on. Part of that is fallback keys, which make it easier to come back after a long period away.

Nheko now also evaluates notifications locally. This is especially great for encrypted rooms, since before the server mostly guessed what should notify or not. But it also means you get highlighted when mentioned now, which makes it much easier to find where you were notified. We also now have a line where you last left off reading the room, which is much more useful than I initially wanted to admit and I use it a lot. We also have experimental support for MSC3664, which allows us to hopefully eventually get rid of reply fallbacks, by evaluating the reply relation instead of relying on every message to include the name of who you replied to for highlight purposes...

We also improved performance, however as always anytime you do, you end up adding features, that slow you down again. However current Nheko should still start up significantly faster than 2021 Nheko.

Speaking of improvements, we have made a few for macOS this year. Apple Silicon is now natively supported, so Rosetta is no longer needed to run Nheko. This means improved battery life and performance! At least on Apple Silicon, launching Nheko on macOS should now be roughly as fast as Alt+Tab-ing to another window. Additionally, you can now reply to messages straight from the notification in the Notification Center.

One thing I didn't imagine we would ever have is a D-Bus API. This means you now can do some limited interactions with Nheko via the D-Bus API, like switching rooms using KRunner or Rofi! For FOSDEM we also added some support for widgets, because I wanted to be able to participate in the online FOSDEM without running a second client. This however is an incomplete experience, since... why run a browser in Nheko, if you have a perfectly capable browser client you can use for widgets? Nheko just shows you how to open a widget in a browser.

As already mentioned, we also significantly improved our support for the PinePhone. We now have a bubble layout, which looks better on mobile than the normal layout without bubbles. There has been significant work to make dialogs fit on mobile screens as well as allowing interaction using touch in almost all places. If you want to play with a PinePhone, definitely give Nheko a try and tell us, how you like it!

You might have noticed that we spent a lot of work on moderation tooling and that is probably something we will continue. I have a lot of ideas on how to integrate policy lists with spaces as well as using them to auto-decline invites, automatically ban people and more. How cool would it be if you could ban people community wide using a "banned members" editor in Nheko that is compatible with Mjolnir? And have permissions in spaces apply globally, maybe with some tweaks based on room types? There are a lot of cool ideas out there and we will certainly be experimenting with them.

Another topic will be building out our call support. I want to be able to use Nheko for my gaming sessions. Just drop into a voice chat room and talk to each other. Maybe do my work conference calls, including presentations as well or do remote help for my parents and grandparents over Matrix! We also really need to support calls on other platforms.

Which brings us on the last big goal: We do want to eventually switch to Qt6. We did have a branch testing out how difficult that would be and it was doable, but we were mostly blocked on GStreamer not supporting Qt6 yet. This is fixed in GStreamer 1.24, which should be out soon, so this is probably the time we can start looking into finalizing the port. Qt6 will fix A LOT of Wayland issues and give us a lot of new optimization opportunities. Maybe that is the year we can get below 100MB RAM usage on my ever growing account and make every room switch feel instant.

Well... this was a bit of a long one? Certainly it wasn't the work of one person. The Nheko community seems to just be constantly growing and there are so many people contributing, that it really makes me love open source! Thank you! All of you! It has been a great year (Nheko wise) and I hope 2023 becomes even greater! Have a great year!

Timo Kösters' year in Matrix

Timo gives an update about Conduit and their year on Matrix. ↗

Timo on Conduit ⚡️ tells us

Hello everyone, I am the maintainer of the Conduit Matrix project and this year my goal was to make Conduit more reliable. I've released three major updates this year, going from v0.2 to v0.5:

For example, the admin room received a lot of love this year. It's a Conduit-specific way of controlling the Matrix server using a chat bot. Commands are parsed using clap and perform actions like creating or deactivating users, adding appservices or listing rooms.

Conduit now supports RocksDB as the database, which is better than the previous ones, but still has some problems. I have worked on a new database abstraction layer that would allow using PostgreSQL in the future.

I have also worked on all sorts of bug fixes. End-to-end encrypted chats work reliably, Server ACLs are respected, the user directory hides private users and so on.

These and many, many other fixes allow me to use Conduit for most of my Matrix interactions now and most of the issues I encounter are client and not server bugs, see https://conduit.rs/issues

My goal for 2023 is adding all the modern features we need to be competitive with Synapse, like threading, space exploration, registration tokens and so on.

I also want to contribute to the Matrix spec and implement my ideas in Conduit, for example changing state resolution to speed up room joining.

I can't promise to finish all of this next year. I will finish my Bachelor's degree next year and for now I'm a full time student working on these things in the remaining time.

Thanks to all my individual sponsors this year and to FUTO ( https://futo.org/ ) for making this worth it financially as well. https://liberapay.com/timokoesters

Sticker/emoji pack collection

Tastytea maintains a collection of MSC2545 sticker pack rooms and gives an update about how the experience has been so far. ↗

tastytea mentions

At the end of 2021 i made a room with a Blobcat emoji pack, and since i could not find a place to announce it, i started a space to collect rooms with sticker/emoji packs. It began with 3 rooms and under 500 images, but withMSC2545 getting implemented in more and more clients in 2022, the space quickly grew and we're now at 7 rooms with more than 30 packs containing over 2000 stickers and emojis!

One thing i didn't anticipate was that people started to request new stickers and sometimes submitted their own. We're not just collectors anymore but also the prime source for Blobcats on Matrix!^{[citation needed]}If you have a sticker room too, please drop by our lobby and tell us about it so we can list it and make it known to more people! Do you make your own Blobcats or want to learn how to? Visit my roomso we can spread the blobby joy together!

Meetups in Berlin

Berlin has a vivid Matrix community with not only one, but two Matrix meetups.

jaller94 tells us

Berlin has a vivid Matrix community with not only one, but two Matrix meetups.

Once a month, the Matrix User Meetup Berlin (MUMB) invites people to chat about Matrix and meet other users.
In summer this exchange of ideas and starting points into Matrix was sometimes combined with food from the BBQ grill.
For their upcoming events in 2023, check out the room #mumb:c-base.org. It takes place at c-base on the first Wednesday of a month.
Thanks to the organiser saces for bringing people together!

Furthermore, we have the Berliner Matrix Salon 🍷 (previously called Matrix Meetup Berlin, which made it hard to tell apart from the MUMB).
In the first half of 2022 we had regular meetups for developers and server admins to talk about their Matrix projects. This meetup eventually led to the Matrix Community Summit in August.
We still meet infrequently to discuss our projects and what public events we could host next. We'd love to host a series of presentations at various offices which also appeal to an audience outside the Matrix community (e.g. education, public sector and health care which have a growing Matrix adoption in Germany). Ping me or Yan, if you want to help by being a presenter, have access to an office or know of a particular audience in Berlin to bring Matrix to.
The room is #matrix-berlin:matrix.org. Feel free to ask when we're meeting next.

Sailtrix

Sailtrix is a Matrix client for SailfishOS. ↗

HengYeDev contributes

The following major changes have been applied to Sailtrix in the year 2022, in no particular order:

• Basic emoji verification
• SSO Login
• Create room
• Integration with Sailfish.Share API
• Room searching UI
• and numerous cosmetic improvements and bugfixes

This year in NeoChat

NeoChat is a client for Matrix, the decentralized communication protocol for instant messaging. It is a fork of Spectral, using KDE frameworks, most notably Kirigami, KConfig and KI18n. ↗

Tobias Fella mentions

It's been an interesting year, that's for sure :)

Let's start with some statistics:

Some quick git magic shows 689 commits for this year so far; Roughly 200 of those were for translations.

On the topic of translations, NeoChat is currently (almost) fully translated into 17 languages, with 17 others being in progress.

One of the major areas of work this year - like last year - has been end-to-end-encryption, which, as of last week, is released in libQuotient and NeoChat. This means that you can now read new messages and verify your session with other devices. You won't yet be able to recover from (most) undecryptable messages, we're working on implementing those parts of the matrix specification.

NeoChat's user interface saw major improvements this year:

The message list has been improved to be less buggy, adapt better to different form-factors and the different appearance options NeoChat offers, like the "compact" message style.

The compact style also recently gained a sibling in the equivalent style for the room list, which makes the list more compact by not showing the last message of the room.

Input handling has been overhauled, as a result user mentions are now highlighted while writing a message, making them more reliable and appear less magic to the user.

More new features include basic support for room search, improved emoji and reaction handling (including better emoji data, search and a skin tone selector), basic developer tools, support for showing and responding to polls and an improved account switcher. One of my personal highlights is support for collapsing large amounts of state events, which makes low-activity rooms significantly more pleasant to use.

On the moderation side, we've implemented support for reporting messages to the homeserver administrators and improved the kicking and banning support.

Progress on the space support has unfortunately been slower than hoped, with the only result of the GSoC project being the space list that is shown at the top of the room list. Space support will be one of the areas to work on in 2023.

Plasma users have gained some nice integration points with their desktop: File uploads and downloads will now be shown in plasma's job tracker, there is now a D-Bus runner for opening rooms, and you can share messages with purpose-enabled apps.

Finally, we've been working on improving NeoChat's settings. Visually, the application and room settings have been ported to newer components that look significantly nicer, especially on mobile devices. We've also added settings for configuring room visibility, join rules and notifications and added support for configuring a proxy to use when connecting to a homeserver.

In terms of contributors, this year was better than last year, with several people becoming active in development and bug reporting. We're especially excited about having been able to add James Graham as a third maintainer for NeoChat after all his work, focusing mostly on NeoChat's front-end and settings.

imbev's year in Matrix

imbev gives an update about what they have been up to this year.

imbev tells us

This past year I have worked on several projects using Matrix:

• matrix-rss-bridge
  • This is a bot that can be configured to watch RSS/Atom feeds and relay to Matrix rooms. It is written in Python, configured with a single config.toml, and licensed under the GPLv3.
  • I don't actively work on it, however I will review and merge contributions that improve the project.
• matrix-debate-bot
  • This is a bot that "moderates" discussion in Matrix rooms. It does nothing more than provide a signal every 2 minutes. Also in Python, interacted with via "command" messages, and licensed under the GPLv3.
  • Same thing as the previous project :)
• matrix-quicksetup
  • This is a docker compose file and a few config files to help setup a Matrix homeserver and client. The homeserver setup is Conduit, and the client is Cinny. I don't advise that anyone use this in a serious deployment, but if you want to quickly test Matrix entirely on your local machine, this may be useful.
  • Same as previous
• simplematrixbotlib
  • This is an easy to use bot library for the Matrix ecosystem written in Python. Having taken ownership of the project, I maintain the project with help from @kim:sosnowkadub.de, @moanos:hyteck.de, and others. Thank you for your contributions!
  • While I anticipate releasing version 3 of simplematrixbotlib, this next project has captured my focus recently.
• matrix-social
  • matrix-social is a Matrix "Social Media" client. It is a webapp written in Rust using WASM, Yew, and the Matrix Rust SDK. Inspired by the design of Reddit, matrix-social will provide a similar experience, but based entirely upon Matrix. By providing seamless interoperability with Matrix chat clients, matrix-social will extend the Matrix ecosystem without dividing it. matrix-social currently lacks crucial features that will be added soon.
  • I actively develop matrix-social and will be doing so for the foreseeable future. At the moment, I am porting the styling from the Bulma CSS framework to TailwindCSS for greater control. If you'd like to try out the current state of matrix-social, https://imbev.codeberg.page/matrix-social/ is available. Join us in the Matrix room #matrix-social:matrix.org !

Kitsune's year in Matrix

Kitsune, one of the Spec Core Team members and maintainer of the Quotient client for Matrix, gives an update about their work this year as well as some new projects.

kitsune mentions

This year hasn't been very productive for me (not in Matrix at least) but a few things are worth a mention.

Quotient

This year I finally got to diving into the (new) E2EE code for libQuotient that NeoChat fellows started writing back in 2021, and was quite happy to end up collaborating with Tobias Fella on making it even better, all the way to merging and releasing way overdue libQuotient 0.7.0. The best news for me in all this was not even getting E2EE to its first actually usable release but the fact that libQuotient is no more a one man show. And now that there's yet another libQuotient-based client (with much more solid traction than any client before), there's hope that the project will move on at a somewhat steadier pace.

Spec Core Team

I did my share of MSC reviews (much fewer than I'd like to) and carried on with my role of ensuring Element doesn't throw too much weight behind its contributions (although there are a few other people in SCT who seriously push for neutrality in things we work on; so that role is rather formal). One thing that I unfortunately did not find enough time to help with this year but I'm sure we'll make it happen in 2023 is to move our API definitions from Swagger (v2) to OpenAPI v3, ditching all the Swagger extensions we had to add - thanks to Kevin for driving this home.

CLUP.chat

About a year ago I was contacted by folks who wanted to use Matrix as a backend to bridge WhatsApp, Signal and Telegram for scout (and other) communities in Germany and asked me to be their technical advisor. Less than a year later we went live (you can connect the groups here), soon after ran into rate-limiting issues outside of Matrix (centralised networks, heh...), did the homework, and now busy making the whole thing worth charging money for. The backend is almost entirely vanilla code for Synapse and Mautrix-based bridges, plus a small website and a non-Matrix bot to onboard people.

Jae's year of Matrix

Jae gives an update about what they worked on this year. ↗

Jae (Beep) shares

Yet another year well spent on Matrix, which was a bit more dynamic than the previous ones.
From mitigating spam attacks to creating brand-new projects and also contributing to others, there's no shortage of news.

cert-monitor

cert-monitor is a small program made entirely in vanilla Python that checks the validity of your SSL certificates and warn you when they are about to expire.
The idea for it originated in a Matrix room in which the other administrator would usually forget to renew SSL (bringing down their homeserver).
The software can send notifications to e-mails and Matrix and other methods are in the works like NTFy (but a bit on stale since Matrix support was the main goal).

MSC3868: Room Contribution

The MSC3868 (currently still a draft) is a spec proposal by me and Aminda to add a way for rooms to advertise easily official links like code repositories, ways to contribute to translations, donations and more but only showing to users inside the room.
The start of it is that we noticed that usually users don't even bother reading the topic/MOTD of the room, which renders putting links inside of it just about useless in most cases.
The proposal is still being refined, but the big lines are there already!

gh-bot

gh-bot is a small bot made to be used with the webhook function of various Git forges (namely GitHub, GitLab and Gitea/Forgejo).
The bot itself is pretty simple and will just output new commits, new stars and build statuses in all the rooms the bot is.

hsl-matrix-notifier

hsl-matrix-notifier has a bit of an exotic use case: it is made to track problems with the Helsinki public transports company and warn about potential disruptions.
For now, it is very basic and is still being worked on to have a better version (like if no news, it will still post old stuff when I would like in term something more like an RSS feed).
When I move, I'll probably spin off this bot to make a local version or even build something, so it can be configured by city.

---

In the end, this year has been a very dynamic one in the Matrix world, and I can't wait to see what is coming next.
For my part, I don't intend to stop there, and I have even more Matrix related projects, so stay tuned!
Oh also, I almost forgot, happy new year Matrixians, stay awesome!

Cinny

Cinny is a Matrix client for instant messaging. Our main goal is to make the best UI/UX so that less technical folks can easily adopt Matrix. ↗

ajbura shares

Cinny is a Matrix client for instant messaging. Our main goal is to make the best UI/UX so that less technical folks can easily adopt Matrix.
2022 has been really productive year for Cinny, we have landed Full Spaces support, Room settings, Custom emojis and stickers, Session verification and cross-signing, and so many cool features.

Lately, we have been working on a design system for Cinny and it is almost ready to release. Our short-term goals for 2023 would be to incorporate the design system into Cinny, and convert the code to TypeScript both of which will greatly improve the developer and user experience.

You can join Cinny space to talk about it or browse https://cinny.in

2022 year in Nyatrix

Nyaaori ⚛️ tells us

• Initial workings on spec.cat
  • Intended to be a community-driven extension specification to allow for easier collaboration and client/server integration prior to submitting an MSC
  • Would allow for finalising community things even if they get little to no attention from SCT
  • Eventually will take over maintenance of Catalyst
• Initial work on decentralised trust/moderation system
  • Should work on under any federated system, not just matrix
  • Intended to reduce workload on moderators/admins
  • Makes use of a web of trust system, with each user or server being their own center of trust
• Catalyst (fork of conduit) progress
  • Cacophony

    • Implementation of Discord C2S inside a matrix homeserver

    • Marginally modified Discord web client can connect to it

  • Partial Dendrite API support

    • Allows using TARDIS

  • Room V10 support

    • => Upstreamed to Conduit

  • Support for private read receipts

    • => Upstream in progress

    • Partial support for displaying space hierarchies
  • Backfill to other servers via S2S

    • => Upstream in progress

  • Code refactor alongside Conduit
  • Many minor bug fixes

    • => Most upstreamed

• Initial research into designing my own matrix client
  • Intended to be extensible
  • Plugins/extensions should be installable via matrix itself
  • Eventually will be spec.cat's reference client

Ement

Ement or ement.el is a Matrix client for GNU Emacs, the classic-yet-ever-new text editor and Lisp environment. ↗

alphapapa contributes

Ement is a Matrix client for GNU Emacs, the classic-yet-ever-new text editor and Lisp environment. After a couple of years of off-and-on development, 2022 saw the first versioned release, published to GNU ELPA, the official Emacs package repository (so it's installable into Emacs "out-of-the-box," without any additional configuration).

This development was enabled by the maturation and publishing of Ement's underlying HTTP library, plz, also to ELPA. And another library, taxy, used in Ement for organizing rooms into meaningful groups for the UI, was also released to ELPA.

Along the way, Ement gained useful features like a helpful command menu based on the Transient library (the one used in Magit, the popular Emacs frontend to git), the ability to show and send images, files, and reactions, read receipts, room directories and searching, an improved notification system, fancy, configurable room grouping provided by taxy, and many other improvements and fixes.

As well, although Ement doesn't support E2EE natively, users have successfully used it via Pantalaimon, the E2EE proxy daemon, allowing Ement to be used with encrypted rooms.

Altogether, Ement now provides a stable, reliable client for Emacs users to "jack in" to the Matrix. Users and interested parties are invited to join the chat room, #ement.el:matrix.org, where users help each other and announcements are made.

Looking forward to 2023, it's planned to improve support for newer versions of the client-server spec. Sliding-sync support will be especially helpful for improving initial sync times, and the new event-to-timestamp endpoints will aid in searching room events and paging back in history by date. As well, the next stable release of Emacs, version 29, will include native SQLite support, and the author looks forward to investigating how that might be helpful for Ement (e.g. caching events locally, similar to Element).

And as always, like Emacs, Ement is Free Software, so contributions are welcome. Feel free to submit bug reports, feature requests, and other feedback on the repo's issue tracker and in the chat room.

Matrix Highlight

Matrix Highlight is a web annotation tool based on Matrix. It allows you to select and highlight text on webpages, as well as comment on it. Because it's built on Matrix, you can keep this information hosted on your own hardware, and highlight pages together with other users. ↗

Daniel mentions

Matrix Highlight is a web annotation tool based on Matrix. It allows you to select and highlight text on webpages, as well as comment on it. Because it's built on Matrix, you can keep this information hosted on your own hardware, and highlight pages together with other users.

This year, Matrix Highlight switched to manifest V2. This is a browser extension version format supported by Firefox (Chrome too, but not for the web store). Now, you can highlight pages from Firefox! In addition to this, the project switched to using a shadow DOM for styling its UI elements, which makes it significantly less likely to be affected by the style and design of the webpage it's running on.

You can find Matrix Highlight on its GitHub page or read about it in the introductory blog post.

Populus-Viewer

Populus-Viewer is a social annotation tool, powered by Matrix. It lets you attach Matrix chats to PDFs, images, videos, and audio files. ↗

gleachkr tells us

Populus-Viewer is a social annotation tool, powered by Matrix. It lets you attach Matrix chats to PDFs, images, videos, and audio files.

It's been a big year for populus! Since last January, we've seen huge improvements in usability, appearance, and Matrix feature support, that have taken populus from a fun experiment to a useful tool (though we're still considering ourselves in beta). The topline item is that we've achieved our original goal of supporting matrix-powered social annotation of PDFs and audiovisual media. So what's left to do?

Here are some ideas for the New Year.

• Let's add support for annotating web files: HTML (out on the web) and WARC (web archives, stored as files on matrix).
• Let's add widget support for populus chats, so you can annotate your documents with all sorts of matrix-powered tools.
• Let's get moving on the social annotation MSCs
• Stickers?

If you'd like to talk about any of these ideas, or add some of your own, come join us at: #opentower:matrix.org

Aminda's matrix update

Aminda (she/they 🏳️‍⚧️ MSC1769|MSC3189) reports

so I have been doing

• https://gitea.blesmrt.net/mikaela/gist/commits/branch/master/matrix
• https://git.piraattipuolue.fi/Pikaviestimet/Pikaviestimet/commits/branch/master/matrix
• https://github.com/Mikaela/mikaela.github.io/commits/master/blog/_posts
• https://github.com/Mikaela/mikaela.github.io/commits/master/pages/matrix.markdown
• https://github.com/Mikaela/mikaela.github.io/commits/master/txt/matrix.txt

matrix-docker-ansible-deploy

Matrix (An open network for secure, decentralized communication) server setup using Ansible and Docker ↗

Slavi tells us

For matrix-docker-ansible-deploy, 2022 started with breaking the Synapse monopoly by adding support for the Dendrite Matrix homeserver in early January. This required various internal changes so that the Ansible playbook would not be Synapse-centric anymore. This groundwork paved the way for continuing in this direction and we added support for Conduit in August.

When it comes to the matrix-docker-ansible-deploy Ansible playbook, 2022 was the year of the non-Synapse homeserver implementation. In practice, none of these homeserver implementations seem ready for prime-time yet and there is no migration path when coming from Synapse. Having done our job of adding support for these alternative homeserver implementations, we can say that we're not getting in the way of future progress. It's time for the Dendrite developers to push harder (development-wise) and for the Synapse developers to take a well-deserved long (infinite) break, and we may get to see more people migrating away from Synapse in the next year(s).

Support for the following new bridges was added:

• Postmoogle for bi-directional email bridging, which supersedes my old and simplistic email2matrix one-way bridge-bot
• mautrix-discord
• go-skype-bridge
• matrix-appservice-kakaotalk

Support for the following new bots was added:

• buscarron bot
• Honoroit bot
• matrix-registration-bot
• matrix-hookshot
• maubot

Support for the following new components and services was added:

• Borg backup
• Cactus Comments
• Cinny client support
• ntfy notifications
• matrix-ldap-registration-proxy
• matrix_encryption_disabler support
• synapse-s3-storage-provider to stop the Synapse media store from being a scalability problem. This brought along another feature - an easier way to customize the Synapse container image without having to fork and self-build all of it from scratch

Besides these major user-visible changes, a lot of work also happened under the hood:

• we made major improvements to Synapse workers - adding support for stream writers and for running multiple workers of various kinds (federation senders, pushers, background task processing workers, etc.)

• we improved the compatibility of (Synapse + workers) with the rest of the playbook by introducing a new matrix-synapse-reverse-proxy-companion-service service

• we started splitting various Ansible roles out of the Matrix playbook and into independent roles (e.g. matrix-postgres -> com.devture.ansible.role.postgres), which could be included in other Ansible playbooks. In fact, these roles already power a few interesting other sibling playbooks:

  • gitea-docker-ansible-deploy, for deploying a Gitea (self-hosted Git service) server
  • nextcloud-docker-ansible-deploy, for deploying a Nextcloud groupware server
  • vaultwarden-docker-ansible-deploy, for deploying a Vaultwarden password manager server (unofficial Bitwarden compatible server)

These sibling playbooks co-exist nicely with one another due to using Traefik for reverse-proxying, instead of trying to overtake the whole server by running their own nginx reverse-proxy. Hopefully soon, the Matrix playbook will follow suit and be powered by Traefik by default.

Last, but not least, to optimize our etke.cc managed Matrix server hosting service's performance (but also individual Ansible playbook runs for people self-hosting by themselves using the playbook), we've improved playbook runtime 2-5x by employing various Ansible tricks.

MTRNord's Journey of Matrix 2022

MTRNord is known for starting way too many interesting projects. Definitely worth checking out!

MTRNord tells us

Since I worked on so many projects this year, I am trying to group these here.

Matrix-Art

Matrix Art was meant to be a Deviantart or Art Station style image gallery using Matrix. This project, as many others of mine, is currently on ice.

It offered profiles, uploading images and comments using Spaces as FS.

You can see the latest version of it at https://github.com/MTRNord/matrix-art/pull/121

Matrix Moderation Widget for Mjolnir

A widget made to be a companion to Mjolnir. It offers a form input and lists to view the policy lists.

For 2023 this effort is going into the Moderation bot I am currently developing as part of the Matrix Spam ML project. While not being a widget, similar UX decisions are used.

Matrix Fuzz

A simple fuzzer written in rust to fuzz some endpoints of Synapse.
A Fuzzer is essentially a bruteforce approach to finding bugs. Usually by sending pseudo random characters.

As part of running this, I found a few minor verification issues at Synapse:

• https://github.com/matrix-org/synapse/issues/13510
• https://github.com/matrix-org/synapse/issues/13511
• https://github.com/matrix-org/synapse/issues/13512
• https://github.com/matrix-org/synapse/issues/13664

For 2023 the goal is to fuzz more endpoints, especially within the rooms using fuzzed events.

MRSBFH - Matrix-Rust-SDK-Bot-Framework-Helper

In 2022, I also worked on further updating https://github.com/MTRNord/mrsbfh which is a command bot framework for the matrix-rust-sdk.

Since then, the SDK massively improved how you interact with the API. Due to this, there are no plans to further develop it as by now the SDK has a sufficient API interface.

Generic Conference Bot

People likely know the Conference bot from FOSDEM. Back in February, I did work on making it possible to be used more generic without the hard-coded penta integration.

As a result, this branch was created: https://github.com/MTRNord/generic-conference-bot/tree/MTRNord/Pretalx It offers a way to easily add new backends and adds a pretalx backend. Due to the changes it has, there is currently no way this is possible to upstream, but maybe it will help someone from the community.

Matrix Spam ML

This project is mainly a project to experiment with using Machine Learning for Moderation as a warning system.

As part of this effort, there is currently an RNN model and a BERT model available. The trainingset is public.

For users, there is both an API endpoint for this available and a Matrix Mod Bot in progress.

You can find more about it at https://github.com/MTRNord/matrix-spam-ml or join the chat at #matrix-spam-ml:midnightthoughts.space

Matrix Faq Rasa

This is a RasaX based FAQ Bot project. The goal is to have a NLP based FAQ bot. It currently is very simple and not finished. The goal for 2023 is to continue working on this and getting it to a stable level where people can contribute to.

Matrix.org Zola

Last but not least, I did kick off the Zola rewrite of Matrix.org together with Thib and jplatte, and a small team of element devs and designers. Please note that this was initiated by the community and still is a community project.

The goal of this rewrite is to move away from Gatsby and rewrite and redesign matrix.org using the zola static page generator.
We made great progress this year, but sadly it will take a bit longer before it can be deployed. :) If you want to watch progress, I suggest looking at things labeled with "zola" in https://github.com/matrix-org/matrix.org/

Miki - A Matrix Wiki

Miki is a MediaWiki meant for Matrix. It isn't a bridge, but instead the goal is to document projects and history around Matrix. This project aims for 2023 to extend the data, while in 2022 the work was focused around infrastructure.

That's all I know about so far. I hope you had a great year and that the next one will be even better. As you can see, the Matrix community is a riot of colors and seems to grow every year. I absolutely love it!

Hi all,

2022 has been a rollercoaster of a year for Matrix.

On one hand, the network has doubled in size (44.1M to 80.3M visible matrix IDs). The wider world is having a grand awakening to the importance of decentralisation thanks to the situation at Twitter. We’ve seen an amazing number of major new players entering the Matrix ecosystem: Reddit appears to be building out new Chat functionality using Matrix; TeamSpeak announced Matrix-based chat in TS5; Discourse is working on adding Matrix support; Thunderbird launched Matrix support; Governments from Luxembourg to Ukraine have launched their own Matrix-powered chat infrastructure; and hundreds of other organisations ranging from startups to massive private & public sector entities are betting on the protocol. The European Parliament has used Matrix as a proof-point for the viability for communication interoperability between gatekeepers in the Digital Markets Act. FOSDEM 2022 ran smoothly via Matrix with over 23,000 attendees, making it the world's largest open source conference (with 70% of attendees using their own servers!). Sweden has published case studies on the benefits of Matrix for messaging interoperability. Meanwhile existing players like Germany’s BWI have expanded their scope to providing Matrix messaging to the whole German State; Automattic is busy building Matrix plugins for Wordpress; Rocket.Chat launched federation via Matrix, Gematik has been busy progressing their TI Messenger initiative for interoperable messaging within Germany’s healthcare industry, and Tchap in France is continuing to expand.

On the other hand, only a handful of these initiatives have resulted in funding reaching the core Matrix team. This is directly putting core Matrix development at risk. We are witnessing a classic tragedy of the commons. We’ve released all the foundational code of Matrix as permissively-licensed open source and got it to the point that anyone can successfully run it at scale themselves. The network is expanding exponentially. But in return, it transpires that the vast majority of these commercial deployments fail to contribute financially to the Matrix Foundation - whether by donating directly or supporting indirectly by working with Element, who fund the vast majority of core Matrix development today.

In short: folks love the amazing decentralised encrypted comms utopia of Matrix. But organisations also love that they can use it without having to pay anyone to develop or maintain it. This is completely unsustainable, and Element is now literally unable to fund the entirety of the Matrix Foundation on behalf of everyone else - and has had to lay off some of the folks working on the core team as a result.

The only viable solution to this is for organisations building on Matrix to contribute to sharing the costs of maintaining Matrix’s core projects. We made a proposal to address this a few weeks ago, which we’ll iterate on further in the new year to find an approach which both empowers the community and encourages organisations to participate. In the interim, if you are an organisation who’s building on Matrix and you want the project to continue to flourish, please mail [email protected] to discuss how you can support the foundations that you are depending on.

As a reminder, the work the Foundation does today for the benefit of the Matrix includes:

• Publishing the Matrix Specification
• Organising the Matrix Spec Core Team, responsible for reviewing and evolving the protocol.
• Writing roughly half the Matrix Spec Change proposals.
• Developing Synapse, the Python matrix homeserver implementation
• Developing Dendrite, the Go homeserver implementation
• Developing client SDKs for Web (matrix-js-sdk, matrix-react-sdk), iOS (matrix-ios-sdk), Android (matrix-android-sdk2), Python (matrix-nio)
• Developing our next-generation client SDKs (matrix-rust-sdk)
• Developing our end-to-end encryption implementations (libolm in C/C++ and vodozemac in Rust)
• Developing next-generation end-to-end encryption implementations (MLS)
• Developing and evolving additional core functionality in Matrix, including:
  • Account portability
  • Faster room joins over federation
  • Sliding Sync for instant client sync
  • Threads
  • Rich Text composer components
  • Spaces
• Developing open source integrations to other products (GitLab, GitHub, JIRA... )
• Developing open source bridges to other platforms (IRC, XMPP, Slack, Discord, Telegram, bifrost…)
• Developing peer-to-peer Matrix implementations, avoiding the need for servers (and associated data/metadata accumulation) entirely
• Developing low-bandwidth Matrix transports
• Developing and hosting static Matrix room archives for the wider network (matrix-static and matrix-public-archive)
• Developing and hosting the matrix.to link redirect service
• Developing open source authentication mechanisms and integrations for Matrix (OIDC)
• Developing decentralised Video/VoIP conferencing servers on Matrix (waterfall)
• Developing decentralised Video/VoIP client components on Matrix (matrixRTC)
• Developing showcase "beyond chat" implementations of Matrix such as Third Room
• Developing moderation tooling and applying it to matrix.org (mjolnir and much more)
• Publishing moderation reputation lists for the benefit of the wider community
• Developing integration test suites for Matrix compatibility testing (sytest, complement, trafficlight)
• Developing a reference push notification server (sygnal)
• Developing a reference identity directory server (sydent)
• Procuring and publishing independent public audits of Matrix's encryption and wider stack
• Publishing the matrix.org website and blog
• Publishing the weekly "Matrix Live" video podcast
• Publishing the weekly "This Week In Matrix" news letter
• Organising regular meetups (e.g. "Open Tech Will Save Us")
• Promoting Matrix at open source conferences
• Running the matrix.org homeserver
• Moderating the matrix.org project rooms
• Running free public bridges to networks such as IRC networks and XMPP.

This list is not remotely exhaustive (turns out there are over 240 projects in the matrix.org GitHub org!) but it serves to illustrate the sheer scale of work that the Foundation performs today. Keeping the core team funded to work on Matrix as our day job is critical for Matrix’s long-term success, and so we really hope that organisations depending on Matrix (or passing philanthropists who appreciate Matrix’s value) will drop a line to [email protected] and help keep the show on the road.

Turbocharging Matrix

Aside from the nightmares of funding open source software, 2022 has very much been a year of building - focusing on implementing a step change in Matrix’s performance and usability: ensuring that the protocol can punch its weight (and more!) against centralised proprietary alternatives. After all, Matrix clients need to be at least as good as the centralised alternatives in order to get widespread uptake.

This work has ended up taking many forms: on the server-side, Synapse sprouted Rust support to accelerate its hot paths, starting with push rule evaluation. It’s super exciting to see Synapse performance heading into a new era, building on the foundations of what’s become a very mature and stable homeserver implementation.

Meanwhile work is in the final stages on “Faster Joins”, finally letting servers rapidly join rooms over federation by synchronising only the minimal subset of state needed to join, rather than proactively synchronising the room’s full current state. Faster joins became available for testing in Synapse in October, and since then the team has been working through making it support workers and addressing the various edge cases and bugs that have shown up during testing. Current join performance is a roughly 25x speedup on large rooms, although we’re confident that we can improve this even more, and we’re aiming to land it in time for FOSDEM at the beginning of Feb.

On the client-side, the work to transform Matrix client performance has centred around “Sliding Sync” - our entirely new API for synchronising the minimal data to a client needed for it to render its UI, thus making login, launch and sync instant. Sliding sync (originally called “sync v3”) has been a long time in the making; the API has gone through countless iterations as we worked away throughout 2022 implementing it in real-life clients, and adding all the extensions (MSC3884, MSC3885) needed to get to parity with sync v2. The wait has been well worth it, though: support in Element Web is in the final stages of development - and moreover the next-generation Element X mobile clients will only speak Sliding Sync.

Element X itself is shaping up to be a showcase of just how snappy and performant Matrix can be: built on matrix-rust-sdk, it uses native Swift UI on iOS/macOS and Jetpack Compose on Android to couple together the best possible platform-native user experience with the ultimate underlying native-code SDK implementation, backed by sliding sync. The goal is to be at least as snappy as Telegram, iMessage or WhatsApp (we’ve taken to counting the frames in screen recordings to compare things like time-to-launch and time-to-load scrollback). Element X is currently in late alpha on iOS, and the hope is to enter public beta in time for FOSDEM. You can see a sneak peek here of the iPad-style layout (running under macOS) though!

Finally, in terms of usability, there have been leaps and bounds forwards across Matrix - particularly with Element’s mobile UI being entirely refreshed by the design team in September as a stepping stone to the forthcoming final Element X design. Any remaining UX quirks should be flushed out with Element X, but the visuals are already a clear step forwards towards an excellent alternative to the centralised encumbents.

Encryption

We had great plans for E2EE in Matrix this year; starting off in a huge rush to get vodozemac finished and audited as our shiny new native-Rust implementation of Olm/Megolm. The plan was then to integrate vodozemac into matrix-rust-sdk’s crypto crate, and then replace the various old fragmented E2EE implementations across matrix-js-sdk, matrix-ios-sdk, matrix-android-sdk2 and matrix-rust-sdk itself with One True audited implementation - with audits booked with Least Authority to get further assurance around matrix-rust-sdk-crypto, matrix-rust-sdk itself and finally the full stack (Element X + Synapse).

Unfortunately, things went sideways when security researchers from Royal Holloway University London & elsewhere got in touch to explain that they had found some nasty implementation vulnerabilities in the venerable matrix-js-sdk implementation. So, we had no choice but to pause “Element R” - the project to converge matrix-{js,ios,android}-sdk on matrix-rust-sdk-crypto, and instead start analysing and addressing the issues across all current shipping Matrix clients in order to resolve them as rapidly as possible. Ironically, it turned out in the end that only matrix-{js,ios,android}-sdk were affected - all other independent implementations, including matrix-rust-sdk, were okay. As such, the Element R work would have protected us from these vulnerabilities had it been ready, and failing that it would have let us solve them in a single place. Instead, Element R ended up getting pushed back for months while we worked through the various issues in triplicate across the legacy SDKs, while also checking all the other client implementations we could find, and dealing with additional issues which the RHUL researchers discovered as they dug deeper. Eventually we finished the analysis and agreed a coordinated disclosure at the end of September. (EDIT: to be clear, we are very grateful to the security researchers for discovering and disclosing the vulns responsibly to us. The frustration here stems from the irony that if we'd finished the matrix-rust-sdk-crypto rewrite a few months earlier, we'd have mitigated the severe vulns - but instead, the rewrite got pushed back even further. It's obviously our fault though, not the researchers'.)

Since then, work has been split three ways: firstly, Element R work has resumed - and in fact Element R on iOS is pretty much usable as of today, other than needing some work to support E2EE push notifications (which will also be required for Element X). Element R on Android is very close too, and meanwhile Element R on Web decrypted its first event on Dec 19th! We’re hoping to get Element R in production on all platforms by Feb.

Secondly, we’ve been addressing other points raised by the RHUL researchers to ensure that malicious servers cannot add malicious devices or users to conversations, rather than warning as we do today. This is not a trivial problem to solve, but we’re making progress via MSC3917 (Cryptographically Constrained Room Membership) and MSC3834 (Opportunistic user key pinning (TOFU)). However, this work is effectively blocked on Element R landing first, as there’s no way we’re going to fix this in triplicate on the legacy SDKs.

Thirdly, we’ve been pushing ahead on implementing Decentralised MLS as a next-generation encryption protocol for Matrix to potentially replace Olm and Megolm. This work was badly disrupted by RHUL mitigations, but we’re making good progress again - you can follow all the details over at https://arewemlsyet.com. Matrix over DMLS is currently in alpha, but the aim is to start beta testing Decentralised MLS in 2023.

Finally, we’ve been working hard on completely reworking the overall UX of how E2EE should work in Matrix clients - specifically, requiring users to cross-sign their devices in order to use E2EE, and so end up in a much higher trust world (alongside Trust On First Use). Can’t wait to finally simplify the E2EE UX!

All new features

It’s not all been performance and stability work this year - there have been some large areas of feature work happening too.

One of the most visible projects has been Threads, which launched in beta in April, and subsequently has undergone huge amounts of polish to improve performance, notification semantics, unread behaviour and thread-aware read receipts. The end result is feeling great now, and threads exited beta in Element Mobile on Dec 20th. Web narrowly missed the window due to a final ‘stuck notification’ bug which is still being tracked down, but will follow shortly afterwards and then threads will be finally out of beta!

Another big project in 2022 has been to create a general purpose Rich Text Editor to provide WYSIWYG (What You See Is What You Get) message composition for Matrix clients. This has ended up being a very ambitious project to define all the core editing semantics in a shared rust library, with platform-specific bindings to link it into the editing UI available on Web, iOS & Android. The end result lives at https://github.com/matrix-org/matrix-rich-text-editor - and you can play with it by enabling it in labs on Element Web/iOS/Android or experiment with the live demo. The core behaviour is feeling excellent, although predictably some of the fine detail is very fiddly to get right. It’s almost there, though, and thanks to its built-in rust test harness generator(!) we are confident we’ll catch and control all the edge cases, and this should form an incredibly strong platform for all future rich text editing requirements in Matrix (and beyond!). This work was very kindly sponsored by one of Element’s public sector customers in order to get Element to parity with Teams - thank you!

Location Sharing was another feature which landed in 2022 - powered by MSC3488 and MSC3489, and implemented in matrix-{js,ios,android}-sdk in Element Web/iOS/Android, letting users share static and live locations and view them on an OpenStreetMap compatible map tileserver of their server’s choice. The Live Location Sharing is controversial in that it stores location data in the room history (and as such is hidden behind a labs flag on Element), but should eventually be replaced by MSC3672 to share locations are custom ephemeral events instead (once custom EDUs land) in the spec. Around the same time, Polls also went live thanks to MSC3381 - it’s worth noting that both Location Sharing and Polls are excellent examples of “extensible events” in the wild: ensuring that clients which understand the custom event type will render them appropriately, but letting other clients fall back to showing them as simple timeline events.

Open ID Connect

The transition to using Open ID Connect for Matrix authentication has been progressing steadily throughout 2022 - with Third Room being the first OIDC-native Matrix client, closely followed by Element X. matrix-authentication-service now exists as a basic OIDC identity provider suitable for being linked into Synapse, and meanwhile Third Room demonstrates how you can integrate Keycloak as a third party IDP (complete with reCAPTCHA and guest access!). The team also went on a very exciting detour to figure out how to perform login-and-E2EE-setup in a single operation by scanning a QR code (MSC3906), and how it might integrate into OIDC in future.

Element X looks set to be the showcase for native OIDC in a typical Matrix client going forwards, so watch this space to see how it feels!

You can keep track of the inexorable transition to OIDC over at https://areweoidcyet.com.

VoIP

2022 was the year that Matrix finally got native multiparty VoIP. After launching Element Call Beta 1 in March followed by Beta 2 in June, we’ve been busy embedding Element Call as a “matryoshka” widget into Element Web, using it to replace Jitsi in powering video rooms and video calls. You can read all about this in detail in the summer blog post.

Meanwhile, lots of progress is underway on Waterfall - the name we picked for the Pion-based decentralised Selective Forwarding Unit (i.e. conferencing focus) contributed by Sean DuBois earlier in the year, including adding simulcast support to support large scale conferences.

There’s only one catch, which is that Element Call is still in (very very late) beta, thanks to a handful of bugs which have been hard to track down, which has in turn kept all the other dependencies (embedded Element Call; video rooms etc) in beta too. However, we think we’re pretty much there now - which is perfect timing given how Waterfall is coming together, meaning that both stable and scalable native Matrix conferences are on the horizon!

Even better, the plan is for Element X to rely entirely on embedding Element Call for VoIP - so we should be able to jump forwards pretty rapidly to having excellent native multiparty VoIP and video rooms on mobile as well as on Web. So, once Element Call exits beta, everything should follow. Just for a change, we’re aiming to get this done by the end of January - but there are a lot of unknown unknowns still flying around, so watch this space…

IETF & MIMI

Another massive new initiative this year has been the process of proposing Matrix to the IETF as a candidate for use in interoperable instant messaging standardisation. The MIMI (More Instant Messaging Interoperability) working group emerged earlier in the year within IETF as an initiative to define how MLS could be used to interoperate between different instant messaging silos - as shortly to be required by the Digital Markets Act.

One of the things that MIMI aims to do is to define a common application layer protocol to exchange messages. At first CPIM was proposed (an ancient message format that looks a lot like email) - and then an entirely new JSON message format proposal emerged which looks somewhat Matrix (but isn’t). At this point it became obvious that we should throw our hat into the ring and encourage MIMI to use Matrix rather than reinvent it, and so we set about proposing Matrix as at least the message format and message transport layer of the stack. It’s quite surreal to see Matrix starting to fly around as IETF Drafts!

The next step here is to re-express the relevant bits of the current Matrix spec as self-contained IETF Drafts (rather than backreferencing the current spec from the drafts). The idea is that the normal Matrix spec will continue to evolve much as it always has, but we’ll effectively donate a Long Term Supported dialect of it to IETF which can then evolve according to IETF process and be immortalise as RFCs for use in MIMI. We’ll then backport those changes into spec.matrix.org in order to avoid fragmentation, while retaining the same ability we have to rapidly iterate and extend Matrix with MSCs. This work is well under way (taking opportunity to use Extensible Events from the outset!), and we should see explosions of further IETF Drafts emanating from Travis as 2023 progresses.

Trust & Safety

2022 saw a real uptick in spam and abuse across Matrix, and there have been some valiant attempts to improve our moderation tooling over the course of the year. Unfortunately it hasn’t come together as rapidly as we might have hoped, however, and we’ve seen several large communities give up on Matrix and move back to Discord thanks in part to needing better anti-abuse mechanisms.

In 2023 we’re resetting our trust & safety work, with Mjolnir dev returning to its original development team, and we’ll be working as tactically as possible to ensure that all communities on Matrix can easily block abuse using whatever mechanisms they need.

P2P & Dendrite

Meanwhile, Dendrite (our second generation homeserver implementation) development has continued at pace throughout the year. According to sytest we are now at 93% client-server API compliance with 577 out of 620 tests passing, and the server-server API compliance is at 97% with 111 out of 114 tests passing! None of the missing tests are showstoppers, so it’s fair to say that Dendrite is very nearly ready for primetime.

The interesting plot twist is that Dendrite development has ended up increasingly focusing on embedded matrix server use cases - particularly to power Peer-to-Peer Matrix, where clients require a server to be embedded within them. So while Synapse has ended up increasingly focusing on large-scale deployments, Dendrite has ended up pursuing smaller instances (which is ironic, given originally it was meant to be the other way round!).

P2P Matrix work has been progressing well too - you can follow the blow-by-blow updates over at https://arewep2pyet.com. After a lot of back and forth evaluating hard-state routing versus soft-state routing in Pinecone, we’ve ended up converging on soft-state routing (which is chattier, but easier to reason about in terms of mitigating attacks). However, the chattiness means that it doesn’t scale as well as one might hope - so we’re now working on a “tiered” approach where separate Pinecone networks can be tiered together into one inter-network, giving us scalability at the expense of being slightly less decentralised. It’s fair to say that the journey here has been pretty frustrating in its twists and turns, and sadly Neil Alexander chose to move on a few months ago. However, Devon has stepped up to fill his shoes as primary Pinecone and P2P wrangler, and is making amazing progress on the remaining work - firstly implementing Store and Forward relaying in Dendrite so that today’s Pinecone networks can exchange messages even if the recipient node is offline. Next up will be bridging P2P Matrix with today’s Matrix network - and then working on tiering to provide the scalability we need. The expectation is that today’s serverside Dendrite instances will effectively turn into static pinecone peers, store and forwarding messages on behalf of P2P nodes, and providing tiering between respective pinecone subnets.

Hydrogen & Chatterbox

Development on Hydrogen as a super-lightweight progressive-web-app Matrix client has also been progressing throughout the year (with a few detours to help out with end-to-end testing via trafficlight both for the benefit of Hydrogen and other clients).

The biggest change has been Hydrogen sprouting a separate SDK layer, letting the engine be embedded into other webapps in order to add noninvasive Matrix messaging with as minimal a footprint as possible. This was showcased in Element’s chatterbox offering in July - providing an open source chatbox which can be trivially embedded into existing sites, and also powers the Chatrix wordpress plugin that Automattic is working on.

Hydrogen also added independent support for MSC3401 multiparty voice/video calling (albeit on a branch), letting us showcase heterogeneous Element Call <-> Hydrogen group calling and prove MSC3401 as fit for purpose as a true open interoperable call signalling - and in turn Hydrogen SDK, complete with the multiparty voice/video calling, powers the Matrix engine within Third Room - our metaverse-on-Matrix platform.

We’re looking forwards to Hydrogen continuing to reach full feature parity with Element over the next year, and popping up in increasingly unexpected places as everyone’s favourite embedded Matrix client!

Third Room

Finally, it’s hard to believe that Third Room, our Matrix-based open platform for decentralised realtime spatial collaboration, barely existed at the beginning of the year. Third Room serves to demonstrate that Matrix is way more than just chat and VoIP, but can power the spatial communication layer of the open web. This has ended up driving forwards a tonne of new capabilities for Matrix - showcasing native OIDC auth; scalable multiparty VoIP in Hydrogen SDK, efficient binary-diffed file storage, and more recently has been defining how to store extensible behaviour for Matrix rooms as WASM objects stored in the Matrix room itself.

Third Room itself is a Hydrogen-based Matrix client, which lets you view Matrix rooms as interactive multiparty 3D environments (using MSC3815) - with the world defined as glTF blobs stored in the Matrix room, and the ability to script and customise any aspect of that world using WASM blobs stored in Matrix rooms, which execute on the participating clients, exposing a new scenegraph API called WebSceneGraph in order to manipulate the glTF that makes up the world. We also expect to see a variant of Matrix’s normal widget API to be exposed to these WASM blobs, introducing the concept of sandboxed clientside widgets, bots or other integrations - letting users customise and extend Matrix without ever having to run serverside bots again.

The intention is to provide a platform which can be used to build any kind of interactive realtime spatial multiparty app in an open standardised, decentralised, end-to-end encrypted way - whether that’s for gaming, social, or professional activity such as building “digital twins” for manufacturing, agriculture, smart cities, search & rescue, etc. You can read more about the vision at thirdroom.io/preview, or via press coverage at TheNewStack or Golem. We were also incredibly flattered to be invited to present Third Room at SIGGRAPH Asia a few weeks ago. The official recording has yet to emerge, but you can find a cheeky bootleg here.

We launched Tech Preview 1 of Third Room at the end of September, and since then all of the work has been around building out WebSceneGraph and the WASM scripting environment - letting users build their own functionality in JS via QuickJS or C (and in future Rust or Zig too). We’ve also been working on making the networking (via Matrix WebRTC-negotiated data channels) more robust, switching to an ‘authoritative’ simulation model rather than having each client run its own physics simulation, in order to kick the hard problem of decentralised physics simulations down the road a bit further. We’re also adding in a much-needed ‘discover’ page to help users find new rooms and explore everything that’s possible in the platform. And finally, we’re adding WebXR support so that folks can use ThirdRoom with VR and AR hardware if they so desire. All this should culminate in Tech Preview 2, due in the coming weeks.

If you want a quick sneak preview of the scripting capabilities on the horizon with a very basic script stored in the media repository, head over to https://thirdroom.io/world/#surprise:thirdroom.dev and click on the television ;)

Conclusion

So there you have it: it’s been a mixed year for Matrix, but at least the project itself is moving forwards faster than ever, for now. If you look back at the predictions from last year’s holiday blog post you’ll see that most of them even came true. This year, we’ll keep the predictions simple: our plans for 2023 are to ensure that the Foundation is well funded, ship all of the step-change improvements in performance and usability which are currently in beta as rapidly as possible - and demonstrate for once and for all that Matrix can indeed punch its weight against the proprietary centralised alternatives.

If you can afford it, please consider donating to the Matrix.org Foundation to support our work. The most efficient way to support us is to donate via donorbox. Our Patreon is not going anywhere, so if you wish to keep supporting it there we're happy to count you in our supporters.

Thanks for flying Matrix;

Matthew, Amandine & the whole core team.

TL;DR: you can now officially join the Matrix Foundation as an organisational or individual member in order to sustainably support core Matrix development, help steer the direction of the protocol and how best to fund it! Organisations can join by filling this form and we will get back in touch, or individuals can now donate directly here (as a more efficient alternative to Patreon, which remains online for Patrons used to it).

Hi all,

Only two days late for Giving Tuesday (and 4 years late on the Foundation scale), we are super excited to announce that we are finally expanding the Matrix Foundation into a fully-fledged non-profit fund-raising organisation to help support the core Matrix development and the wider open source Matrix ecosystem!

Has your organisation been using Matrix to communicate via the open source server and clients and you want to ensure that improvements and features still keep coming? Become a member, and feed into the roadmap.

Has your company been building on top of Matrix, making the most of its openness and flexibility, but you’ve never figured out how to contribute back in order to ensure the resilience of the tech which you rely on for the success of your business? Become a member, and ensure the core development is funded and that Matrix is here to thrive.

Are you about to be designated a gatekeeper by the EU, and have to rapidly figure out how to implement DMA-compliant interoperability (complete with end-to-end encryption compatibility) into your services? Become a member, and discover how Matrix can solve all your problems, while providing your input too.

Are you looking to implement DMA interoperability but don't fall into the gatekeeper designation? Become a member, and help ensure Matrix fits your needs too!

Are you a non-profit organisation with a mission to provide secure and sovereign communications to those who need it the most, providing an alternative to the current players? Become a member, and help us take our mission forward.

Are you an individual who strongly supports the mission of Matrix and wants to see it thrive and become the open backbone of the world’s communications? Become a member, and support the future of Matrix.

In short, this finally gives the wider world a way to contribute concretely to the significant costs of funding folks to work fulltime on core Matrix development - which now covers over 243(!) projects in github.com/matrix-org. Core Matrix work ranges from:

• managing the Matrix spec itself
• maintaining the reference client SDKs and encryption and getting them independently audited
• maintaining example server implementations in the form of Synapse and Dendrite
• writing the test suite
• publishing the matrix.org website
• promoting awareness of Matrix
• running the matrix.org homeserver
• and so much more...

In exchange for supporting the Foundation, and beyond providing certainty that our work can continue, organisations and individuals who contribute financially will be able to directly provide input to the trajectory of the core Matrix developments by becoming official members of the Matrix.org Foundation.

Introducing Foundation Memberships and the Governing Board

Practically speaking, this means that we are going to create a "Governing Board" to the Matrix.org Foundation: a new team, made up of members voted by the overall membership, a subset of the Guardians and a subset of the Spec Core Team. The Governing Board will have the responsibility of determining how Foundation funds are distributed and used, how the Spec Core Team roadmap is prioritised, how to best grow Matrix awareness, etc.

In other words, we are literally expanding the day-to-day steering of the direction of the Matrix Foundation to the wider community. In order to run the Governing Board and the overall work of the Foundation, we are also hiring an Executive Director, so please get in touch via [email protected] if you’re a non-profit foundation-running expert! In the interim, while this search proceeds, Matthew and Amandine will fill the role with the support of the other Guardians of Matrix. The Guardians themselves retain their existing function as the Foundation's non-executive board - responsible for safeguarding the overall mission of Matrix, appointing the membership of the Spec Core Team, approving membership applications, and defining the overall changes we’re outlining here.

Membership comes at various levels, each with different rewards:

• Individual memberships (i.e. today’s Patreon supporters):
  • Ability to vote in the appointment of up to 2 ‘community representatives’ to the Foundation's governing board.
  • Name on the Matrix.org website
• Silver member: between £2,000 and £80,000 per year, depending on organisation size
  • Ability to vote on the appointment of up to 2 ‘Silver representative’ to the Foundation's governing board
  • Supporter logo on the front page of the new Matrix.org website
• Gold member: £200,000 / year, adds:
  • Ability to vote on the appointment of up to 3 ‘Gold representatives’ to the Foundation's governing board.
  • Press release announcing the sponsorship
  • 1 original post on the Matrix.org blog per year
  • Participation in the internal Spec Core Team room
  • Larger logo on the front page of Matrix.org
• Platinum member: £500,000 / year, adds:
  • Ability to vote on the appointment of up to 5 ‘platinum representatives’ to the Foundation's governing board.
  • 1 sponsored Matrix Live episode per year
  • Largest logo on the front page of Matrix.org

As the activities of the Foundation increase, we expect to add more benefits to this list, for example discounts on sponsoring a future Matrix Conference, or similar.

Governing Board elections will occur yearly, with the first election planned towards the end of this year once we’ve gathered together the first wave of members and candidates have proposed themselves for election.

For anyone building on Matrix, memberships are a no-brainer as they will ensure the perpetuity and future-proof-ness of the standard. But for anyone supporting the mission of Matrix, this membership can be key to define its future.

Meanwhile, with Matrix looking increasingly integral to implementing interoperable communication for compliance with the EU’s Digital Markets Act (whether that’s as pure Matrix, or as part of the IETF MIMI initiative), this is an incredible opportunity for the organisations impacted by DMA to get a front-row seat within the Foundation to ensure that Matrix thrives and solves the challenges posed by the act. To get involved, please apply via the membership application form.

So, why is this all happening?

Since 2017, core Matrix development has been funded primarily by Element - the company founded by the team who created Matrix. Over the years, Element has put tens of millions of dollars into Matrix - which in turn has come from both selling Matrix hosting (EMS), on-premise Matrix solutions, and VC investment in Element. To put it in perspective, even though there are over 5000 contributors to github.com/matrix-org - over 90% of the actual committed lines of code come from Element employees. Similarly, while we are enormously thankful for the past and existing generous donations from the wider Matrix community, today they only come to $6,000 a month, relative to the $400,000 a month that Element has been funding.

Over the last year, we’ve seen a palpable shift within the Matrix ecosystem. Matrix is growing faster than ever. Synapse has improved immeasurably, using less RAM than ever and even sprouting Rust to optimise its hot paths. Element has improved immeasurably too, with an entirely new design on mobile, and tons of new features including threads, voice messages, location share, video rooms and more. Monthly active users reported via Synapse’s phone-home stats have almost doubled and are growing at their fastest ever rate. The number of servers has increased equivalently. We hear about major new commercial Matrix deployments almost every day. However, while usage is going through the roof - we haven’t seen a matching increase in players looking to support the project.

In fact, we’ve seen the opposite: commercial vendors forking the protocol while trying to break up the core team. Matrix tenders lost to “preferred” vendors who know absolutely nothing about Matrix. Vendors selling Matrix hosting or services without contributing anything back to the project at all. Organisations with huge amounts of money (governments, $$B massive enterprises) have enthusiastically launched proprietary Matrix solutions by building on the liberally-licensed Apache reference Matrix implementations… while contributing back nothing. Now, we are enormously grateful for the commercial Matrix deployments who do actually work with Element to fund core development or contribute code themselves - but this is very clearly the minority. Obviously it’s great to see folks building on Matrix - but it’s rather galling if it ends up with insufficient funding trickling down to the core Matrix team to be able to build the foundational technology that everyone else is relying on.

Element in particular has staffed up in order to both support the core Matrix ecosystem (the spec, Synapse, Dendrite, Client SDKs, Encryption implementations etc) as well as Element-specific work (the Element apps, EMS, the Element Enterprise Installer, etc). As a result, Element employs roughly twice as many developers as you might expect, and while Matrix is here to stay, this turns out not to be sustainable for Element unless the wider ecosystem helps support the foundational work

We believe the world needs secure decentralised communication more than ever, and ensuring the Foundation can distribute funding to those contributing to the core platform (be that Element or individuals or other organisations) is key to that. So: please consider this a call to arms - if you believe the world needs Matrix, and particularly if you depend on it for your business, please join the Foundation and participate!

Fill in the form to apply for membership, or if you are not acting on behalf of an organisation, you can go straight to our donation page.

Matthew, Amandine & the whole Matrix.org Foundation

This year, the Matrix.org Foundation is excited to host the first ever Matrix.org Foundation and Community devroom in person at FOSDEM. Half a day of talks, demos and workshops around Matrix itself and projects built on top of Matrix.

We encourage people working on the Matrix protocol or building on it in an open source project to submit a proposal! Note that companies are welcome to talk about the Matrix details of their open source projects, but marketing talks are not welcome.

This call for participation is only about the physical devroom. A separate CfP will be issued for the online devroom once there are more details about it.

Key dates are:

• Conference dates 4-5 February, 2023 In person
• Matrix Devroom date: Sunday 5 morning in person, online devroom to be announced
• Submission deadline: Monday 5th December
• Announcement of selected talks: Thursday 15th December

You must be available in person to present your talk for the physical devroom.

Talk Details

The talks can follow one of thee two formats for the physical devroom

• 20 min talk + 10 min Q&A, for topics that can be covered briefly
• 50 min talk + 10 min Q&A for more complex subjects which need more focus

We strongly encourage you to prepare a demo when it makes sense, so people can actually see what your work looks like in practice!

Of course, the proposal must respect the FOSDEM terms as well:

The conference language is English. All content must relate to Free and Open Source Software. By participating in the event you agree to the publication of your recordings, slides and other content provided under the same licence as all FOSDEM content (CC-BY).

Submitting a Proposal

Proposals must be submitted on FOSDEM's conference management system Pentabarf before December 5 December 8 2022. If you are not used to Pentabarf, you can follow this beginners guide to Pentabarf.

We expect to receive more requests than we have slots available. The devroom organisers will be reviewing the proposals and accepting them based on the potential positive impact the project has on Matrix (as defined in by the Mission section of https://matrix.org/foundation).

If a project proposal has been turned down, it doesn't mean we don't believe it has good potential. Maintainers are invited to join the #twim:matrix.org Matrix room to give it some visibility.

As of Synapse 1.69, we consider "faster remote room joins" to be ready for testing by server admins.

There are a number of caveats, which I'll come to, but first: this is an important step in a project which we've been working on for 9 months. Most people who use Matrix will be familiar with the pain of joining a large room over federation: typically you are just faced with a spinner, which is eventually replaced by a cryptic error. If you're lucky, the room eventually pops up in your room list of its own accord. The whole experience is one of the longest-standing open issues in Synapse.

The "faster joins" project set out to change all this. Briefly, the reason the experience is so poor today is that there is a lot of information required to join a large room, which is slow for the "resident" server to generate, and even slower for the "joining" server to validate and store. The key insight is that we don't really need the full membership list of a room to get started: rather, we can present the user with the basic information about the room (name, topic, space hierarchy, etc), and then populate the full details in the background. The upshot is that, whereas it used to take upwards of 12 minutes to join Matrix HQ (even assuming that your server didn't fall over in the meantime), this is now down to about 30 seconds (and we're confident that we can reduce this even further).

It sounds simple enough, but in reality this has meant a lot of work on Synapse. The main problem was that huge amounts of the Synapse codebase assumed that we either had all the state for a room, or none of it. That assumption no longer holds, which meant lots of changes to the code to handle "partial state". Along the way we've also had to make some other improvements: for example, we found and fixed some long-standing bugs in event authorisation, and implemented cancellation for requests where the client disconnects before we finish handling the request. For an idea of the things being changed at the Matrix protocol level, take a look at MSC3902.

The upshot of all that, is that instead of seeing a blank room with a spinner (or an error message), you can now see the basic information about the room, as well as receive incoming messages, within a few seconds of trying to join the room.

Caveats

The devil, as they say, is in the detail, and unfortunately there remain a few rough edges to this work.

Firstly, and most importantly: we do not yet recommend enabling faster joins on important production systems. We've done quite a lot of testing, but there are some fundamental changes to Synapse, and by their nature they are hard to test rigorously. We're pretty confident it won't eat your entire database, but stuck rooms, stuck notifications, and stuck clients, are all entirely within the realms of possibility. We'd recommend only enabling faster joins on your server if you are comfortable looking at the logs, and using the Synapse Admin API or flushing client caches to clean things up if they go wrong.

Secondly: there's still some outstanding work required to support faster joins on Synapse deployments using worker processes. At present, if you try to enable them on a worker-based deployment, Synapse will refuse to start.

Next: the faster-joins process requires some support from the resident server, and, since those changes are not yet in the stable matrix spec, it must be explicitly enabled. We have enabled this support on the matrix.org homeserver, but it generally won't work elsewhere. In other words: for now, you'll only see the benefit when you join a room via a #<name>:matrix.org alias (or via the matrix.org room directory).

Finally, there are still quite a few things that don't work properly yet. We're tracking the list of things we need to fix as a milestone on the Synapse project, but to name a few:

• You can't yet send messages during the "resynchronisation" phase (synapse#12997). Currently, you'll just get a spinner.
• Similarly, attempts to leave the room (synapse#12802) will block until the resync completes.
• Clients which don't support lazy-loading room members will block (ie, they won't receive any new events at all) during the resynchronisation process (synapse#12989). Most popular clients, including Element, Hydrogen, Fractal and FluffyChat do support lazy-loading, but a few (including Nheko) do not.

Turning it on

With all that said: we are very excited for people to start trying it and give us feedback. If you administer a Synapse server and are as excited as we are, all you need to do to start testing faster joins is to add this to your homeserver.yaml (and then restart Synapse):

experimental_features:
  faster_joins: True

With that, any future remote room joins (or at least those going via matrix.org) will use the new faster joins algorithm. Please let us know how you get on, and file GitHub issues for any problems you might have!