(This article is made in a similar vein to a Luke Smith article about web browsers.)
Since the dawn on the internet, people have seeked to use it as an effective way of communicating in real-time with others – even from across the globe! This is where the idea of a chat protocol and associated chat client comes in. This article seeks to act as an effective breakdown of every major usable chat protocol and client so you can make your choice wisely. Don’t worry, none of these chat clients is perfect, so you can never truly make the “right” choice!
A Proper Protocol
Notice I say “protocol” rather than platform/company. It should be a given that a good chat client wouldn’t use some proprietary, walled-off chat system that isn’t inter-operable with your own self-hosted server. That means no Discord, WhatsApp, Telegram, Signal even…
In addition to this, decentralized protocols like Tox, Session and the like don’t apply because they are not reasonable solutions for most people. Any chat system that requires the user’s device to be constantly online is not usable. These may be great for one-off and coordinated conversations, but it’s nowhere near the level of intuitiveness of Email or similar “federated” technologies. Federated, always-on servers are a necessary evil.
With this said, this leaves the only usable protocols as:
- Matrix (Which has its problems, but it’s still generally better than everything else out there.)
They both have a sizeable user-base and are mature enough to be reasonable choices for modern chat.
For all reasonable uses, a client should support end-to-end encryption. Luckily, most XMPP and Matrix clients support this natively, although setup is rendered slightly more complex on XMPP.
Short for “Off-the-Record” messaging, this is a simple method of encryption that generates a secret and public key pair for each user. The key difference being that OTR does not support sending messages while a user is offline, making if unusable for most people.
This is the familiar encryption scheme used on Emails. The biggest downside is that you’re relying on a single key for all your communication across all devices. Because this key never changes, if someone gains access to your key, all your previous conversations are compromised!
(AKA, the one with the fish.)
This is the de-facto standard for XMPP encryption nowadays. OMEMO works by generating a new key every single time you sign into a new “device” (ie. XMPP client) and that key gets broadcast to all your contacts when your device is online. Once your contacts have your public key, they can encrypt messages and send them to you any time, even when you’re offline! Just make sure to disable old OMEMO keys when you sign out of unused devices.
You can track the progress of getting XMPP clients to support OMEMO here.
Conclusion on Encryption
Matrix has succeeded at making decentralized chat encryption a rather painless experience. Encryption key backups are supported, allowing you to retrieve old messages even if you’ve lost the original device. Its implementation is certainly superior to XMPP, although the prevalent metadata and bloat issues Matrix suffers may be considered greater threats to its security.
In the world of XMPP, OMEMO is the most reasonable choice out of all of its encryption schemes. It will be a requirement for any XMPP clients listed here from now on. With this, XMPP clients like Thunderbird (which don’t support OMEMO) are out of the race!
Push notifications aren’t an issue on a desktop device, where your chat client would be running in the background anyways. However, they are a requirement on a phone when you actually want to know when you’ve gotten a message or a call. On Android, systems like these rely by default on pesky Google services, however this can be circumvented with some alternatives mentioned below. Push notifications are especially an issue on iPhones, since unlike on Android, they don’t allow apps to listen for notifications in the background (as both Element and Conversations do on Android).
At the moment, Matrix supports push notifications through Unified Push, and XMPP has its own implementation which is available in Prosody through a community extension and is included by default as a module in Ejabberd.
Voice and Video Calls
Before I begin this section, can I just point out how funny it is that one of the Tigase developers is seen calling himself in all the pictures for its voice/video call feature? Now that’s some grade-A marketing right there:
Calling is the “gotcha” for most clients. With this, you’ve already ruled out every command-line chat client in existence, barring some obscure Mumble one which isn’t even for messaging. Sorry, Gomuks!
As of the writing of this article, neither XMPP or Matrix have “native” support for group calling. Now, technically, XMPP does have a few unofficial implementations of this feature, but most of them rely on a lot of specific client-side support. It’s nowhere near as universal as something like Discord calling or standalone solutions like Jitsi or Mumble.
On the Matrix side, there’s Element Call which is implemented into certain clients, but this still isn’t a truly “native” calling feature; It still relies on a central “Element Call” server you can self-host, essentially making it a Jitsi clone where you can use a Matrix account instead of an anonymous identity.
TL;DR: If you wanna group call, use Jitsi or Mumble, preferably with your own instance. There is no usable implementation in either XMPP or Matrix for group calls right now.
At the moment, there are 3 Matrix clients that support private, peer-to-peer voice and video calls. You read that correctly, 3:
- Element/Schildi (A cross-platform client. “Schildi” is a fork of Element)
- Nheko (A desktop client)
- FluffyChat (An Android and iOS client)
In the XMPP world, there are slightly more:
- Movim (Not really a client, we’ll get into that)
- Conversations (An Android client, with many related forks)
- Dino (A Linux client with an unofficial Windows fork)
- Siskin and Beagle (iOS and MacOS clients)
(There are technically more than this, but many of them are incompatible with each other or super old with no support for modern encryption.)
Ok Great, So What do I Use?
When every single client sucks, the best solution is to just use multiple clients to compensate for their varying weaknesses. Here’s a list of clients I use for chat:
Gajim for XMPP on the Desktop
I’ve not mentioned this one in the article yet, why is that? Well it’s because on paper, Gajim doesn’t meet many of my requirements. Especially voice and video call support, which it used to have but now doesn’t support with modern clients (like Conversations.)
With the addition of integrated OMEMO support however, Gajim is now a really good option if you don’t mind using your phone for voice and video calls.
Conversations for XMPP on Mobile
Conversations is probably the most well-rounded client out of all the options in the world of XMPP. It has full support for encryption, voice and video calling and push notifications. Its many forks are all pretty good too, especially since they borrow most of the important features (like the calling). It doesn’t have as many administrative tools for server admins (like Gajim) but it’s ideal for mobile use.
Element for Matrix on the Desktop/Mobile
Yep. Get your torches and pitchforks ready.
The bloated, web-based soyware known as Element is unfortunately the only client I know of that works consistently both on the desktop and on mobile devices. I’ve experimented with Nheko and FluffyChat before, but encountered numerous bugs or usability issues (like Nheko being unable to start new Matrix DMs without creating groups.) So I begrudgingly conclude that Element (and its fork, SchildiChat) is the only Matrix client I can bring myself to use for everyday communication.
So yes, every chat client absolutely sucks. But what I can tell you is that they would suck a heck of a lot more if there weren’t all these talented developers and protocol standards to help!
The fact I’m even able to make these comparisons is wonderful in itself; it means people all over the world are working to write genuinely useful pieces of software. Also, remember that an article like this is never static! Clients change over time, and there are plenty of promising developments in the world of XMPP and Matrix that will make it so maybe, someday, we may have a usable client.
Written by Alex [→ Reply-To]