Kela

Kela is a new decentralized web protocol to make it easier for anyone to build and run decentralized web applications. It's basically a mishmash of ideas from ActivityPub, SMTP email, IPFS, BitTorrent, Nostr, the AT Protocol, and Spritely, but without the headaches of those existing protocols.

Motivation

One popular decentralized web protocol these days is ActivityPub, which is used by Mastodon and many other applications. ActivityPub is an incredibly flexible protocol, but it also has plenty of flaws. It doesn't have replicated, fault-tolerant storage so your data can be lost due to a server shutdown or ban. Also, usernames in ActivityPub include the domain name of your server, so you can't easily migrate your account from one server to another. Implementing ActivityPub is no fun either since it uses some complicated Semantic Web stuff.

Nostr is another popular decentralized web protocol, except it doesn't really work. Instead of having a name resolution system, in Nostr you just try messaging a bunch of servers that might have information about a specific user and hope for the best. Also, Nostr is focused primarily on messaging and isn't suitable for building decentralized web applications.

Purely peer-to-peer protocols like IPFS suffer from being way too complex and slow, so that's no good either.

Design

Alright, let's solve all those problems listed above! Kela consists of three components, a name resolution system using a DHT, a messaging service, and a storage service.

In Kela, each user has an ID, which is a public key. Each user is associated with one or more Kela servers, which store that user's data. To find out which servers a user is associated with, you can query the name resolution system. All Kela servers participate in the name resolution system and act as DHT nodes. Each server stores a complete list of all DHT nodes. When a new server joins the DHT, it tries to peer with an existing server in the DHT. Say server example.com would like to peer with test.net. example.com first sends a GET request to test.net/peer?peer=example.com. test.net replies with its list of DHT nodes. Once example.com receives this reply, it adds test.net to its list of DHT nodes and attempts to peer with all servers in the reply that it hasn't peered with yet. test.net now also tries to peer with the server that just contacted it, in this case example.com. Servers periodically go through their list of DHT nodes and remove nodes that are no longer online.

DHT get/set TODO

Messaging TODO

Storage TODO

Old stuff:

Let's start where ActivityPub went wrong: identity. ActivityPub uses usernames plus the instance URL (for instance, billiam@example.com) as identifiers. This ties your identity strongly to a server, but it's actually not necessary. In Kela, each user is still associated with one (or more) servers, but public keys are identifiers. Each user has a public and private key, and when you want to find a user's server, you query a DHT formed by all servers. This returns a string containing their server's URL or some other address, signed with that user's private key to prevent tampering.

Your account can be associated with multiple servers, and your data is replicated between them. To prevent sync conflicts, you designate one server as your main server, which is a single source of truth that replicates data to all your other servers. To migrate your account between servers, simply associate your account with a new server, which syncs over all your data to that server, and then deassociate your account with the old server.

Because public keys are annoying to read and type, Kela uses a friendly petname system so users can assign human-readable names to public keys.

Applications

In Kela, applications and bots are the same thing. Just like users, applications have a public key, and are functionally equivalent to bots or automated users.

You can tunnel HTTP (no TLS needed!) over Kela to host websites. Kela supports tunneling arbitrary data. Even better, Kela can replace your website's authentication system so you don't need passwords anymore!

Storage

Kela is also a decentralized storage system. You, and websites, can store data on your servers, and it will be replicated between them. Kela also supports access controls so you can give people read or write access to specific files.

Examples

Messaging app

Let's try building a simple messaging app with Kela. First, create a folder on Kela's storage system, and share it with the person you are messaging. Then, both people can add messages to the folder. Of course, the low-level details here can be abstracted away by a GUI.

Issues

Coupling identity closely to public keys makes verifying message integrity easy. However, if your private key leaks, you are screwed.

History

A few core ideas for Kela were braindumped by Anthony Wang on the fediverse in April 2022 and written down in a repository. A few months later, Anthony Wang and Alek Westover developed a very basic prototype during HackMIT 2022. The name "Kela" comes from spelling "Alek" backwards.