Truly Private Messaging Clients
This post was updated with feedback
Chat or Messaging?
First of all it is useful to make a distinction between messaging and chat clients. Those two use cases get thrown into the same bag a lot, but the requirements are actually quite different.
Messaging
Messaging clients are intended to provide a direct communications link between two people, sometimes with an option of expanding this to a (small) group of people. In both cases the members know each other on a first hand basis. Chances are they are in each others' address books or contact lists. They do not seek to meet new people. They merely want to establish a channel between previously-known people.
What counts is positive identification of who is on the other end, with a notification if what happens is not what's expected. The contents of the communications are private and must remain so, also into the future. The privacy requirement also extends to incidental metadata, such as message transaction logs and relationship graphs.
Extending the communications beyond mere texting and media attachments, a requirement is often raised to also support voice and video calling.
Messaging can be server-based or direct peer-to-peer, or a mixture of both.
Chatting
Chat clients, on the other hand, are tools used by people who would like to participate in losely-knit groups of people discussing topics of mutual interest.
Predominantly the participants do not know each other face to face, and membership of the groups will fluctuate over time as people lose interest and new members join. Some of these groups reach hundreds, even thousands of members.
Usually chat groups will be hosted on servers, either standalone or federated. Due to this it is almost impossible to control the spread of metadata as every server must out of necessity be trusted to properly care for its privacy. Message contents can be encrypted, but that will usually be client-to-server, not end-to-end.
What's a "truly private messenger"?
Now with those definitions out of the way, here are my thoughts on messaging clients.
Encryption
This is the most obvious requirement: encrypt the payload end-to-end so that only the sender and the intended recipient(s) have access. Besides the actual algorithm used, factors such as plausible deniability and forward secrecy have to be taken into account.
Agreement on encryption keys can be a massive showstopper for widespread acceptance, often dominated by the perceived ease of use. Trust-on-first-use tends to be the "easy button" though it comes with serious security drawbacks.
It's nice if TOFU as well as manual keying is supported.
Server Infrastructure
Modern messaging protocols do not need central server infrastructure. These are rightfully labeled peer to peer messengers, and are vastly superior to anything that relies on infrastructure, especially when that is centralized and run by a single entity.
This infrastructure is liable to government intervention such as wiretapping and subpoenas. It can be taken offline or otherwise fail at any point. And it is hard to control metadata when all messages travel through a single place on the net.
Steer well clear of these systems.
User Identification
As opposed to chat systems, which rely on users being able to find other users, messaging clients don't have to rely on such functionality since participants tend to already know each other. It can be a bonus addon, which makes it easier to add peers to the personal address book, but as messengers such as Session demonstrate it is perfectly possible to add other people simply by copying and pasting long and obscure hashes or scan QR codes.
Prefer messengers that make user identification optional, and be very wary of ones that require central registration.
Metadata
It is surprising how much information can be gleaned merely from the metadata surrounding communication events without the actual message contents actually being captured.
Information such as a graph of personal relationships; frequency and timing of messages between individuals indicating their relationship status; message size indicating whether media is exchanged; etc. all might give away evidence that in some cases makes the actual content of the messages irrelevant.
Peer to peer systems can be very hard to capture such metadata of, especially if they use some form of obfuscated transport (such as onion routing) to deliver messages.
Recommendations
Keeping the above in mind, my own personal recommendations for messengers as of right now are the following, in no particular order of preference.
Session
A virtual lookalike to Signal, but serverless and with a form of onion routing. Clients are very "mainstream-y" (which is good), but have some odd niggles which may hamper adoption by non-techies.
For example you can only share addresses with others by using the system-generated hashes as there is no discovery function for peers. The interface is very sparse, and some of the options are rather hidden; such as renaming a contact by having to long-press on the avatar, then entering details, and finally clicking the edit pencil.
Detracting from the otherwise positive impressions are a business model for the swarm operators that is based on cryptocurrency exchange, and the possibility of a "Pro" version that is somehow offering services above the "Free" tier. As of early 2022 it is unclear what exactly this will mean.
Tox
Tox is a very interesting protocol, which is published as a set of libraries with no central institution operating any kind of service around it. A number of good client implementations exist. For Android specifically Trifa is very nice.
A feature of the completely serverless implementation is that both endpoints to a conversation have to be simultaneously online. This harks back to the IRC of old, and indeed the solution/workaround is similar: use a proxy. As explained on the Offline Messaging Wiki page ToxProxy can be used -- but only with Trifa at the moment. All other clients implement a pseudo-offline function in that they buffer messages to be sent transparently, but still sender and receiver need to have overlapping online time for the messages to actually be sent.
Lack of central marketing is another limiting factor for Tox, leading to very poor public awareness of the protocol outside of the nerdspace.
Jami
With its official Gnu project status and an architecture that encourages plugin development, Jami is a very streamlined and "normie-friendly" approach which is also rather feature rich - almost the antithesis of Session which is reduced to the max. Unfortunately especially the mobile clients have a reputation for rough edges and somewhat unreliable operation. Quite a bit of finishing work remains to be done.
Creation of a user id on directory servers is optional, though might be useful to boost acceptance. All three server types can be run self-hosted if so desired, and in any event only the Turn server is required if NAT is in use (which these days it almost invariably is).
Others
A number of other systems exist, some of them quite technically interesting such as Secure Scuttlebutt (SSB).
I will be following up with a new edition of this post as new material becomes available.
Non-Starters
Just very briefly:
Briar: no iOS client means acceptance will be very limited. Does not provide a peer discovery function except when physically present in the same Wifi network or within bluetooth range. With iOS support this would be a very strong contender, or put another way: if you don't need to support Apple users this might be the platform for you.
Wire/Threema: central closed-source server infrastructure.
Signal: central server infrastructure, which is "somewhat" open source (search for the flame wars having erupted on this subject in early 2021).
Telegram: central closed-source server infrastructure, proprietary encryption protocol, unclear business model, lots of other problems. Features prominently on the radar of law enforcement agencies due to lots of criminal activity in various "dark" Telegram groups.
Summary
All three of the recommendations, plus Briar, operate without complete reliance on a central infrastructure (Jami's Turn servers excluded) and leave little to no metadata traces. You won't go wrong with either.
Other than Session, both Tox as well as Jami support additional features beyond messaging; namely, voice and video calls. As of 2022, Session is strictly for person to person or group chat text messaging - including file attachments - only.
My personal recommendation is: Tox, if you can get your circle of communication partners to move to it.
If not, Jami or Session both of which might be an easier sell. Jami has more bells and whistles but is still somewhat unreliable, Session looks almost like Signal but with a reduced feature set. If you don't know anyone with an Apple device, Briar is worth a look too.
The most practical option has been for years and remains so, Signal. But it does come with the limitation of the centralized infrastructure, albeit the least privacy-intrusive of all of them.