Frabjous Dei

Robert Atkins's weblog

RFCs not IPOs

There are many problems with the way we’re doing one-to-one and one-to-many short message communication over the Internet right now, but making a bunch of slimy venture capitalists rich isn’t one of them. So try and understand what the real problems are before writing another VC-funded, walled-garden messaging platform:

  1. If it’s not cryptographically secure, end-to-end, everyone from the NSA to 4chan is going to fuck with your users. This is not acceptable in 2015.

  2. If it has investors, commercial pressure will force you to make the user experience shitty (see Twitter) or sell your users out to someone who will (see WhatsApp.) If you can’t find a bigger fool to sell to, you have to close down and the users are left stranded.

  3. If it’s any kind of centralised (even federated) system it’s vulnerable to government, spook, corporate or hacker manipulation and shutdown, probably at the instant it’s most sorely needed.

By their very nature, proprietary, centralised, VC-funded, walled-garden platforms can not solve these problems. Even well-intentioned ones with pretty websites. Why is email is still going strong after 45 years? Ugly boring standards which allow anyone to write their own implementation and interoperate with everyone else on the Internet.

I love Twitter but I fear commercial pressure (see point 2 above) will soon force it to become something I don’t love or else go away entirely. I believe that in 2015 we have the capability to design and implement a protocol that will give us a secure, distributed, Twitter-like service with the side effect of making shitty proprietary walled-garden messaging platforms redundant.

I want a few core elements:

  1. Identities are simply public keys, managed in a distributed web-of-trust system similar to keybase.io.

  2. Strong, end-to-end cryptography for both authentication and privacy. Public messages you send are signed with your private key to authenticate their source and prove their integrity, private messages are also encrypted under the recipients’ public keys so they are secure in transit.

  3. Completely distributed, peer-to-peer operation. Client software stores-and-forwards received messages, possibly earning some kind of proof-of-work credit to prevent “cheating” clients leeching or otherwise harming the network.

  4. All of the above is documented in an RFC anyone can use to implement a client for their favourite platform—open or closed source, Free Software or proprietary.

I have never been part of a standards committee, nor am I an expert on the theory or practice of the necessary crypto. But I would very much like something like the above to exist.

And with a bit of luck, it might help usher in a new age of RFCs over IPOs.