Did I get your attention with the title? Good. In this post I will outline something that I have been thinking about for some months:
I believe it is possible to build a system with the simplicity and functionality of WhatsApp or Viber, which provides end-to-end encryption, is built on free software and open protocols, that supports federation and is almost decentralised, and that would allow interested companies to turn a profit without compromising any of these principles.
Introduction
This is the first post of a series that I will be publishing in the next few days. Many parts of these posts will be technical, but I expect that the main concepts can be understood by a wider audience.
What I am proposing seems like a bold statement, I know. Maybe there is some fatal flaw somewhere in my thinking, and that is why I am publishing this: I hope to get constructive feedback, and maybe get enough traction to start implementing it Real Soon Now™.
I have been thinking about this problem since February, when I discussed this extensively with friends at FOSDEM. I have already published a critique of Telegram, which had way more impact than I ever imagined, showing that there is people out there interested in this kind of stuff. The last posts about DNSSEC and DANE were part of my musings about this, too.
There are many components that need to be built for this to happen. But more importantly, this can only be useful if it gains a critical mass. And that's why I think making this a viable business tool is very important. At the same time, that means I need to think extra carefully to make it impossible for any for-profit company to mutate this effort into Just Another Walled Garden.
My goals for this architecture are:
- First and foremost, target the same people that nowadays is using a plethora of walled gardens for their instant communication needs. That is WhatsApp, Viber, Skype, Facebook messenger, etc.
- It must focus on mobile, that is what people care about, without forgetting about other use cases.
- Creating an account and placing the first call/text message should be as easy as it is currently with the competition.
- All communication must be encrypted end-to-end with public-key cryptography; nobody but the user has access to the private keys.
- Most components must be decentralised, and allow for competition.
- There should be as little trust as possible placed on any part of the system.
- Anybody can set up a compatible service provider and offer it to its users, while having full interoperability with other providers.
- Compatible services which are not part of the network must be able to interoperate.
- Contacting a person should happen even if they are not subscribed to the service. The client application must fall-back seamlessly to using interoperability gateways, PSTN termination, or the mobile network.
- Interoperability with the competition is desirable, but possibly is better left to be implemented by the client applications.
Components
I have identified a few components needed for this to work, I will expand on each one later.
- A flagship mobile application for Android and iOS, based on Lumicall or CSIPSimple, but with several important modifications.
- One or many directory and authentication services, based on ENUM and DNSSEC. These are the most critical piece of this idea, and possibly must only be operated by community-governed non-profits.
- One or many service providers, that offer simple account creation, registration, and optionally PSTN termination (which can be the main way of generating profit). An API needs to be defined for operations that are not part of the communications protocol, like account creation, credit purchasing, and balance querying.
- A network governing charter, and a trusted non-profit organisation that oversees that any participating parties are following the charter. This organisation defines which directory services are to be trusted (and possibly operates one of them), and which service providers the client application can use to create accounts.
Key points
Some of the issues that need to be solved are:
- How to handle and distribute public keys securely without the user understanding anything about security.
- How to make registration painless and password-free, while offering an acceptable level of security.
- How to fund development of the client application, and maintenance of the directory services.
- How to get companies interested in this, so them would bring users to the network.
- How to allow the user to migrate from one service provider to another, to improve competition.
- How to prevent any party from subverting the spirit of the network.
- How to make the client application work everywhere and have reasonably quality.
To be continued
I think I have answers to most of these problems. I will elaborate in the next few days, stay tuned! 
Footnotes
The name is something I've chosen a name in less than 2 minutes, while starting this post, so probably is awful.
The distributed part is only half true, as the directory services need to be centralised, but I think it's good enough.
I am aware that Lumicall seems to be trying to build something similar. I only found about that recently, when I was thinking about this design. Sadly, I think it has several shortcomings, but it is definitely one of the building blocks of this project.
Following the WhatsApp acquisition, several competing applications have seen the light:
As a librist I could only use the latter and it seems it would be a good start for what you're trying to do; avoiding the NIH would be nice though!
Cheers, OdyX
Yes, I have looked into Koltalk before, and I just checked again...
There are no technical specs, and form the few bits of information you can get from the website, it seems it is just an XMPP client, with user names based on phone numbers... The server side seems to try to put all users under the same domain, and somehow distribute them among different servers. I really don't see much of interest here, maybe if they documented more clearly the whole idea...
I think WhatsApp's success really came from taking its users' private phonebook data to facilitate finding other users quickly. Everyone I know who uses it, was totally unaware it even did this.
Worst of all, I don't think it could have been done in any way that respects privacy. Any hash function used must be fast (weak) enough for a phone to do it. And unique enough to avoid accidental collisions and give a 1:1 mapping. And therefore easy to bruteforce every possible phone number combination and be able to reverse the hashes back to phone numbers. Using a random salt in the hashes would have made them useless for matching up users with each other.
In addition to creating new protocols and messaging systems, maybe we should use the existing ones together:
Authentication: many users can't be bothered to do keysigning. A multiprotocol client could use existing messaging systems and social networks to authenticate an user across all of them to achieve an acceptable degree of trust.
E.g. Ada's client perform N challenge/reply interactions with Bob using N protocols/accounts (Linkedin msg, email, phone text, Facebook msg, gtalk). If an attacker is impersonating Bob/doing MITM on only N-1 protocols, the client alarms.
Confidentiality: an attacker that is able to intercept N-1 protocols and decipher them (having captured a copy of a private key or due to broken cryptography) might not be able to read messages that are being "spread" across N protocols (e.g. using SSSS)
Availability: N-1 messaging system might be unavailable at the same time (downtime, firewalling, legal restrictions) but the users could still be able to communicate.
Ease of migration: adding new transports and removing old/less trusted ones could be almost transparent to the user.
Of course the value of "N" could change depending on the criticality of the message, e.g. 3 for the first authentication (including slower ones), then 2 for regular messaging.
Even if some systems are still centralized, "striping" transports could be a form of decentralization. A messaging "striping" library could be reused in many clients.
Hi all, thanks for the comments!
@stenvenc: I agree with what you say, although I think there are two alternatives:
@Michael:
I know about TextSecure. I see two problems with it: it does not interoperate, as their signalling protocol is a custom one, so no chance of calling people who use standard SIP or XMPP protocols. And the second one is that they use OTR for authentication and encription, which is a good protocol, but it still depends on the users verifying a secret somehow. Which I think most people would not do properly.
@Federico:
I think that is an interesting point of view, although it seems pretty complex to get it right. The model I have in mind wouldn't be incompatible with that, so it is something that could be considered.