Secure Messaging for Paranoid Realists: Volume 2

I've disabled "conduit.rs", the Matrix service I had running on my VPS.

There are several reasons for this, the first being that I don't want to deal with the bugs and resulting mishaps of an implementation in beta (not right now, at least).

Though I've read that this has been fixed recently, as soon as I spun up my Conduit server, I couldn't communicate with most of the rooms created on existing Synapse servers due to later versions of rooms not being supported yet.

The second reason is that I've been evaluating some other options, mainly Session. Though it's not perfect, there are some things I like about it that are impactful enough for me to put the Matrix ecosystem on pause for now. To be clear, I still love what Matrix is doing, but running my own instance is just a little more than I want to deal with at the moment, and federation is the only way to truly realize the full range of benefits offered by the protocol.

Session Messenger Breakdown: Pros and Cons

[ Pros ]

• Uses Tor by default
• Decentralized by default via volunteer-run nodes
• APK is available via F-Droid
• Doesn't require any personal information on account creation

[ Cons ]

• Uses Google for notification services*
• Desktop client is Electron-based

*There is an option to not use Google's notification servers, but it's a lot slower and you can't set the check interval. From their FAQ:

> If you choose slow mode, the Session application runs in the background > and periodically polls its swarm (see What is a swarm) for new messages. > If a new message is found, it is presented to you as a local notification > on your device. > > If you choose fast mode, Session will use Google’s FCM push notification > service to deliver push notifications to your device. This requires that > your device IP address and unique push notification token are exposed to a > Google operated push notification server. Additionally, you will expose > your Session ID and unique push notification token to an OPTF operated push > notification server, for the purpose of providing the actual notifications > to the Google FCM server.

Session vs Signal, and Why I Will Use Both

I see Signal and Session as complimentary layers. Session is arguably more privacy-friendly than Signal for a few big reasons:

- Signal servers are centralizedconduit - Signal APK is not available on F-Droid - Phone number required for account creation

Despite this, Signal has an advantage where Session does not: the ability to replace SMS apps. Signal has basically become a catch-all for anyone who might be using it with their phone number. This only applies to around 3% of my contacts, but that's better than 0%.

For anyone else who I communicate with on a regular basis, most of them care about communications privacy and security enough to use a separate app to achieve it.

The Ideal Future Setup

More recently, Rocket.chat announced it's building federation capability via the Matrix protocol, which is a refreshing move. Matrix has only ever wanted to be a protocol in the same way that XMPP is a protocol, leaving the frontend messenger client responsibility to others if you don't want to use the one they provide.

A single protocol that can be audited by the community is the best case we can hope for outside of complete decentralization. There's a reason why e-mail with PGP is still considered one of the best ways to communicate securely and privately: you at least control the keys.

If the answer to the problem of walled messenger gardens is Matrix, it's Matrix. I would love to see more of these platforms begin to adopt interoperability so that people can finally stop juggling digital communication channels based on contexts and pros/cons lists.