A free, community controlled replacement for Signal and WhatsApp

My aim in writing this is partly to provoke discussion, but also to point out some technology the potential of which hasn’t been fully realised yet. So, here is an outline of how I would replace the current generation of secure instant messaging applications. There are two dimensions here: governance and implementation. I’ll start with governance.

To start with, we have to consider who is in control. The problem with WhatsApp is that it is owned by Facebook and is now more or less a vehicle for further corporate surveillance in the form of contact and message frequency leaking. The problem with Signal is that Moxie has no interest in listening to anyone at all, and is in control by virtue of his ownership.

I would suggest that it is time to have a project which is not only free/libre open source software, but operated on behalf of a community by a cooperative in which regular users of software can participate. I imagine the form as a multi-stakeholder cooperative where a board is elected by:

• Dues paying ordinary members, eg people who use the service and pay £10 per month
• Operators who look after infrastructure requirements
• Contributors, which is to say anyone who has had code merged in the last X days (or who works full time on the project).

This is to protect specifically against private interests and to promote the participation of people who aren’t tech oriented. Ordinary people should still get a say in how services they rely on are run, how their data is treated and what features they consider to be important, and it is through representation rather than federation that I would secure this.

In terms of implentation, I would envision four components:

• A Kafka bus, where a topic corresponds to a user. A global “in” queue would see consumers copying messages to the user topic, with each message having metadata about what conversation it is part of and which participants it is for.
• A server that sits between Kafka and the client mediating access, offering web sockets for clients and running a Kafka consumer and producer for each connected user. The consumer waits for updates (eg message arrivals) which are pushed to the client by web socket. The producer pushes messages to the global queue to be processed, when they are received from the client. I’d suggest implementing this in Go, using Shopify’s Sarama and net/websocket.
• A “bot" to consume from the global queue, check messages are destined for users who want them (must be in the contact list of the recipient or some other criteria) and then produce on to the recipients' queues. As above, Go and Sarama would be reasonable choices here.
• A web client written in an uncontroversial, not sparkly and new but seasoned and stable JavaScript framework (Emberjs works nicely for Discourse and might be a nice choice). This would eventually need to implement something like Axolotl, which could potentially be done in wasm.

As engineering challenges go, this isn’t huge. Remember, half a dozen people or so made WhatsApp. This would require a pair of people to keep Kafka in good order and deal with other infrastructure and deployment issues, some experienced gophers, and a front end dev or two.

The above doesn’t address everything. In particular authentication is neglected: I’d suggest usernames could be anything an auth code could be delivered to. Email wouldn’t be a bad idea and would be cheap to run, with verifications delivered at account creation. If it became financially viable, phone numbers could be another type of auth. Even irc users, with their username appended with their irc network. We could even offer a contacts synchronization service to add value to the data sharing that is required for contact discovery, and be confident this information wouldn’t be data mined because of the participatory style of governance.

Raising funds for this wouldn’t be simple, but Wikipedia sets a precedent of a widely used and loved service that is funded entirely by donations. The key elements to the operation would, in my view, be:

• Aiming for financial sustainability, not profitability
• Membership involvement, in the form of meaningful opportunities to engage with the project roadmap and decisions around safeguarding user privacy. Members should also understand their financial impact, being given estimates of how many users they support every month when they pay their dues.
• User awareness of the unique setup of the project. Users should be aware that the service is funded by membership dues. One way that occurs to me as possibly effective in raising awareness of this would be to send messages annually informing users of how many degrees removed they are from a paying member, with a suggestion that they can sustain the service by joining and paying dues.

The infrastructure for this is cheap, too: services like GoCardless and Stripe plus any of the many many SaaS accounting offerings would do the job.

This is my two cents, partly in reply to this, but also as a followup to a previous post. I’ve been thinking about this for a while, and all I really want is a system that I can have some control over, rather than something I have to host myself. I’m fine with compromise as long as I have certain guarantees. I’ve written about this a little before and when I get chance I’m going to put together a POC.

I’d welcome interest and criticism. Forming a group to talk about this and share ideas is the next step, and I’d welcome contact from anyone who feels this would be a reasonable direction.