From e104ae2223ee3c99239ac78ac3e86cc810e0a3e7 Mon Sep 17 00:00:00 2001 From: Anthony Wang Date: Wed, 9 Nov 2022 14:13:15 -0500 Subject: [PATCH] Make Kela more agnostic to the underlying protocol --- README.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 831d4fc..479189a 100644 --- a/README.md +++ b/README.md @@ -12,14 +12,14 @@ The web sucks. Today's web is dominated by a few gigantic walled gardens locking 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. +- **Powerful**: Kela is flexible and can handle all sorts of applications, as well as being agnostic to the underlying protocol (usually HTTP). - **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](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. +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](https://en.wikipedia.org/wiki/Distributed_hash_table) 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. @@ -28,6 +28,8 @@ Because public keys are annoying to read and type, Kela uses a friendly [petname ## 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!