My experience on Matrix¶

I have been using [Matrix] for a long time now (over a few years), and have gone from simply using it as a way to chat to friends while in school, to being in hundreds of rooms, talking to anyone and everyone, and even writing bots for it.

In this post today, I'm going to summarise my experience on Matrix, what it is, the pros and cons of it, and what I think the future holds for it, and a few of the issues that I have with it.

What is Matrix?¶

Many people haven't heard of Matrix, so to give context on this post, here's a simple explanation.

Matrix is an open standard communications protocol that enables End to End encrypted (like what you see in Signal, Whatsapp, iMessage, RCS, etc.) real-time instant messaging, and VOIP.

Matrix is unique because it is decentralised and federated. This means that anyone can run their own Matrix server, and communicate with anyone else on any other Matrix server. This is similar to email in the sense that anyone can run an email server, and talk to anyone else on another email server. For example, I run a matrix server on nexy7574.co.uk. I am @nex:nexy7574.co.uk. I can join a room with @nex:envs.net (on the https://envs.net server) and talk to that account, as if we were on the same system.

This means that you have complete control over your data, and who you talk to. Although, you don't have to run your own server! There are plenty of open-registration servers. I would personally recommend envs.net, constellatory,net, or nope.chat.

Another cool thing about Matrix is that since anyone can run their own server, the client stack is entirely seperate! You might've seen my Matrix mirrors index page, which is a list of all of the mirrors that I run of Matrix clients (namely Cinny and Element). This means that you can use any client you desire, at any location. You aren't locked in to one client at one location. This is also great for censorship circumvention as if a domain the client you want to use is blocked, you can just use another domain. Furthermore, a lot of clients you can actually just run locally on your device! Clients on Matrix work by talking directly to your homeserver, rather than a central server for that app. For example, Cinny will load all of the assets for running the app from cinny.in, but in order to actually get information from your homeserver, it will talk to your homeserver directly.

My history with Matrix¶

I first used Matrix in high school, when I was looking for a way to chat with my friends in other classes. I needed some way to talk to people that felt similar enough to existing chat apps that I could access from the web, that I could also onboard them on to. I can't remember how, but I found Matrix, specifically https://app.element.io, and created an account on matrix.org. I didn't really use it a whole lot, and I struggled to onboard my friends due to some issues with end-to-end encryption (which I'll talk about later). After a while, I mostly forgot about it.

Fast forward a few years, and I was still using Discord mainly, however, I was getting more and more disillusioned with the platform. I was getting tired of constant outages, the harsh "no modified clients" policy, and generally degrading experience. I started looking for new places to build things on, and saw Guilded, but that never really grabbed my eye enough. I saw revolt.chat but I never found a userbase there. Then, finally, I remembered Matrix.

I came back to my matrix.org account, jumped around a few rooms, talked to a few people, and eventually decided I wanted to have my own handle on my own domain.

My first homeserver¶

Like any person wanting to naively just have a domain for their Matrix account, I went to the Synapse documentation and set it up on my Raspberry Pi 4b. I did not, at this point, understand how resource intensive running mass federation on a Python-based server implementation on a cheap Raspberry Pi was, and soon ran into issues. It worked great for a few months, but eventually as my account grew, and I got further and further into the network, I started to run into memory issues, and extreme slowdowns. Exit stage left, Synapse.

My second homeserver¶

On the same domain, I decided to run Dendrite. Dendrite is a Go-based homeserver implementation, and is meant to be the successor to Synapse. Dendrite, using a compiled language, was much faster and efficient than Synapse was. However, I failed to do proper research, and dismissed the "this is alpha software" warning.

I ran dendrite for quite a while, and it was fairly great. However, the team that was tasked with working on Dendrite did not have enough funding to maintain the project, and it is effectively in maintenance mode now. It is quite far behind in the spec and is lacking a lot of modern features, and ironically, is now slower than Synapse at a fair few federation tasks.

After a few more months, I got sick of using Dendrite, and decided to make the jump to another implementation.

My third and current homeserver¶

I initially looked at Conduit, a Rust-based homeserver implementation. I'm not a fan of rust, so I was already hesitant, however, don't judge a book by its cover and all that. I looked at conduit for a while, but could never find any satisfactory documentation. It just felt like a gitlab project with a binary and flashy website.

I can't remember how I stumbled upon it, but I found Conduwuit, a hard fork of Conduit. At the time, I saw that Conduwuit had a few improvements over Conduit that I liked, such as federated presence & typing, and a bunch of improvements that Conduit just hadn't implemented.

I initially set up Conduwuit in docker, but then later on re-installed my host OS to use Proxmox, instead of Ubuntu Server, meaning that I could run Conduwuit in an LXC rather than docker container. I won't get into why I did this here, but it was one of the best things I've done so far.

I have been using Conduwuit for many months now, and it's been a great experience. It is fast and efficient (can handle my account with several hundred rooms and thousands of federated homeservers), and has very active development. It is now leaps ahead of the upstream Conduit, and I have zero regrets running it.

Why I use Matrix today¶

I use Matrix for a lot of reasons today. I have met a lot of people on Matrix and made friends in a number of communities that exist pretty much only on Matrix. Sure, there's a few that brige to Discord, or IRC/XMPP, but the majority of the people in these rooms are Matrix users. I also like the freedom that Matrix gives me. By being able to run my own homeserver, I am allowed to decide what can and cannot be done on it (e.g. I can disable ratelimits and stuff), who gets to use my servers, and super importantly, I can control who can talk to me. Because I run my own server, I can block any user, or even entire servers, from communicating with me.

Another huge thing I like about Matrix is that I can use my own domain. By hosting a server accessible at nexy7574.co.uk, I effectively gain access to a whole namespace. This means that I don't have to fight to get a username that has not already been taken, and I can have a username that is unique to me. Furthermore, I can then use short usernames (like nex!) that are easy to remember and type.

I also like Matrix because there's a weird sense of development with it. You never know what challenges the next day may bring, what drama may unfold, what advancements may be made, and that constant but low-risk challenge is something that I find really fun. Of course, this isn't for everyone, and those people I strongly encourage to join a server that is already being hosted by someone else. I just like the technical and administrative challenges that come with running a homeserver.

Those who know me well and have spoken to me for a length of time will know that I LOVE to push the limits of software, and Matrix allows me to do just that.

Where I recommend going¶

Public homeservers¶

If you don't want to run your own homeserver, I can personally vouch for some of the following servers.

envs.net¶

envs.net is a great server run by the envs.net team. It has been around for absolutely ages, is quite large, and very stable. Envs also has a great guide to Matrix available, which you should definitely go check out if you're new to the platform.

You can sign up for an envs.net account at cinny.envs.net or element.envs.net. You will need to provide your email.

tchncs.de¶

Like envs.net, tchncs.de is a very large and stable server. tchncs hosts a number of other services for public use. tchncs has been around for a long time, and is a great server to use. It is based in Germany, so you know that it has some strong data protection (see their privacy policy for yourself).

They don't host a Cinny instance, but they run Element. A cool thing with tchncs is that you can sign up with a third party account, such as https://codeberg.org, https://github.com, or https://google.com!

The mismanagement of Matrix¶

So, Matrix isn't perfect. Matrix suffers a lot from administrative hurdles, and a lack of funding. Like XMPP, Matrix has a "spec proposals" system, which allows anyone to contribute a proposed change to the specification. However, these spec changes can often take YEARS to be implemented, if they ever are. A lot of really useful and promising spec changes end up getting bikeshedded to death. Changes also take a long time to get implemented, as there is a really annoying "well nobody else has implemented it yet so nobody wants it" mentality amongst both client and server developers alike. There is also a general seemingly disconnect between the Matrix teams and community developers, with a lot of ecosystem developers feeling like they are being left in the dark.

The authenticated media fiasco¶

This was especially prevalent when MSC3916: Authentication for media was merged. This MSC was a proposal to change Matrix's previously unauthenticated, open media system to require authentication.

On paper, this was great! It meant that homeservers now no-longer acted as CDNs and open proxy servers for media. However, it was very poorly implemented.

MSC3916 entered the "final commit period" on May 14th, 2024. This is a period where any final changes and concerns can be contributed before the MSC is merged, however, no major changes should happen. And then, one month later, it was merged into the spec. This was an incredibly short notice period for such a major change to be implemented into the spec and consequently clients and servers, and resulted in what was dubbed the "authpocalypse". As you can see after the merge, all hell broke loose. You can see just the sheer number of issues that were opened that referenced this singular pull request, and there are undoubtedly more that were opened that didn't reference it.

For months after this pull request was opened, and even to this day, there were users complaining that their client cannot view uploaded media. Many clients did not implement authenticated media in time for the release, meaning that users of those clients were left without any profile pictures, room avatars, or uploaded attachments until their respective clients updated. Furthermore this change has non-insignificantly reduced the privacy of many users, as many clients now require Service Workers in order to use authenticated media. Service workers are often not available in private/incognito browsing, and are commonly blocked in privacy browsers due to their ability to track users and remain in the browser even after shutdown.

Sliding Sync deprecation & Lack of respect for the ecosystem from Element¶

"Sliding Sync" is a concept in Matrix where the traditional "sync" is replaced with a "sliding", more efficient version. Traditionally, syncing would include all of the events that have happened since the last sync, and could take several minutes to complete. On the contrary, Sliding Sync was designed to be much faster, and only include information that the client actually wanted.

However, Sliding Sync is still an MSC, and has not yet been merged. However, the Element team decided that their new flagship client, Element X, would only support Sliding Sync. They also kicked up a huge storm about the release, citing that "Matrix 2.0 is here!". Meanwhile, only Synapse had half of the features they listed, and most of the "2.0" features (which are "here!"), were actually still unmerged MSCs.

This meant that on the release, homeservers who had not updated, and homeserver devs who had not yet implemented sliding sync, were harassed into doing so by impatient users. Of course, this was another case where only Synapse had implemented this thing.

Then, a few months later, Element decideded that actually, Sliding Sync wasn't fast enough, and deprecated it, releasing ANOTHER MSC called "Simplified Sliding Sync". Like the name says, this is Sliding Sync but simplified. Except, it needed re-implementing.

Now of course, Synapse implemented Simplified Sliding Sync. However, as of today's date (2024-12-16), only Synapse has implemented it. Dendrite hasn't, none of the Conduit forks have, and even the Sliding Sync proxy, designed to give servers without Sliding Sync a way to use it, hasn't implemented Simplified Sliding Sync, but instead just got swept under the rug and deprecated too.

This would all be fine and jolly, if it weren't for the fact that Sliding Sync support is being entirely removed from the Rust SDK in January. This means that currently, any client that uses the rust SDK (which is a lot of them), will be unable to use any server other than Synapse after January. I'm sure that other homeserver implementations will catch up before the deadline, but for some lower-priority servers, such as Dendrite, they may take a long, long time to get it implemented.

These sudden, swift, and devastating changes from Element (the company) have left a lot of ecosystem developers feeling like they are being left in the dark, and generally just disheartened with the process. And, as a user, it feels like Element, and the Matrix Foundation, really don't care about anything but the profit of their enterprise customers with Element X/Web and Synapse (now with Synapse Pro, too). The ecosystem and general open-ness of the protocol feels overshadowed by the needs of the enterprise customers. Hell, the Element X clients still don't have custom emoji support. Which has been in basically any other client for years now.

Conclusion¶

I know it feels misplaced to put this straight after a section about the mismanagement of Matrix, but I do genuinely believe that Matrix is a great protocol. If you want something that is decentralised, federated, and open, then Matrix is a great fit. Furthermore, if you're someone technical and want to play about with a homeserver, running a Matrix server can be a great backburner project.

It has its flaws, but I hope that the protocol can grow, improve, and find its userbase. Great things can happen. And, with enough effort, the protocol can be brought up to scratch with modern day centralised chat apps, but with the added bonuses of additional privacy and control.

Further information¶

If you want to learn more about Matrix, you can look at https://joinmatrix.org, who do a great job at explaining Matrix.

If you're looking for some clients to use, take a look at the ones I host.

Also, I run a public homeserver. The registration token is on https://transgender.ing/services.txt, and you can sign up at https://chat.transgender.ing or https://element.transgender.ing! Please contact me in #general:nexy7574.co.uk if you have any issues.