Changes
1 changed files (+34/-8)
-
-
@@ -1,20 +1,46 @@# LibreFed # Kela Highly experimental federation protocol using identity-based cryptography A new federation protocol. Kela combines the best ideas from email, IPFS, BitTorrent, ActivityPub, Nostr, and Yggdrasil ## Motivations Existing federation protocols like ActivityPub have a number of problems, including nomadic identity (being able to freely move your account around instances) and having multiple AP accounts for Mastodon, PeerTube, WriteFreely, Gitea, etc. The web sucks, and no one knows how to fix it. The most successful decentralized web protocol, ActivityPub (or blockchains, if they actually worked), suffers from many problems, such as not being able to easily move accounts between servers, making it vulnerable to server shutdowns. ## Ideals ## Public-key identity 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**: - **Fast**: Kela uses aggressive caching and minimizes the number of hops between user-to-user connections when possible. - **Secure**: We can solve many of these problems by rethinking how our protocol handles federated identity. Instead of using the instance URL as part of the full username, we use the public-key to form the full username. For instance, your username might look like `billiam@d981a0c873` instead of `billiam@example.com`, where that hex string is your public key. Your account can be associated with any number of instances, including instances of different software, and your data is incrementally replicated across all instances. If someone wants to message you, their instance either has the URLs of your data instances cached or you have to manually give them the URL of one of the instances (like in a traditional federation protocol). Instances will store users' public keys encrypted, so only users will be able to sign messages, proving that they haven't been tampered with by any of the instances. This scheme is potentially vulnerable to MITM attacks, so this will have to be investigated in more depth later. ## 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](https://en.wikipedia.org/wiki/Distributed_hash_table) formed by all servers. This returns a string containing their server's URL, signed with that user's private key to prevent tampering. ## Replication 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. As mentioned earlier, user data is replicated across multiple instances. To maintain consistency, a [CRDT](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type) can be used. Because public keys are annoying to read and type, Kela uses a friendly [petname](http://www.skyhunter.com/marcs/petnames/IntroPetNames.html) [system](https://spritelyproject.org/news/petname-systems.html) so users can assign human-readable names to public keys. ## Applications You can tunnel HTTP (no TLS needed!) over Kela to host websites. ## Storage Kela is also a decentralized storage system. You can store data on your server, and it will be replicated between them. ## 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](https://social.exozy.me/@ta180m/108201791226634267) for Kela were braindumped by [Anthony Wang](https://a.exozy.me) on the fediverse in April 2022 and written down in a [repository](https://git.exozy.me/a/Kela/src/commit/a2561afe554382ae4ba9fcd9beb276497127dc3c). A few months later, Anthony Wang and [Alek Westover](https://awestover.github.io) developed a very basic [prototype](https://git.exozy.me/a/HackMIT) during [HackMIT 2022](https://hackmit.org). The name "Kela" comes from spelling "Alek" backwards.
-