IM protocols and clients and FOSS

2022-06-01

I'm publically announcing my move off of the signal chat protocol controled by Whisper Systems. I'll still be on there occasionally for now, but I'm almost always available on matrix @mbrewer:matrix.org.

I've been considering various options. I'm unwilling to consider using anything that doesn't support end to end encryption, or anything with more central control than Signal. But, these days there are actually options in this space! Signal is not the most FOSS/libre player anymore. And their insistance on only supporting the Android/iPhone ecosystems is a major downer. The other two options I found are Jami and Matrix. Here's a "feature" matrix for matrix, signal, and Jami.

Summary:

System Functional e2ee Open source FOSS/libre centralized clients available Required OS
Signal yes yes mostly no yes Whisper System's provided Android or iPhone
Matrix yes yes yes yes federated Dozens available Android, iPhone, linux, OSX, Windows, Arm and x86, can easilly port to other OS/Archs
Jami no yes yes yes fully decentralized one FOSS client Android, iPhone, Linux, OSX, Windows

For me Matrix seems like the clear winner. Jami *sounds* good but when I tried it I couldn't actually work. So Matrix it is. More details below.

Problems with Signal

Whisper Systems has talked about a first-class desktop client for years, but nothing of the sort has materialized. They have a desktop client, but it can only be used secondarily to having a phone by mere mortals. A few people have managed to run it as a primary client, but you have to do a lot of hacking around the system design. As a result to really use Signal you must own an iPhone or an Android phone with a valid phone number and be willing to register that with Signal. For me this is a practical matter. I don't own an Android phone and don't intend to any time soon. Many folks have also pointed out that in many countries you can't get a phone without basically registering your identity with the government as attached to that phone. That raises privacy related safety issues for those dissenting from their government.

While Signal protocol is public, and some code is open source, it is neither FOSS/libre nor an open system. Whisper Systems has singular control of the server side of the system. My understanding at least is that the server code they publish is out of date. But, most importantly, they change the protocol whenever they feel like it. This means that in practical terms only they can provide consistantly functional clients. This has been demonstrated by attempts like axlotl to fill the application gap for first-class desktop IM clients. axlotl does work for some people some of the time, but it's flaky at best. In reading about axlotl it appears this is due to the constantly moving target of the protocol, as represented by the server-side software run by Whisper Systems. When I tried axlotl I got stuck in a perpetual auth loop.

Let me be clear. I laud Whisper Systems and the developers there for their efforts. They have changed the entire conversation around e2e encryption and chat protocols, making e2ee available to normal users, and doing it well. For a centralized chat ecosystem they are doing a better job than anyone else out there, and I'm NOT condemning that effort. They take security seriously, they open source the important parts of their software so anyone can audit it. From a pure security perspective they are doing everything right, and that is not only rare but basically unheard of in the software industry.

What I am saying is that I demand more. There is no reason we should be locked into a single provider for our chat services. While they provide a valuable service, they do so on their terms with heavy centralized control of the overall ecosystem. Sure you can run a 3'rd party client, but they don't announce ahead of time that server support is changing, so while they *allow* it, they don't *support* it. I'm not a FOSS/libre purist actually. I just want to be able to use my software in certain ways, and control my own systems, and this is just one more case where those desires are in practice incompatible with more closed software ecosystems.

Problems with Jami

I attempted to use Jami for some time. Jami sounds ideal in that it basically drops the server-side entirely, using only a very thin server for aiding in NAT traversal. The problem? It doesn't work (yet at least). While I did manage to chat with my wife occasionally with this software it was so flaky as to be useless. I couldn't predict when it would or wouldn't work. I had to restart clients frequently. Whether this is the protocol or the client I'm not positive, but whatever the reason it's not currently a usable option. After a couple of months of experimentation I gave up. Besides these problems Jami is harder to use for normal users. For example: with no server there is no such thing as account recovery. The model is confusing, and the chance of lockout for normal users is high.

Is matrix really better than these?

While I think Jami's vision is absolutely the ideal. In practice Matrix.org seems like a better balance between usability and encryption, striking a similar balance to signal, and most importantly, matrix actually works. Matrix is a fully open federated protocol that also supports e2ee and has dozens of fully FOSS/libre clients, and multiple FOSS/libre server-side implementations. Matrix.org provides an easy default server for the normal user much like Signal, but unlike Signal if someone is dissatisfied with that they can go off and run their own server and still chat with folks on other servers. And because the protocol spec is a well defined standard there are many clients available for basically anything, many of which work consistantly. And if you have an extremely weird use-case (you're running OpenBSD on a vax) you can always port a client yourself.

I've run into one significant flaw in Matrix. E2ee support in the client is *optional*. This is sensible as Matrix can also be used as an IRC replacement (open chatrooms), where encryption is likely not that valuable. As a result though many clients don't support E2ee yet. I recommend "fluffychat" as I've had the most luck with this client. My wife runs it on Android. I run it on an ARM64 linux phone and an x86_64 linux tablet. There was an issue with it getting stuck in right-to-left language mode on linux caused by an underlying library but it's been resolved. Element would be my next recommendation. It worked well for a while then broke on me last week. To be fair though I am using debian unstable so it may not be the application's fault.

Conclusion

As someone who has opted out of the iPhone/Android duopoly, Signal is basically not an option anymore. So I'm using Matrix as my primary chat platform. I hope I can drag a few other folks along with me.