Hello :)
You will find here an evaluation of several instant messaging software, that I try to keep up to date.

While these are great projects and have interesting features, they all have different aspects that I don't like:

I understand that it is a benefit to use these projects and encourage the users, who were not using a secure messaging application, or voice call system, to get used to one of these apps.
Better security is usually better. The higher number of people, using daily crypto in their communications, the better.

However, as I indicated, all these projects suffer from a couple of drawbacks that harm the confidentiality and security of the communications.

I'm convinced that users of Internet should really be owner of their data and metadata as much as possible. I also argue that Internet real value does not hide in high scale centralized architecures, such as provided by GAFAM (Google Apple Facebook Amazon Microsoft). This would just be a scale change with terminals and mainframe we experienced long ago.
Instead, we should really take advantage of having a common global network to push for peer-to-peer, decentralized and distributed protocols.

That said, here are the main features I want to have in my loved messaging app :

Based on these criteria, I selected 2 free software projects.
These 2 candidates are the best that match closest to what I seek : Jami and Tox.

Signal bad point is the requirement of a phone number.
Now, also Signal is making good efforts to reduce metadata exposure, it won't solve the centralized model key issue, all communication connects to Signal servers.
The only way to get rid of that is to turn to a decentralized and distributed model.
Now users have to decide what level of privacy do they want.

Jami has been created by Savoir-faire Linux Inc. It is written in C/C++. Jami is based on SFLphone.So all communication is based on SIP, RTP, TLS, ICE, STUN, TURN (TCP and UDP). In order to locate users across the network, DHT is used. Bootstrap nodes are used for first connecton. The application can run in several modes, it is not limited to peer-to-peer communication. Federated and clent-to-server modes are both possible also, so it means we could also use it to connect to a central IPBX such as Asterisk. I haven't tested that part, as I want to focus on the p2p features.

Free software license : GPLv3

Distributed : Yes, working with bootstrap nodes and OpenDHT across all clients : SHA1 40 characters signature of "callto:" + ring_id_hex. So it is based on the user's RSA public key, but the public key itself it never directly hosted on OpenDHT nodes. The list of OpenDHT peers is frequently updated as this is a real dynamic ecosystem.

End to end encrypted by default : Yes, it uses a combination of high security level of TLS for all communication, RSA 4k keys, SRTP, SIPS, AES_CM_128_HMAC_SHA1_80 / SRTP_AES128_CM_HMAC_SHA1_80, AES_CM_128_HMAC_SHA1_32 / SRTP_AES128_CM_HMAC_SHA1_32.

Minimize metadata exposure : all data connection that is needed between 2 clients and OpenDHT nodes are signed+encrypted using RSA pki material of sender and recipient. OpenDHT nodes cannot see the contents of these messages. The real identity is thus not public. Even though if you know the ip address of clients, you still don't have access to users' public key, so identity is not directly revealed. As long as users don't reveal their public key by other means of communication, their ring identity is private.

Signup : no phone number or email required.

Clients platform : Available for GNU/Linux, Android, MS Windows, MacOSX

Tor friendly : No. Tested with Orbot and SOCKS proxy, client could not connect ring network. => Jami is SIP UDP based.

File transfer : Yes.

Voice calls : Yes.

Video calls : Yes. Videoconference features. Screen sharing.

Should not rely at all on Google resources : No use of Google API.

Multidevice support : Yes, distinction between device ID and user ID.

API for interoperability : There is an API that allows for developing custom clients. These could be also used for modules to interact with other messaging clients.

Blockchain integration : Ethereum smart contract is now used in Jami. It is used for the public key directory. Users can opt in or out from the public ledger. This let the user control whether his contact is the ring id or a name associated. Ethereum blockchain is then used to provide long term distributed public integrity for the directory. This means you can identify your ring id as alice or bob, or you can keep your ring id as only contact endpoint that does not reveal any particular name. Ethereum blockchain then ensures correct integrity. Efforts in QA are made to avoid critical vulnerability in the smart contract code.

IPV6 support? : Yes

Tox has been created by a bunch of people in reaction to Edward Snowden NSA surveillance methods discosure. It is written in C. It follows same abstract as Jami : use DHT to locate clients and setup connections for peer-to-peer communication. It works with UDP for voice and video communications, and uses ICE (STNU,TURN,UPnP) to be able to solve the NAT/firewall problem. It uses UDP hole punching technique to setup p2p connections from NAT envrionments. It does not use SIP for signalling, but uses RTP for media streams. Onion routing is used to exchange messages for initial connection between 2 clients.

Free software license : GPLv3

Distributed : Yes, working with bootstrap nodes and DHT. Generated temporary public key (256 bit) is used as key_id of peer and stored on DHT nodes. It uses same method as bittorrent or ring to find closest nodes to final node. Sender then uses onion routing to send real public key to recipient's node. Recipients follows same concept to complete handshake with the sender. EC25519 is used for key exchange.
Note :Tox is not 100% distributed. It has to handle mobile devices issues (resources, energy), and provides TCP relay by default, but you can force UDP and it will work as a real p2p clients. Bootstrap nodes are not from a huge list and mainly maintained/provided by tox foundation members. Tox clients can declare themselves as TCP relays in the network.
Depending on the tox client implementation, some offer the option to define the list of bootstrap nodes (like toxic), some others don't (qtox).
It can be of a concern to use hardcoded bootstrap nodes. You should be free to select nodes from the official list of registered nodes. Any client can also run a node for bootstrap. (from wiki from blog)

End-to-end encrypted by default : Yes, xsalsa20 for encryption, poly1305 for authentication.

Minimize metadata exposure : temporary keypair generated that gets stored in DHT are not directly related to long-term master keypair. Each DHT node has its own symmetric key. Master public key is then never directly exposed on DHT nodes, they are safely transmitted to contacts inside onion routing messages. Client's ip address is stored encrypted in DHT. It is readable only when request is made with correct tox ID. A nospam number is also added in the tox id, it is meant to be changeable to prevent easy tox id guessing and friend request spamming.

Signup : no phone number or email required.

Clients platform : Available for iOS, Android, Sailfish, GNU/Linux, MS Windows, MacOSX, FreeBSD

Tor friendly : Yes. (tcp only then : toxic --force-tcp --SOCKS5-proxy 9050, see proxy options in GUI clients. Android client can use Orbot to force routing of app.

File transfer : Yes.

Voice calls : Yes but features availability depends on client developement progress. Antox (Android client) has voice and video calls.

Video calls : Yes. Same as for voice calls. It depends on client implementation progress.

Multidevice support : Under development, not yet available. Parts of the code is already in toxcore and some early testing can be done with uTox client.

Should not rely at all on Google resources : No use of Google API.

IPV6 support : Yes.

Offline messages : Under development. However current design roadmap will rely on supernodes to store and route messages. This is effcient for convenience but bad for security : it is a place for metadata collecting. We want to avoid that as much as possible. Message contents are as safe as online messages. However as long as you use UDP mode, p2p friendly, your metadata attack surface is limited. But if your goal is anonymity refer to projects below (ricochet, briar), and you can use Tox over Tor as well.
Tox wiki mentions several proposals for offline messaging. none of them is yet written in stone.

API for interoperability : There is an API that allows for developing custom clients. These could be also used for modules to interact with other messaging clients.
Antox client currently does not yet fully implement groups but this is subject to change as it is evolving.

CAVEAT : toxcore consumes some network resource. This can cause data volume quota issues over mobile networks 3G/4G, over time as it may need to handle udp nat keepalives, dht peers swarming. It can drain battery of the mobile phone, even though there is no communication.

Jami faces same kind of issues on mobile phones. I had problems using it reliably inside NAT networks and consumes quite a lot of resources.

P2P apps on mobile phones is somehow a paradox that needs to be adequately addressed : from the mobile device perspective, application should minimize its energy consumption to ensure battery duration. From the p2p perspective, it should participate into the overall network of nodes.
A correct balanced solution must then defined, a solution that correctly takes care for battery energy, p2p connections.

Distributed network : Designing a fully distributed network is hard. One of the biggest problems comes from the constraint of using UDP from clients inside NAT'ed networks. Techniques for UDP hole punching require the support of decentralized servers (STUN, TURN).
This help for later p2p connection establishment (STUN), but then rely on third party server that manages (ip address, port) tuples between the clients to establish a p2p connection. The STUN host becomes a SPOF (Single Point Of Failure).
In the TURN case, things get worse : it helps for some NAT network layouts, however TURN hosts do proxy the communication.
These 2 methods, that will be needed in several NAT networks (work offices, hotels, airports), solve the connection issue that is vital to have the communication working, however they are a tradeoff with fully distributed layout, because they bring critical unique hosts in the path that, in case of failure, would bring down the communication between two peers.
In addition to that, this also increases the metadata exposure through possibly malicious relay/proxy. However it does not compromise the authentication between peers, and does not impact confidentiality for the data.
This brings interesting challenges:
- How far can we avoid to have to rely on STUN or TURN servers inside NAT networks where such techniques are currently required to establish a peer to peer connection between clients?
- How can we reduce metadata exposure as much as possible in a distributed network?

Both Jami and Tox face the same kind of problems here.

Zooko's triangle describes well that we cannot achieve decentralized+secure+human-meaningfull at the same time, in the same proportions. In P2P networks, we always have a bootstrap problem that must rely on some form of federated system. So don't be surprised if these communication projects also rely for some parts such as bootstraping on a couple of well defined servers.

These two project are still under active developement. They are not meant to be fully production stable and mature. Some clients are still unstable, some are missing important features. There has not been a wide public security audit for any of these AFAIK. Both follow p2p/distributed concept and this is more than welcome. Jami sticks to SIP and mostly UDP. Tox uses TCP, UDP for media streams with RTP.

I wish that efforts are focused on these kind of projects that really benefit from the Internet design and concepts. Signal and Telegram were a big step towards secure communication on the Internet. But I am convinced that the next step is to make communication systems such as Jami or Tox popular and promote them for the average user. Much efforts are being brought for these projects to provide a client as simple as possible and with high security features by default, without having the user to really put his hands in it, such as the GPG case.

Special mention : Tor app Briar
The elegant feature with tor onion services is that it does not require an open ingress port. So we don't care about NAT traversal issues, each app will connect to a tor circuit.

As they use Tor, they are tied to TCP connections. So this makes voice or video calls using classic UDP protocols such as RTP quite hard to use. This is a current limitation of the Tor model.

Privacy and Anonymity :
To achieve a certain level of privacy, metadata must be protected. This is not a feature we usually meet with usual apps.
Developing a messaging application/protocol that will provide a serious privacy feature requires some form of anonymity protection also.
However, any single messaging application will have the issue of being quite easy to detect and target for traffic analysis and correlation.
To become harder to be identified, the more we are within a crowd of people doing many different things, the better.
In that direction, it would be then better to use an overlay network that already focus on privacy and anonymity, so that metdata is protected and some good level of protection against traffic analysis.
Tor and I2P networks do provide such goals and are quite popular (Tor being the first).
So why not focus on messaging software that can adequately hook with these networks and benefit from the security layer they provide.

Last updated : 20191114