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.

I've been using IRC as one of my primary communication methods from mobile for a while, and the solution to all of these issues in that realm is to just use a bouncer (e.g., ZNC) which can then use APNS or GCM to wake up your device without actually sending any data through APNS or GCM. All you need is a stable place (server, "cloud" VM, RPI in your apartment, whatever) to run the bouncer. So maybe the solution so your issue is to just write a bouncer for XMPP (which wouldn't even need to have any of your keys or be able to see message contents at all, so would be of somewhat more limited security sensitivity) and use that to get "real-time" behavior.
Comment by James Brown Wed 01 Jun 2016 11:30:10 PM EDT

Chris is not implementing Push on ChatSecure for iOS because he is afraid of a potential battery drain but because iOS is killing apps when they are not running in the foreground. Android does not have this problem. XMPP is already a push protocol. It doesn't need an extra layer of push on top. In fact you at some times have to scroll all the way to the bottom of the battery stats to find Conversations in there.

FWIW Conversations has had support for XEP-0357: Push Notifications as a fallback (if the App does get killed because of memory shortage for example) for a few month now. But that's just as a fallback. You really don't need that to minimize battery drain.

There are a couple of public servers that have CSI enable (jabber.at, conversations.im) if you don't manage to install your own server.

Comment by Anonymous Thu 02 Jun 2016 03:04:32 AM EDT

If your colleagues, friends, family use Signal, great. But then there are people who cannot use it. E.g.

  • someone does not own a telephone or SIM or does not want to use their telephone number as id or one shares their landline telephone with the family
  • someone does cannot (or does not want) to use Google services to install or run Android apps
  • someone does not want (or is not allowed to by company policy) to have their communication meta data at one central place, esp. outside their legislation

Signal is nice, but it is not for everyone, at least for various reasons it is not for me.

Comment by Anonymous Thu 02 Jun 2016 08:06:53 AM EDT

Kontalk is free software in both client and server. Server is xmpp. Encrypts using GPG. It uses phone number as id. Allows sending images and audio notes. There are no groups but coming soon (next resease). Problems are: phone number as id? (for some people this is a bug, for others, a feature), no iOS client yet, bus factor.

Comment by Anonymous Thu 02 Jun 2016 01:04:08 PM EDT

How about something SIP-based?

Linphone is multi-platform, including mobile. https://www.linphone.org/

Ring (formerly SFLPhone), although it's in an early stage, aims at desktop and mobile. Additionaly it supports its own decentralized, serverless protocol Ring which uses DHT (like torrent) to find peer. https://ring.cx/en

The only problem is most people (including our friends) are tech-unconscious and use Signal or Whatsapp.

Comment by Anonymous Thu 02 Jun 2016 04:39:25 PM EDT
Regarding your worries about battery consumption and your questions on push you might want to read The State of Mobile XMPP in 2016.
Comment by Anonymous Thu 02 Jun 2016 05:58:01 PM EDT