4.5 KiB
Kela
Kela is a new decentralized web protocol, combining the best ideas from ActivityPub, email, IPFS, BitTorrent, Nostr, Secure Scuttlebutt, Yggdrasil, AT, Spritely, and more.
Motivations
The web sucks. Today's web is dominated by a few gigantic walled gardens locking in billions of users, while tiny decentralized web projects fail to gain any traction. Recently, the ActivityPub federation protocol has seen some success with Mastodon, but it suffers from many problems. For instance, identity in ActivityPub is strongly tied to domain names, which complicates migrating accounts between servers and making ActivityPub vulnerable to sudden server shutdowns or bans. In addition, ActivityPub uses ActivityStreams 2.0 under the surface, which is both a JSON-LD modeling protocol and a great way to get lost in the Semantic Web rabbit hole of horrible complexity. In short, implementing ActivityPub isn't fun, and you don't even get a great federated network once you're done! Similarly, peer-to-peer networks like IPFS or Secure Scuttlebutt are also complicated, but we can fortunately simplify things by introducing hub nodes. Nostr shares many common ideas with Kela, but Kela takes them a step farther without introducing much more complexity.
Ideals
Kela strives for these ideals:
- Simple: Many decentralized web protocols are horrendously complex (I'm looking at you, Urbit!). Kela is simple and can be taught to someone in 30 minutes.
- Powerful: Kela is flexible and can handle all sorts of web applications.
- Fast: Kela uses aggressive caching and minimizes the number of hops between user-to-user connections when possible.
- Secure: Strong cryptography ensures that all connections in Kela are end-to-end encrypted.
Identity
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, 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
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.