First, many thanks to Planet Debian readers for your thoughtful and constructive feedback to my Signal and Mobile Instant Messaging blogs. I learned a lot.

Particularly useful was the comment directing me to Daniel Gultsch's The State of Mobile in 2016 post.

I had previously listed the outstanding technical challenges as:

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

I am now fairly convined that both problems are well-solved on Android via the Conversations app and a well-tuned XMPP server (I had no idea how easy it was to install your own Prosody modulues -- the client state indicator module is only 22 lines of lua code!)

I think the current technical challenges could be better summarized as: adding iOS (iPhone) support. Both end-to-end encryption and receiving messages consistently seem to be hurdles. However, it seems that Chris Ballinger and the Chat Secure team are well on their way toward solving the push issue and facing funder skittishness on the encryption front. Nonetheless, but seem to be progressing.

With the obvious technical hurdles in progress, we have the luxury of talking about the less obvious ones - particularly the ones requiring trade-offs.

In particular: Signal replaces your SMS client. It looks and feels like an SMS client and automatically sends un-encrypted messages to everyone your address book that is not on signal and sends encrypted messages to those that are on signal.

The significance of this feature is hard to over-state. It differentiates tools by and for technically minded people and those designed for a mass audience.

When I convince people to use Conversations, in contrast, I have to teach them to:

  • Create an entirely new address book by entering addresses for your friends that you don't already have
  • Use a new and different app for sending encrypted messages

For most people who don't (yet) have their friends XMPP addresses or for people who don't have any friends who use XMPP, it means that they will install it, send me a few messages and then never use it again.

The price Signal pays for this convenience is steep: Signal seems to synchronize your entire address book to their servers so they can keep a map of cell phone numbers to signal users. It's not only creepy (I get a text message everytime someone in my address book joins Signal) but it's flies in the face of expectations for a privacy-minded application.

How could we take advantage of this feature, without the privacy problems?

What if...

  • Our app could send both XMPP messages and SMS messages
  • Everytime you added a new XMPP contact, it added the contact to your address book with a new XMPP field
  • Anytime you send a message to a contact with an XMPP field filled in, it would send via XMPP and otherwise it would send a normal SMS message

The main downside (which Signal faces as well) is that you have to contend with the complexities of sending SMS messages on top of the work needed to write a well-functioning XMPP client. As I mentioned in my Signal blog, there are no shortage of MMS bugs against Signal. Nobody wants that head-ache.

Additinally, we would still lose one Signal feature: with Signal, when a user joins, everyone automatically sends them encrypted messages. With this proposed app, each user would have to manually add the XMPP address and have no way of knowing when one of their friends gets an XMPP address.

Any other ideas?

The on-boarding will always be easier in a centralized system. No questions about it.

It is fair to assume that it will always be undesirable to XMPP users to upload their cell phone number to a central server for instance. If that's fine with someone they can just use Signal. However there are ideas floating around to make the on-boarding easier. If you want some reading material there are discussions here and here. (Please keep in mind that this is all work in progress.) None of the ideas are final. The end goal is something like this: You send some a link like and the rest happens automatically. The invitee clicks the link, is being told to install an XMPP client, clicks the link again that automatically opens the XMPP client and creates a contact for them.

This is already working right now. In a second iteration we will try to modify the process so that giving someone this link will automatically let them subscribe to your presence. (See if you are online, see your avatar and so on.)

Comment by Anonymous Sun 05 Jun 2016 05:48:45 AM EDT


Has only an OTR plugin that says "Do not rely on it". But there exists an omemo plugin!

Telepathy & Empathy

No Support.


Development seems to have generally stalled some years ago. (However, there is a v3 branch.)


Comment by Anonymous Sun 05 Jun 2016 07:49:55 AM EDT
"Signal seems to synchronize your entire address book to their servers" - no they don't. They send hashes of phone numbers.
Comment by Anonymous Sun 05 Jun 2016 11:11:36 AM EDT
As one small step, get people used to the idea that their XMPP address should be their email address. When you see an email address, see if it works for XMPP, and if it does, automatically treat it as an XMPP address too.
Comment by Anonymous Sun 05 Jun 2016 08:45:27 PM EDT

I am pretty sure the Signal servers only see hashes, not phone numbers btw..

Anyway, one idea I've had in the past was to create a DNS hierarchy similar to e14, against which you could run SRV queries. For instance, the phone number +49.1234567 would have and you could query that RR to get e.g. This would essentially allow everyone to publish alternative contact channels for their number(s), but obviously would also lead to the ability to link names to numbers.

You could introduce hashes here, i.e. query the SRV record of the $(hashsum +49.1234567).hashes.something. RR and get back the XMPP address. That way, you can map numbers to alternatives without letting people find out the phone number(s) connected to e.g. an XMPP address.

Long-term, however, I'd hope SMS dies (or grows a negotation channel), such that in the future, clients can connect to each other (directly or via servers) and negotiate the protocol they want to use.


Comment by Anonymous Mon 06 Jun 2016 03:42:23 AM EDT
True, Signal only transmits hashes. But then, the space of phone numbers is so small that reversing these hashes is pretty easy. So this protection only helps until someone with access to the Signal database actually has any interest in figuring out the phone numbers. (Which probably will never happen, since everyone of us has a friend who uses WhatsApp, and so we're all in that database already...)
Comment by Anonymous Mon 13 Jun 2016 07:43:02 AM EDT