Decentralized Apps

Apps are listed in order of "Highly Recommended" first, then "Worth a Try", then "Not Recommended" last. Apps within the same recommendation level are ordered alphabetically.

Conversations (XMPP)

Settings->Expert Settings->Blind Trust Before Verification: Disable

Manage Accounts->Click on account->Top right corner hamburger->Archiving preferences: either "Contacts" or "Never"

Here is a list of what information is stored on the conversations.im server. Each XMPP server however has different policies on what information they store, so this is only an example. https://account.conversations.im/privacy

What we store

Account data

Your user name and hash of your password

Your email address if you provide one. This will only be used to provide you with a way to recover your password.

The date of your account creation and the end of your next payment interval.

Messages

Offline messages. If someone sends you a message while you are offline that message will be stored until you get back online.

Archive. By default we will be keeping an archive of your messages for later retrieval by yourself. This can come in handy if you log in with a new device and want access to your message history and is also required if you want to use the OMEMO encryption with multiple devices. You can opt-out of this by setting your server-side archiving preferences with your XMPP client.

Files. Every file you share with a contact or a conference will be uploaded and stored for later retrieval by the recipients.

Other data

A list of your contacts (Roster, Buddylist). This list is maintained by you. You decide who goes on that list and who gets deleted.

Semi public data you are publishing for your contacts to see like your avatar or the OMEMO public keys.

Other private data your XMPP client might upload like a list of conference bookmarks.

What we don’t store

Your IP address or any information that could be inferred by that address like your location.

The time when you login. - Or more general the times when you use our services.

A correlation between your account and your payment information for longer than it is necessary to fulfil our return policy.

Regarding the above information, even with OMEMO enabled the following is unencrypted on the server:

Archiving of messages on the server is a concern. Even if the messages are OMEMO encrypted it is only the message contents that are encrypted. Other meta data with the message is not encrypted. Some goes for the files which are uploaded encrypted.
All your contacts are stored unencrypted.
Avatar
Bookmarks

When XMPP was first developed there was no encryption implemented in the design. OMEMO adds encryption to the message contents, but the underlying system of XMPP remains unencrypted. It is just the nature of this system that confidentiality is only available for message contents. In many ways it is very similar to PGP which only added encryption to the message contents of emails.

The verifying of a contact's OMEMO keys is done through the exchange of QR codes that are scanned. Once verified any messages from the contact will show a shield icon. If a contact has multiple devices then a key for each device will need to be individually verified. Also if you have more than one device verifying a key on one device does not make that key verified on other devices. You will need to scan the QR code for each of your contact's devices on all of your devices.

Another aspect of security is that photos are automatically saved to your phone's photo gallery where they are saved unencrypted. And if you have any backup or cloud syncing setup for your photos then these photos from Conversations wil also show up in your online storage. You can turn off Storage access for the app, thus preventing any photos or files from being able to be saved to the device, but that also prevents them from being downloaded and viewed in the app as well, essentially making Conversations a text only messenger. Photos are saved in Local Storage/Device Storage/Conversations/Media.

The application does have Google analytics trackers listed in its manifest file however these look to be disabled since May 2018. This is just something to be aware of that a change in the default settings could turn these back on. See Conversations/src/playstore/AndroidManifest.xml.

My Verdict: The best XMPP app, but security is a fundamental afterthought in the XMPP system.

XMPP was not designed with security at it's core. Therefore be careful of data leakage. I would only recommend this app to people who have a full understanding of the limitations of XMPP. It is not foolproof at all and is very easy to leak information by mistake.

Snikket (XMPP)

Platforms: Android, iOS
Communication types: Text, group chat, video, files, images
Country of origin:
Source code: open
Encryption protocol: Signal
Shared Secret exchange: ECDH25519
Message Encryption Cipher: AES-128
Business model: Donations, planned paid Snikket server hosting
Android app requires Google Play Services: No
Requires a phone number: No
Requires an email address: No
Your ID contains personal information: No
Data is locally encrypted: Yes
Encrypted by default: No (Unless OMEMO Encyption is set to Always)
Perfect forward secrecy: Yes
Messages stored on server: Yes
Ephemeral messages: No
Puddle test: Data recoverable Messages are saved on the server
Hammer test: Data recoverable You can leave a conversation but this does not delete it. Android client also leaks files.
Has contact verification: Yes
Leaks files: Android
Android app trackers (0): None
Websites: Getting Started
Version tested: Android: 2.10.2, Server: test 35-fbc5a
Last tested: 11/26/2021
Notes:

Snikket is a little different than most apps listed on this website in that it is actually a suite of different applications. Currently the suite consists of an XMPP server based on Prosody, an Android client based on Conversations and an iOS client based on Siskin. So there are really 2 clients and one server, however I am grouping them together because the intent of the Snikket project is to create a more unified XMPP chat experience. Currently most XMPP clients are only available on one or two platforms, between Android, iOS, Windows, Mac and Linux. So using XMPP on different platforms is often a very different experience with the client user interfaces and features available. Snikket is trying to fix this by providing more consistant experience across all platforms and feature sets available by default. There are plans to add desktop and web based clients as well.

The Snikket server is designed to be very easy to setup and provides a large set of features enabled by default. The server design makes it easier for anyone with basic Linux skills to setup their own server so that they can have control over all their XMPP data. Using any of the Snikket clients with a Snikket server will ensure that features work out of the box without special configurations.

I am very pleased with the way Snikket is approaching the XMPP problem of inconsitancy of experience across platforms. I have setup my own Snikket server and it took only 30 minutes on an existing VPS server I had running. That time included installing the docker and docker-compose packages, configuring new DNS rules for the server domain, downloading the Snikket server files and starting the 4 docker images, and configuring the firewall rules on the server. It was another 5 minutes to create my first invitation on the server and signup from an Android device using that invitation to signup for a new XMPP account. This process eliminates many barriers for both self-hosting your own XMPP server and makes the signup process for a new user account much easier.

Here is some good reading on the issues with OMEMO encryption and contact trust and verification. These are not easy concepts for the normal person to grasp: Blind Trust Before Verification. OMEMO encryption only works in private (members only) conferences and individual chats, so it will not work in open group chats.

Here are some settings to make Conversations more secure:

Settings->OMEMO Encryption: Set to "Always"

Settings->Expert Settings->Blind Trust Before Verification: Disable

Manage Accounts->Click on account->Top right corner hamburger->Archiving preferences: either "Contacts" or "Never"

XMPP by design does save some information in unencrypted format so it is important that you trust the administrator of your server. By self hosting you are in control of all the information on your own server, however if you communicate with XMPP users on others servers there still is some unencrypted information that those users will have saved on their server. This data may include:

Archiving of messages on the server is a concern. Even if the messages are OMEMO encrypted it is only the message contents that are encrypted. Other meta data with the message is not encrypted. Some goes for the files which are uploaded encrypted.
All your contacts are stored unencrypted.
Avatar
Bookmarks

BabelNet

Platforms: Android, iOS, MacOS, Windows
Communication types: Text, photos, files, voice messages
Country of origin: Czech Republic
Source code: closed
Encryption protocol: Babelnet
Shared Secret exchange: DH MODP2048
Message Encryption Cipher: AES-128
Business model: Enterprise version of the platform
Android app requires Google Play Services: Yes
Requires a phone number: No
Requires an email address: No
Your ID contains personal information: No
Data is locally encrypted: Yes
Encrypted by default: Yes
Perfect forward secrecy: Yes
Messages stored on server: Temporarily
Ephemeral messages: Yes
Puddle test: Data not recoverable Messages not saved on the server.
Hammer test: Data not recoverable When messages are deleted on all devices. You can remotely delete messages from devices.
Has contact verification: Yes
Leaks files: No
Android app trackers (1): Google Firebase Analytics
Websites: White paper
Version tested: 7.6.1 (Android), 3.7.0 (MacOS)
Last tested: 8/12/2018
Notes:

This messenger provides syncing of messages across multiple platforms, messages are not saved on the server so you do not get past messages when you connect a new device. The user interface is very consistant between platforms.
A nice feature is that when you are sending messages from different devices, messages you send from other devices will have a note next to the time indicating which device it was sent from.

Sent and read receipts appear on each message. Pictures have a fuzzy preview until they fully download from the server. Pictures are not automatically saved to your device but you can export them from the application to your device manually. I really like this and think more applications should follow this model. There is also a section of the app to view all attachments.

I did have problems getting the app to connect to the server when trying to setup on new LineageOS devices. The app connects fine on standard Android but it may have problems with unofficial Google implementations.

A bit of confusion in the interface is when creating new chats, there is an option for "New chat", which is for communicating with one person, then there is "New conversation" which is for communicating with a group.

The contact verification codes are a series of 15 random words. This may be easier when comparing keys than what many apps use (long strings of characters). However there does not seem to be a way in the app to mark that you have successfully verified a contact, so if you have lots of contacts you may forget which ones you have verified already.

Another point of confusion is what the setting "Message expiration" actually does. This means that if messages are not delivered within that time frame they are deleted from the server and never delivered. There is another option called "Automatic deletion" in the chat session which will delete the message after the set time once the message is read. These features aren't explained very clearly on the website. The Mac application does not seem to have the "Message expiration" setting anywhere that I can find.

Push notifications for new messages were always received on multiple devices.

From the white paper section 3.1:

3.1 BASIS FOR THE CRYPTOGRAPHY DESIGN
During the cryptography design, we worked with the
following requirements:
• The major goal was to secure the content of the
communication, not the fact that the communication
actually took place.
• Application encryption will be used in between the
end-points during the data transfer.
• Application encryption will be used for data storage
on devices.
• User public key certificates or device certificates will
not be used.
• The server will be used for:
- user account administration
- distribution and synchronization of public keys
- asynchronous communication among devices with
Babelnet application
• Server does not poses any keys that can be used to
decrypt messages.
• Server can only access information about users,
devices and message metadata
• Transported messages will not be stored on Babelnet
servers for a longer period of time than it is necessary
for successful message delivery
• Servers are under the organisations’ own
administrations
• Users can have more than one device (e.g. smartphone,
tablet, PC, laptop…) – messages will always be sent
from one device but synchronized to other devices
under the account
• Standard strong cryptography algorithms and
recommended parameters and operation modes will
be used
• Techniques for elimination of active attacks will be used
– checks of integrity, authenticity and message sequence
– strictly before any attempt to decrypt messages

Encryption protocol (Whitepaper section 3.5):
Diffie-Hellman key exchange using 2048 bit MODP
The shared secret is derived from the negotiated keys
A 128 bit random message key is generated
AES-128 encryption using the message key encrypts the message
A 128 bit "Contact Key" is generated from a hash of the shared secret and other info
The message key is encrypted by the contact key using AES-128
A message authentication code is generated using SHA-256

My verdict: I am liking it, some UI or FAQ clarifications are still needed!

I was pleasantly surprised at the number of security features available in this application. Not only does it have a timeout for the message to be deleted once it is delivered and read, there is also a separate setting for a timeout if the message is not delivered and still resides on the server (very nice)!
The synchronization of messages between multiple devices works flawlessly. You do not get history of existing chats when adding a new device but that is expected (and good security).
I was a bit confused about the difference between creating a new chat or conversation (one is an individual chat and one is a group chat). The group chat has a subject, while the individual chat does not. At one point my chat partner and I had two separate chat entries between us, and we didn't understand why until we realized one of them was a chat and one a group conversation with us as the only participants.
Adding some status indicator when you successfully verify a contact's key would be nice to have.
I did have a problem adding a third device, it received messages for a while but then would no longer connect to the server while my other devices still were connected to the server.
Syncing across multiple platforms and being based outside the 14 eyes makes this a great option.

Blabber.im

Platforms: Android
Communication types: Text, group chat, video, files, images
Country of origin: Germany
Source code: open
Encryption protocol: Signal
Shared Secret exchange: ECDH25519
Message Encryption Cipher: AES-128
Business model: blabber.im is 100% self-contained, independent and a self-financed German community based in NRW. The servers are located in Germany.
Android app requires Google Play Services: Yes
Requires a phone number: No
Requires an email address: No
Your ID contains personal information: No
Data is locally encrypted: Yes
Encrypted by default: No (Unless OMEMO Encyption is set to Always)
Perfect forward secrecy: Yes
Messages stored on server: Yes
Ephemeral messages: No
Puddle test: Data recoverable Messages are saved on the server
Hammer test: Data recoverable You can leave a conversation but this does not delete it. Android client also leaks files.
Has contact verification: Yes
Leaks files: Android
Android app trackers (0): None
Websites: Privacy Policy, source code, Migrate from Pix-Art
Version tested: 3.0.4
Last tested: 4/4/2021
Notes:

Blabber.im is a fork of Conversations (XMPP) with some slight modifications.

When creating a new chat it is nice to see a notice describing how to enable encryption. Settings are also laid out in a more organized manner than Conversations. The settings are basically the same just easier to navigate. In a chat session there are status check marks which make it easy to see when a message has been delivered (green check mark) and when it has also been read (green and blue check marks).

The app requires a TLS connections to any XMPP server which is a nice security feature.

Unfortunately Blabber.im has the same issues with saving images and files into public storage unencrypted that Conversations has. Images from chats are automatically saved into "/blabber.im/Media/blabber.im Images"

One area of concern is the process by which you can recover a lost password on an account on their server. Because you do not specify an email address upon signup they do not have one on file, so this is their process:

Send me an e-mail stating your JID.

I will reset your old password and send you a new password via eMail

They basically need to trust that you truly own that XMPP ID and email. I see the possibility of someone who knows someone else's XMPP ID will email them and having a new password sent to their own email address, thus hijacking another person's blabber.im account.

My verdict: Tweaks make it easier to use than Conversations

Just a few things here and there are enough to make this a more pleasant experience, however there are still some fundamental issues with the XMPP protocol that create security issues.

Quicksy (XMPP)

Platforms: Android
Communication types: Text, group chat, video, files, images
Country of origin: Germany
Source code: open
Encryption protocol: Signal
Shared Secret exchange: ECDH25519
Message Encryption Cipher: AES-128
Business model: Funded through the the quicksy.im directory service
Android app requires Google Play Services: No
Requires a phone number: Yes
Requires an email address: No
Your ID contains personal information: Phone
Data is locally encrypted: Yes
Encrypted by default: No (Unless OMEMO Encyption is set to Always)
Perfect forward secrecy: Yes
Messages stored on server: Yes
Ephemeral messages: No
Puddle test: Data recoverable Messages are saved on the server
Hammer test: Data recoverable You can leave a conversation but this does not delete it. Android client also leaks files.
Has contact verification: Yes
Leaks files: Android
Android app trackers (0): None
Websites:
Version tested: 2.3.6+pcr
Last tested: 11/23/2018
Notes:

Quicksy is based on the same code as the Conversations (XMPP) app, so all notes on Conversations also applies to this app. Additionally there are a few other unique features:

Quicksy.im also offers a Quicksy Directory service which allows other non Quicksy users to add their own XMPP ID and their phone number so that Quicksy users can look them up using a phone number. This service requires a one time fee to register, which helps provide the Quicksy app for free.

Note that a phone number is required to sign up for an account in Quicksy (which automatically uses the quicksy.im server) and the phone number will be your ID for the service. So this does make it easier to signup in the app instead of having to go search for an XMPP server to use. It also makes it easier to find other Quicksy users (or other XMPP users who registered in the directory) by looking up their phone number. However that does mean that you are exposing your phone number so you lose some anonymity. Also the app will at regular intervals upload the phone numbers from your address book to search for matches with other registered Quicksy users or directory entries.

This app does not allow you to add other XMPP accounts that you may own, it can only be used by one quicksy.im account. However you can add contacts that use any other XMPP server as well as Quicksy.im users.

My verdict: Worth a try for beginners

This app is a way for those new to encrypted messaging to get started without much hassle. Using this app gives them access to contact anyone in the entire XMPP federated system. The compromise for ease of use however is the exposure of a phone number as part of the XMPP ID. Just about all other features of the app are exactly the same as Conversations which would make it easier to transition to a non-phone number XMPP ID in the future.

Comparisons to the Signal app are apt since the target audience is very similar, mainly those who may be just getting into secure messaging but are used to the concept of using a phone number as an identifier. Both apps are simple to use and signup for an account. There are some differences however:

Signal:

Advantages:

Also acts as the standard SMS app and encrypts messages at rest
Most metadata is now encrypted
Messages are stored on mobile devices, not a server
Encryption to other Signal users is automatic, less likely to send a message unencrypted by mistake

Disadvantages:

Can only connect to Signal users

Quicksy:

Advantages:

Access to the entire XMPP system and users

Disadvantages:

You still need a separate SMS app
Messages are stored on XMPP servers
Metadata and contacts may be stored unencrypted on servers
Concepts of encryption and using OMEMO correctly still requires some attention, it is possible to send unencrypted messages if someone is not careful

Session Messenger

Platforms: Android, iOS, MacOS, Windows, Linux
Communication types: Text, group chat, photos, files
Country of origin: Australia
Source code: open
Encryption protocol: Session Protocol (using libsodium)
Shared Secret exchange: ECDH25519
Message Encryption Cipher: XSalsa20
Business model: Loki Services
Android app requires Google Play Services: No
Requires a phone number: No
Requires an email address: No
Your ID contains personal information: No
Data is locally encrypted: Yes
Encrypted by default: Yes
Perfect forward secrecy: No
Messages stored on server: Temporarily
Ephemeral messages: Yes
Puddle test: Data not recoverable Messages saved only on device
Hammer test: Data not recoverable When messages are deleted on both sending and receiving devices
Has contact verification: Yes
Leaks files: No
Android app trackers (0): None
Websites: FAQ, Whitepaper, Source
Version tested: Android: 1.11.6, MacOS: v1.4.0, iOS: 1.2.0, Linux v1.7.0
Last tested: 9/12/2021
Notes:

Session audits: Session clients code audit and blog announcement.

Session (previously called Loki) is still in beta but so far I am very impressed with the functionality and features of this app. It runs on top of a distributed network of servers that run the Loki Network.

I like very much that the encryption uses the Signal protocol, which is very good. The Signal app is designed to use a centralized server infrastructure, however this messenger uses the Signal protocol on top of the decentralized Loki network. This decentralization greatly improve the anonymity and robustness of the system.

Features I like:

Disappearing message can be set from 5 seconds to 1 week
You can manually reset the session keys
Read link previews, read receipts and typing indicators can be turned on or off
The use of FCM (Google Firebase) for notifications can be turned on or off

It should be noted that currently in 2021 file attachments for messages are not stored on Session service nodes but are stored encrypted on a central server. The encryption key for the file is sent directly from the sender to recipient along with a link to download the file from the server. Therefore the file attachment is still end to end encrypted, it is just temporarily stored on a central server. More information can be found at https://docs.oxen.io/products-built-on-oxen/session/attachments.

The feature set of the mobile apps is slightly behind the desktop apps.

My verdict: I am loving it!

I will wait a while and see how this app develops, but I am already loving this. It has all the privacy features needed and runs on top of a decentralized network. The speed is very fast, and the desktop client (Linux) is very feature complete. This is very early in the development still, but it has great promise. This is one app to keep around to test and see how it develops.

Adamant

Platforms: iOS, Web
Communication types: Text, cryptocurrency
Country of origin: Republic of Ireland
Source code: open
Encryption protocol: NaCl
Shared Secret exchange: ECDH25519
Message Encryption Cipher: Salsa20
Business model: Per message cryptocurrency fee
Android app requires Google Play Services: N/A
Requires a phone number: No
Requires an email address: No
Your ID contains personal information: No
Data is locally encrypted: Yes
Encrypted by default: Yes
Perfect forward secrecy: No
Messages stored on server: Yes
Ephemeral messages: No
Puddle test: Data recoverable All messages stored on public blockchain
Hammer test: Data recoverable All messages stored on public blockchain
Has contact verification: No
Leaks files: ?
Android app trackers (N/A): N/A
Websites: Roadmap
Version tested:
Last tested: 2/26/2019
Notes:

Adamant is a messaging app that is based on blockchain technology. Messages are encrypted and stored onto the blockchain which is stored in duplicate on many computers connected to the internet. The advantage of this is that your messages are accessible to you anywhere from any device. You can also leave a message for someone else on the blockchain and they can be offline and retrieve it later. One big disadvantage of this system is that your messages (while encrypted) are stored in permanance. So while the encryption methods used now are secure they may not be in the future and all your messages may be decripherable.

This application is also very immature in that is has few features outside of texting and cryptocurrency exchange. At this time it is not mature enough to use as a primary messaging system.

My verdict: Limited use, future security concerns

Lack of basic features like sending photos and group chat make this a very limited use app, and having messages live permanantly on a blockchain is not a good security habit.

Conion (XMPP)

Platforms: Android
Communication types: Text, group chat, video, files, images
Country of origin:
Source code: open
Encryption protocol: Signal
Shared Secret exchange: ECDH25519
Message Encryption Cipher: AES-128
Business model:
Android app requires Google Play Services: No
Requires a phone number: No
Requires an email address: No
Your ID contains personal information: No
Data is locally encrypted: Yes
Encrypted by default: No (Unless OMEMO Encyption is set to Always)
Perfect forward secrecy: Yes
Messages stored on server: Yes
Ephemeral messages: No
Puddle test: Data recoverable Messages are saved on the server
Hammer test: Data recoverable You can leave a conversation but this does not delete it. Android client also leaks files.
Has contact verification: Yes
Leaks files: Android
Android app trackers (0): None
Websites:
Version tested:
Last tested: 4/4/2021
Notes:

Bottom line: Just use Conversations.

Looking at the website home page I suspected it was just a XMPP server app. Then looking at the screenshots confirms this is basically a fork of Conversations. So this app is really just:

An XMPP app cloned from Conversations
Fixed to use their conion.im server as your account server
Connecting to the server over Tor

All of the above you can already do with the standard Conversations app on Android. But you can choose your own server. Also I would be concerned that fixes to the Conversations app would take time to make it into this build.

Who is this group, where are they based? I cannot find this info. The website has poor English so they are not native speakers. The privacy page is incomplete: https://conion.im/index.php/privacy-policy/

The blog looks like all the entries came with the default Wordpress install, and they are getting nonsense comment spam.

They have an icon for the iOS App store but no link. So do they plan to build Conversations of iOS as well because that would be quite a feat.

Looking at the Android store entry they do at least give credit to Daniel Gultsch's Conversations there.

My Verdict: Just use Conversation instead
I would say stay away, I don't know who is running this server and if we can trust them. Calling this the "most secure messenger" is a stretch given the amount of meta data the server has access to.

Cwtch

Platforms: Android, Windows, Linux
Communication types: Text, group chat
Country of origin: Canada
Source code: open
Encryption protocol: Tor hidden services/TLS
Shared Secret exchange: ECDH25519
Message Encryption Cipher: AES-128
Business model: Free open source project
Android app requires Google Play Services: No
Requires a phone number: No
Requires an email address: No
Your ID contains personal information: No
Data is locally encrypted: ?
Encrypted by default: Yes
Perfect forward secrecy: ?
Messages stored on server: Never
Ephemeral messages: Yes
Puddle test: Data not recoverable Messages saved only on device.
Hammer test: Data not recoverable Messages saved only on device.
Has contact verification: ?
Leaks files: ? Needs more testing
Android app trackers (?): ?
Websites: Releases
Version tested: Alpha 0.1.1
Last tested: 3/1/2019
Notes:

Cwtch is based on the Ricochet platform and uses Tor onion services.
From https://openprivacy.ca/blog/2019/02/14/cwtch-alpha/:

Cwtch is an experimental concept and prototype. We do not recommend you use Cwtch today if you require secure communication.

This project looks very interesting being built upon Ricochet protocols, I am interesting in seeing how it develops. On stock Android the application would open for a few seconds then crash so I was not able to test it. However I do like the concept of a decentralized network and using Tor. Give this one some time to develop.

My verdict: Still alpha, keep an eye on this one

I like the concepts, it just needs time to develop.

Element (Matrix)

Platforms: Android (on F-Droid), iOS, MacOS, Windows, Linux (Debian, Ubuntu), Web
Communication types: Text, voice, video, file sharing
Country of origin: UK
Source code: open
Encryption protocol: Matrix
Shared Secret exchange: X3DH Curve25519
Message Encryption Cipher: AES-256
Business model: Open source, Matrix.org funded through donations and investors
Android app requires Google Play Services: No
Requires a phone number: No
Requires an email address: Depends on server
Your ID contains personal information: No
Data is locally encrypted: N/A (Android app is a web app)
Encrypted by default: No
Perfect forward secrecy: Yes
Messages stored on server: Yes
Ephemeral messages: No
Puddle test: Data not recoverable Messages are saved on the server, however if the session keys are lost then they cannot be decrypted.
Hammer test: Data not recoverable When you delete all session keys from all your devices and chat partners' devices. Messages may remain in encrypted form on the servers.
Has contact verification: Yes
Leaks files: No
Android app trackers (0): None
Websites: Source code
Version tested: 1.8.2
Last tested: 9/12/2021
Notes:

Update Sept 2021:
Over the last 4 years I have watched Riot/Element/Matrix mature and grow. What I once saw as a promising platform for security and privacy now I see as an ever growing beast with a huge surface area for abuse and misuse. What I mean by that is:

Abuse: The larger your code base, feature set and number of systems that you integrate with, the more likely that there are vulnerabilities that can be exploited to compromise security.
Misuse: Matrix may have end to end encryption in its own rooms, but that is not the case throughout the entire system. The more integrations that are made with other systems which are not encrypted the more likely someone is going to make a mistake and say something they thought would be private but really is not.

Matrix wants to connect with other non secure messaging systems via bridges. Just take a look at all the bridges that are available. As of the time of writing this the bridges are for: IRC, Slack, RSS, SMS, Skype, Email, LinkedIn Messaging, Discord, Facebook Messenger, Mattermost, iMessage, Mumble, WeChat, libpurple, Keybase, Google Hangouts, GroupMe, LINE, RocketChat, Instagram, Telegram, WhatsApp, Twitter, Signal, Tencent QQ, Tox, Mastodon and Gitter.

The Matrix org is also not going to be in control of all the interoperability of these bridges to other unsecure sysstems. Rooms that you join in Matrix could be connected and streaming data to bridges written by pretty much anyone without any standard of ensuring the code is secure. From https://matrix.org/faq/#what-do-you-mean-by-open%3F

Matrix is an open standard, meaning that we have freely published the details for how to communicate interoperably using the Matrix set of HTTP APIs. We encourage anyone and everyone to use the APIs and build their own projects which implement them and so benefit from interoperability with the rest of the Matrix ecosystem. We also ensure the standard is not encumbered by any known patent licensing requirements.

What does Matrix say its mission is?

Matrix’s initial goal is to fix the problem of fragmented IP communications: letting users message and call each other without having to care what app the other user is on - making it as easy as sending an email.

And we know how secure email is, right?

Encryption:

Element uses Olm for one on one chats and Megolm for group chats within Matrix. It implements a double ratchet key algorithm similar to Signal but is a distinct product.

The setup takes four Curve25519 inputs: Identity keys for Alice and Bob, IA and IB, and one-time keys for Alice and Bob, EA and EB.
A shared secret, S, is generated using Triple Diffie-Hellman.
The initial 256 bit root key, R0, and 256 bit chain key, C0, 0, are derived from the shared secret using an HMAC-based Key Derivation Function using SHA-256 as the hash function (HKDF-SHA-256) with default salt and "OLM_ROOT" as the info.

Element/Matrix is a great way to meet new people, and with E2EE for individual and group chats (in Matrix only) it offers a way to go dark for private conversations. Be careful though because any bridge to another system exposes all data to that platform which will have completly different security and privacy features.

While Matrix is designed as a decentralized system where anyone can choose their own server there currently aren't very many choices. Most people choose the default Matrix home server, so there is not a lot of decentralization going on yet. Even if you do choose a different server, conversations are synced to all the servers of all the room participants. So that means that pretty much all rooms will be synced to the Matrix home server since there is most likely to be at least one person in each room from the Matrix server.

Validating other user's devices is still not completely smooth, the new system does not always work. Sometimes it is necessary to go back to the old manual verification method.

My verdict: Maybe a good social platform, but connects with all types of other non-private messaging systems

Most people still use the default matrix.org server, so almost 100% of the messages on this system are being replicated back to this central server.

RetroShare

Platforms: Windows, MacOS, Linux (many), FreeBSD
Communication types: Text, voice, video, email, file sharing
Country of origin: None
Source code: open
Encryption protocol: OpenPGP
Shared Secret exchange: RSA 2048 PKI
Message Encryption Cipher: ?
Business model: Free open source project
Android app requires Google Play Services: N/A
Requires a phone number: No
Requires an email address: No
Your ID contains personal information: No
Data is locally encrypted: Yes
Encrypted by default: Yes
Perfect forward secrecy: Yes
Messages stored on server: Yes
Ephemeral messages: No
Puddle test: Recoverable?
Hammer test: Recoverable?
Has contact verification: No
Leaks files: No
Websites: Source code
Version tested:
Last tested:
Notes:

[Information provided by JR]

What is leaked to the world when using the DHT.
- Your IP address.
- The IP addresses that you are connecting to.
Optionally, Retroshare may be configured to tunnel through I2P or Tor with friend finding turned off to function as a true darknet. This however, is slow, unreliable, high-latency, and very difficult to set up.

- Retroshare may appear to use PGP, but what actually seems to be happening under the hood is that it's using the RSA keys to sign ephemeral keys which are then used to establish connections to your friends via perfect forward secrecy. The PGP parts of it look like they are used only for certifying and authentication, and are not used to encrypt the data.

- Certificate authorities are not used, the networks are fully friend-to-friend. This is markedly different from peer-to-peer because it is expected in a friend-to-friend network, you already know, and already trust the people you will be connecting and routing for. This is a VERY important distinction in the differences between peer-to-peer and friend to friend.

- Key signing or setting up a PGP web of trust model is in some cases mandatory.

- Retroshare is difficult to set up for the average user. Every user on the Retroshare network MUST know how to port forward or the friend lookup will not function.

- Because it is assumed you already trust the people that you will be using retroshare to connect to, Retroshare makes no effort to disguise or hide your IP address from them. In fact, if your IP address changes, they will get a warning message.
- When operating through the regular Internet, it looks like Retroshare uses a Distributed Hash Table for IP address lookups and friend finding. If this is correct this may present a source of metadata leakage. I will need to look into this some more and find out how it works, because I don't want to spread F-U-D.

- Retroshare *can be made to* go over I2P, but doing so is very slow and requires configuration of the I2P Router. You will need to set up your own tunnels. The documentation for this is a little bit sparse and some of it is in Spanish. You may need to do a bit of experimentation before it works. During this time on I2P, friend finding and the DHT can be turned off, and in this case, Retroshare will function as a true Darknet which will allow for TLS-secured traffic to be wrapped up within I2P's native encryption functions. But this is extremely slow and difficult.

- Retroshare is loaded with features and probably hands down has the most features of any instant messaging bundle. It is VERY good at distributing large files among friends who trust each other.

- Retroshare's trust model is transitory. Friends-of-friends have a certain amount of privilege in some areas. For the rest, a lot of it uses the PGP web of trust.

- The code base has not recently been audited (if ever?). This is the same situation with I2P, where the weak link might be the client software and not the protocol.

- If your Retroshare private key is stolen, although technically you have perfect forward secrecy with TLS, the problem with Retroshare tends to be that much of the content on the network is distributed among your friends. It can be difficult to take back down once. So, for instance, let us say that Alice, Bob, Charlie and Daniel start posting on a Retroshare messageboard that is private to them. Sometime later, Mallory steals Alice's plaintext private key. Even if she does not have Alice's computer, she can still impersonate Alice to Bob, Charlie and Daniel, and re-synchronize her 'copy' of the messageboard with theirs and see all of their would-be private communications. If Alice sent movie.mov to Charlie, and Charlie sent it to Bob, even if Charlie moved movie.mov out of his share, Mallory can use Alice's private key to impersonate Alice and re-download movie.mov from Bob instead.

- The more friends you have on your Retroshare network, the more routing your computer must do and the more bandwidth and processing power the program will need to function comfortably.

- There is a commandline version of Retroshare that is intended to be used as a retroshare server. I have never used it, so I cannot comment on it.

Zom (Matrix)

Platforms: Android, iOS
Communication types: Text, group chat, photos, stickers, audio
Country of origin: USA
Source code: open
Encryption protocol: Matrix Olm
Shared Secret exchange: X3DH Curve25519
Message Encryption Cipher: AES-256
Business model: ?
Android app requires Google Play Services: Yes
Requires a phone number: No
Requires an email address: No
Your ID contains personal information: No
Data is locally encrypted: Yes
Encrypted by default: Yes
Perfect forward secrecy: Yes
Messages stored on server: Yes
Ephemeral messages: No
Puddle test: Data recoverable Messages are saved on the server
Hammer test: Data recoverable You can leave a conversation but this does not delete it.
Has contact verification: Yes
Leaks files: No
Android app trackers (0): None
Websites: <a href="https://github.com/zom/zom-android>Source code</a>
Version tested: 3.0.6-RC-4 (Android)
Last tested: 5/8/2022
Notes:

Update on May 8, 2022:
I have learned that Zom is now using the Matrix SDK2 to interact with Matrix accounts, it is no longer using XMPP.

I logged into Zom using an existing matrix account and basic messaging does work. However there does not appear to be any way to join group rooms, or use newer features like spaces. There also doesn't seem to be much development activity, only 1 or two code changes per month.

The website still references XMPP and is very out of date, and no mention about the change to Matrix.

My verdict: Very basic client, use something else

This is dissapointing that the change to Matrix was made but only a very small feature set of Matrix is actually used.