An exploration of my mixed opinions towards the Matrix ecosystem.

Introduction

As part of my ongoing quest to reduce my dependence on Discord, I set up a private Matrix server1. Matrix is an open standard for end-to-end encrypted chat. It features many of the conveniences that one would expect from a proprietary chat service (such as Discord). Someone can host a server implementing the Matrix specification, called a homeserver, and its users can expect (if federation is enabled) to be able to chat with users on different homeservers, using different clients, and with functional end-to-end encryption. On paper this sounds really good. I like privately talking to people without being locked into proprietary services, and so should you. Let me be clear, I (mostly) like matrix, and all of the things I've described thus far are indeed solved (in theory) by Matrix. Unfortunately, Matrix isn't as perfect as it sounds from the outside. Dear reader, let me take you on a journey through the Matrix ecosystem. Despite how amazing Matrix is, it has many issues which prevent mainstream adoption.

Part 1: The Implementation

The most popular Matrix client right now is Element. It's also the only Matrix client that I would consider "production ready", and so it's the only one I feel comfortable recommending to people who don't have the patience to deal with software that's rough around the edges. The problem is: Element, the most "production ready" Matrix client available right now, is rough around the edges. The main pain point that non-technical users struggle with is the encryption and verification system. Having on-boarded multiple of my non-technical friends to Element I've noticed some recurring patterns in the user experience:

  1. They don't understand the verification system. The Element apps do a bad job at helping non-technical users understand what verification guarantees and why it's important.
  2. They run into a bug in the app but think that it's their fault because they don't have a good mental model of how it should work.
  3. A combination of having basically zero network effect for non-technical users and the app's design making these same users feel stupid makes them unwilling to tolerate bugs as much as they tolerate bugs in proprietary apps.
  4. They perceive the app as unstable or unreliable due to some combination of #1 through #3 so using it becomes a chore that they are barely willing to tolerate (and only because I ask nicely).

I used to run a Matrix server for my friends back in 2020 and 2021. I interviewed some friends that were part of that 2020 and 2021 Matrix server. Keep in mind that some of them were willing to join my new server, and others were not. The following are quotes that reflect the general sentiment of my interviews.

"Element on iOS is garbage. It's battery-draining, buggy, and has unintuitive UI"

"I remember people, like me, having trouble with passkeys [sic]2 and the [verification] system [Element] had"

"It felt like it was randomized whenever it decided to log me out"

"In private chats, I often had an issue with messages [disappearing or] resetting without reason or warning"

"[There were often] moments where I opened up a chat and none of our messages would be there [or] saying "this message is encrypted" or something along those lines"

All of this is compounded by lack of work being done on Element due to the team currently working on a complete rewrite called Element X. The Element iOS and Android apps have both been in "maintenance mode" for quite a while, meaning they only get fixes for "high priority" bugs and security issues. One example where this is a problem is this long-standing open issue in Element Android involving non-compliance with the Matrix specification. From reading through the documentation of their Rust SDK which powers Element X, it looks like this issue will be fixed (although I haven't tested it myself). Another example is Element Android not properly implementing token based registration and falling back to an endpoint which was never even part of the specification. Even though I have hope that Element X will resolve these issues in Element, I currently don't recommend Element X to my friends because it will probably end up getting removed from their device's app store which will likely leave them with an annoying migration that will certainly result in frustration and potentially result in a master encryption key reset if they make a mistake.

In essence, even the most popular and robust Matrix client is a chore for non-technical users, which is a massive hurdle because, as the name would suggest, there are two ends in end-to-end encrypted messaging, and both of them need to cooperate for it to work.

Part 2: The Specification

The Matrix specification is far from stupidly simple. The specification is incredibly long and even includes a bespoke version of the Double Ratchet Algorithm (which, fun fact: has a minor security issue baked into the spec3). The specification is also constantly changing and has had literally hundreds of proposed changes, some of which will require significant changes to all clients if accepted. There are (checks notes) eleven room versions that each client and server should attempt to implement. I believe that an ideal specification should be feasible to implement as an individual volunteer, and I can comfortably say that I would never attempt to implement the Matrix specification from scratch unless I was being paid to do so. I think the Matrix specification is extremely complicated and constantly changing and that this discourages independent re-implementations which I believe to be important for a healthy free software ecosystem.

Part 3: Governance

I put this section last because I think that this is the least important of my concerns currently. New Vector Ltd, the company who makes both Element and Synapse (the most popular and most "production ready" homeserver), mostly has the final say on what gets included in the Matrix specification. I don't think New Vector Ltd has sufficient incentive to keep the standard simple and re-implementable. Having likely spent engineer-decades worth of work building their suite of clients, the complexity of the specification (whether introduced intentionally or not) acts as a soft moat which gives them an advantage when it comes to acquiring Matrix related government contracts. That being said, I don't know what the future holds for Matrix and it's possible this will turn out to be a non-issue.

Hope For The Future

I hope that New Vector Ltd will release Element X (eventually) and it will address my complaints from part #1. I also hope that third-party clients put attention into their UX for non-technical users and make Matrix more accessible to the general public. I think it's likely that the specification eventually gets to a point where it's relatively stable and any additions are optional and non-required extensions. So despite all of my criticism of Matrix, I will still continue to use and recommend it.

1

Using Conduit, which is a great project.

2

I leave this in to give perspective on how the average user perceives security. The word "passkey" did not even exist during the time period this user was referencing.

3

See "issue J" in this security audit, the Matrix team deemed a fix would break too many things to be worth implementing. I agree with the Matrix team's assessment that this is a very minor issue (especially since the whole encryption system is getting gutted and replaced eventually anyway).