Mobile Instant Messaging

2016-06-01 3-minute read

Now that I’ve gone down the signal road, when can I get off of it?

The two contenders I’ve found for more politically conscious mobile-friendly instant messaging are Tox and XMPP.

And the problems to solve are:

  • Implement end-to-end encryption
  • Receive messages the moment they are sent without draining the battery

The Tox Project has a great design (peer-to-peer) and handles end-to-end encryption as part of its core design.

However, the Antox mobile client has not only failed to solve the battery drain problem but seems to also have a serious bandwidth issue as well. Also, what is up with this drama?

How about XMPP?

For years, XMPP clients have been using OTR - and many instant messaging applications support it, including ChatSecure. And now, there seems to be quite a bit of excitement around implementing a better protocol called OMEMO. Incidentally, the OMEMO protocol uses the same Double Ratchet (previously referred to as the Axolotl Ratchet) protocol that Signal uses.

While there are some irritating hiccups around using the available GPL library for Double Ratchet on iPhone apps, it seems like these issues are being sorted out and soon we’ll have some kind of standard way for XMPP clients to exchange end-to-end encrypted messages.

Let’s move on to notifications and battery drain.

If you believe the author of the Android Conversations App there doesn’t seem to be a problem. However, client state indication seems to be the only issue related to battery drainage he addresses and I couldn’t figure out how to easily install that extension on our Debian Jessie prosody instance since it isn’t included in the prosody-modules package in Debian and it requires additional modules for it to work.

Chris Ballinger, the author of ChatSecure (iOS and Android XMPP app), is less optimistic about this problem in general. In short, he thinks we need a proper “push” mechanism and has even started to implement one. At the same time, a new (and different) XMPP standard called Push Notifications - XEP-0357 has been released and it is even implemented in Prosody (although not yet available in Debian).

So the future seems bright, right? Well, not exactly. All of this “push” activity seems to solve this problem: A federated/decentralized application cannot properly use Apple’s APNs or Google’s GCM. In the words of Chris Ballinger:

The biggest problem is that there is no easy way to send push messages between my app and your app. For me to send a push to one of your app’s users on iOS, I must first obtain an APNs SSL certificate/key pair from you, and one of your user’s ‘push token’ that uniquely identifies their device to Apple. These push tokens are potentially sensitive information because they allow Apple to locate your device (in order to send it a push).

So, even if we manage to get one of these two standards for push notifications up and running, we have only succeeded in solving Signal’s centralization problem, not the dependence on Google Play Services and Apple Push Network (in fact it’s quite mysterious to me how you could even use the Prosody implementation of Push Notifications with GCM or APN).

So… what we really would need would be to figure out how to implement one of these two push standards and then get it to work with an alternative to GCM and APN (perhaps MQTT)? Which, I think would require changes to the XMPP client.

Geez. I may be on Signal longer than I planned.