gnum4n

I'll take a crack at this one. I've been using matrix and element for over a decade as my main messenger, and it's great, but it also does suck. I even use it for my business chat. It's pretty much the most popular federated encrypted client right now, and it seems to have taken over XMPP's lead. So here's a nice list/rant about why matrix/element sucks.

1. I spent 15 minutes last month helping my business partner sign onto ElementX on his second phone. He's signed on his PC and his primary phone, but the second phone was very difficult. Basically type username and password, but now you have to verify with emoji. How do you do that? Well, sometimes it pops up on your other clients that a new client needs verification. Sometimes the popup never shows, and there's no way to find it. But we found it eventually. Verify via emoji. Great! Let's do it. Oops, it timed out before he could finish. Apparently it has a super short timer that even I struggle with it. Eventually we gave up and used the recovery key, which worked, but you know many people are going to lose that key since it's not a password they can just memorize. Most other messengers, it's just username, password, and then click the email confirmation link. Boom, easy.

2. Audio/Video calling/conferencing. There are apparently 3(?) different technologies in Element alone, depending on which version of Element (desktop, web, mobile). The "old" one is jitsi. The new p2p one appears to be only available to clients that aren't Element? Or you can only create conference rooms in those other clients (commet?), but you can join them from any client. But then those new rooms are sometimes not join-able from Element clients. They just don't appear in the room list at all. Even clicking a link to the room says it's the wrong "room version", but it's a freshly-created room. So I delete the room and make another new one. But now it's a Jitsi room and it doesn't work in this other Element client (all first-party actual Element clients, and all broken in slightly different ways!). So... it's working now, but only after lots of trial and error and lots of cussing from my business partner. And I have to somehow justify that this is better than using Slack/Discord/whatever corporate thing.

3. The official client is fragmented. On mobile, there is Element (classic) and ElementX. You're _supposed_ to use ElementX, since it's the new one, but ElementX does not have all the features of Element (classic), so you might need the Element (classic) client for those things. But Element (classic) is not getting updated, so you're left in the cold as far as updates and the new features (meaning you might not even be able to cross-verify your clients, or join video calls, spaces, etc.)

4. The official matrix server (synapse) is pretty slow. I hosted a couple small communities (~100 people or so?), and synapse somehow kept getting overloaded and crashing. Maybe it needed more than 4GiB, but that seems kind of silly. There are decent 3rd-party clients (continuwuity is my current favorite), but there's no migration path from one server to another without wiping your entire database and starting fresh. So.... my main homeserver is kind of stuck on synapse.

5. Bridges. Yes, you can bridge anything to anything, but have you actually tried it? Interface is super clunky. You have to run a separate bridge service, make sure it swaps keys with the matrix server via a yaml configuration dance, then talk to the bridge's bot in a dedicated matrix channel with special commands that may or may not get your bridge working. I've used signal, discord, telegram, and irc bridges, and they're all a mess in one way or another. My most recent attempt was with the signal bridge. I made the mistake of enabling end-to-end encryption. One day, the bridge server restarted and lost all its encryption keys. Cool, now all the bridged rooms are dead. So naturally, I delete the bridge service and re-configure it from scratch. Now it doesn't work because its bridge bot username was already taken by the previous instance with the lost encryption keys. And I can't just delete that bridge bot user because _matrix does not allow deleting users ever!_. So now I have broken signal bridge rooms and broken signal bot users that I can't ever delete, even with the admin panel. So naturally I open up a postgresql client and delete them manually. Oops, now my matrix database is broken in ways I cannot even begin to comprehend. Because deleting users is not allowed. So now I just can't have a signal bridge. _maybe_ there's a way to make it work, but I've been programming and sys-admin'ing for over 20 years, and it's just beyond me. I'm going to have to (again!) wipe out my homeserver and start over, losing all my messages and contacts (again!). XMPP had very nice transport services, and Psi+ had a very nice UI for configuring and organizing them.

6. Multi-identity support is lacking in all the official and most community clients. If I have a work account and a personal account, I need to start two separate Element clients. Each one is a hefty electron app, and they all have the same systray icon, so I need to trial+error every time to open the right one to message someone. So far, there's only one client I tried that had proper multi-account, and I think it was commet. It was ok, but I hated that it was a flutter desktop app where every click felt super unresponsive. So I went back to Element. Most XMPP clients have multi-identity built-in. I'm not going to use my work identity for personal chat, just like I'm not going to use my hackernews account to message co-workers.

7. No message auto-deletion. Many people like to claim that Element is more secure than Signal. It is not. If you live in an oppressive country where things you say can easily result in prison or torture, you need more than E2E encryption. You need messages to be gone. You can't trust that your device or your friend's device won't get confiscated and forced to reveal your password. Even the United States has forced device unlocking at the borders. Signal (and Confide, and even Telegram) have automatically deleting messages, so even with the keys, there's nothing to see. Matrix stores messages forever. Aside from some complicated server-side setting, there's no way to automatically delete them. You have to right-click and manually delete EVERY message if you want future privacy. Nobody's going to do that. And I tried enabling the synapse settings for auto-deleting messages, but they didn't work. It seems that feature isn't really tested, or it's documented poorly.

8. The spam/CSAM problem when running a public community. The admin tools are a bit lacking, so without some considerable expertise, it's often not worth even having a community matrix server. So folks just make a discord instead, which has actual moderation tools builtin. Yes, I know there are external moderation tools you can install, but why should that be required?

9. The protocol is too complex to make full-featured 3rd-party clients. This isn't IRC where you can make a basic client in 3 lines of perl. You'll notice that the 3rd-party clients are all lacking in some features of Element, the official client. Even the official ElementX client lacks features of Element Classic. Most folks are stuck on the official electron-based Element client, which has a fairly clunky UX (try explaining to your grandma how to cross-verify clients).

This list is just off the top of my head. I could probably write a whole book on the problems with the matrix ecosystem. But again, matrix is the best we have. IRCv3 hasn't really caught on, and the need for an IRC bouncer to receive offline messages isn't commonly excepted in 2026. XMPP was/is ok, but it hasn't been commonly used since Google Hangouts pulled the bait+switch on us 10+. I keep thinking I should really just go back to XMPP, or start using delta.chat since "everyone" has an email address.

I often can't even get fairly technical folks (who write code by hand, etc) to use Element, even if I do all the server setup and just hand them the keys. It's too hard for most folk. It's too hard for me, and I've been maintaining my own matrix servers for 7+ years. I maintain 3 matrix servers right now. One synapse, and two continuwuity. NixOS makes it pretty easy to maintain servers, actually, as long as they're not open to the public.

And if anyone asks me "what should we use instead?", I'd probably say XMPP or IRC. And we know neither of those is perfect, either, and nothing open source and federated is as easy to onboard like Discord, Signal, or Slack.

But even though Element/Matrix sucks, it still works well enough for me to use it as my main communication. At least until I finish my own multi-protocol messenger. Which I started about 6 years ago and haven't had time to work on.

Disclosure: I wrote some of the code on Confide's backend back in 2021. I do not currently work at that company and am not promoting or un-promoting the app in any way.

That is a very good point. Why buy big iron "pets" when you can buy x86 "cattle"? It works for a lot of stateless apps and services. A node dies, and k8s quickly moves the workloads to new nodes.

It does take some work to accomplish this on more complex apps, though. Things like SQL databases and rabbitmq are very often single points of failure in practice. At smaller companies, it's often easier to stick them on more resilient hardware than to architect an active/active or active/failover system. I agree that this isn't the best way to do it, and IMHO any important service should have HA of some sort.

That said, I use x86 based machines for all my personal projects, and I wouldn't buy IBM systems if I owned a tech startup just because they're like 10x the price of x86.

And now that they bought RedHat, they're eagerly dropping support for all linux distros that are not RedHat, and they're attempting to lock out anyone who wants a personally affordable RedHat-like system (CentOS...). If they succeed, it may even be hard to find decent RedHat sysadmins in the future.

It's hard to keep up a trained workforce when they lock the doors so tight.

Aside: I hate the popup subscription CTA that asks for my email address in the middle of reading the article. How could I know whether I want to subscribe before I finish reading, and why interrupt my reading the article at all?

There are clearly marked "Subscribe" buttons at the header and the footer of the page that I could use if I wanted emails. But there's no RSS/Atom feed.

I'm just a grumpy programmer that gets annoyed by unnecessary interruptions. I'll see myself out...

Former P-series/AIX SME here. I agree 100%. IBM's training programs are a joke.

P-series and mainframe machines have a lot of cool tech, and they're very resilient. They can even lose a CPU or some RAM and keep running. x86 systems would more likely freeze/crash immediately.

But the only reason I know P-series/AIX at all is because one small branch of IBM hired me for my linux skills back in 2011, and I learned on the job. But I quit after 5 years, because the pay wasn't sustainable. The machines are too expensive to play around with otherwise. If you learn by doing (which seems vital to be a good sysadmin or programmer), even a license to use AIX is out of the hobbyist's price range. Training courses are limited lab environments. You won't get nearly as much out of that as you would from a 12-month AWS subscription, or a $5/month VPS, or an x86 virtual machine, or a raspberry pi. etc, etc.

And IBM ended their developer machine licensing. So now employers can't even afford to maintain extra P-series machines for devs/sysadmins to play around with and learn.

But don't worry, IBM will keep shooting their feet off until they no longer exist. There will likely be a panic, similar to Y2K, where everyone's feverishly re-writing and porting and emulating and migrating things off of IBM iron and onto x86 machines.

As a former P-series/AIX specialist, I can say that the pay is not as good as a decent linux job, and the career growth potential is very low. Your career options are basically to maintain legacy systems until they can figure out how to migrate it all to linux.

And if you get laid off (happens a lot at IBM lately), your career prospects are to either wait for someone to retire/die or learn linux.

No matter how important they say maintaining the legacy systems is, the pay is low enough to easily convince people to take any other IT career path.

My Windows PC is only for gaming. That said, I found a simple way to avoid the worst of the Windows update problems: Always stay at least one major version behind.

That means lagging on Windows 7 or 8 when 10 was current, and lagging on Windows 10 until Windows 12 comes out. Microsoft puts most of their offensive junk on the latest Windows, but still back-ports useful features to Windows 10, like WSLg.

It's not a perfect system, and I may get malware someday from missing security updates if Windows 10 goes EoL before Windows 12 comes out, but having the occasional ransomware hit a gaming PC seems almost less annoying than the current nasty Windows updates. I wish I were joking. I have enough stress in my life where I don't want to fight with my OS as well.

I run linux/NixOS on all my important machines, including work.

Ask for more stock/promotions/pay. You won't get what you don't ask for. As an early employee, you have value in your company knowledge.

Otherwise, I'd probably just leave for a company with better pay and better work/life balance.

I've done the startup rodeo before. Worked several nights till 1am. Once worked till 4:30am, slept 3 hours and then right back to the office. After 18 months at that job, badly burnt-out, I was rewarded with layoff and had to find a new job. Never again.

It's much less stressful to just get a higher paying job where you only have to work 6-8 hours a day, with maybe an on-call rotation.

Yeah, but if the phone/browser decides to delete some of the PWA's code to save space, you won't be able to use any maps at all until you connect back to the internet.

Before you say "just download the code to your phone as a file", I'm going to assert that's exactly what an app is ;)

Yes, "Add to home screen" is exactly how you install a PWA to your phone =)

It's a bit confusing, isn't it? "Add to home screen" makes it seem like you're just adding a link, but it's installing the PWA, possibly enabling notifications, and etc.

The UI looks pretty neat, but the install instructions are essentially "curl {url}/install.sh | bash -", which is kind of icky and runs a bunch of sudo commands. Since you're using Docker anyway, why not provide human-readable instructions?

Or, alternately, separate the config process from the install process. I'd be much more comfortable running config commands from a script inside the docker container, or as a first-run setup UI, or as a simple .yaml config.

It does look like something I'd like to try out later, though. Either after the install process is cleaned up a bit, or once I have time to read through the whole install.sh script.

Edit: In case it matters, my personal preference is to install things as linux packages instead of Docker, but I understand that this is a stretch for early-access software.

If Go does have some kind of "__builtin_expect" equivalent, I can't find it.

I'd say it probably doesn't exist. Even if it _did_ exist, the Go compiler authors would reserve it for internal use only, like they do with most other Go compiler directives.

Author here. Thanks for the advice! That's a very good point.

Maybe it's worth doing a follow-up on this? I originally thought of doing unit tests to ensure it's actually running in constant time for different inputs, but I'm not sure they would run well on anything that wasn't bare-metal (probably too inconsistent).

Have you done this with Go or any other compiled language? I remember a colleague of mine was looking into C++ assembly generation rules a few years ago, but I haven't heard how far he got.

In that case, the code would probably work like the C code example I gave. So... I guess you're right. It _can_ be done in Go without `if` if we use unsafe. I can't argue with that =)

In general, I try to to avoid using unsafe as much as possible. Not because I worry that it's "unsafe" or prone to errors (I'm experienced in C, C++, and assembly), but because it makes the code harder to read, and I don't think my coworkers would appreciate that. ;)