a/Kela
1
1
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Make Kela more agnostic to the underlying protocol

Browse source
This commit is contained in:
Anthony Wang 2022-11-09 14:13:15 -05:00
parent 211c42243b
commit e104ae2223
Signed by: a
GPG key ID: 42A5B952E6DD8D38
1 changed files with 4 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
README.md
View file

@ -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!