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

Add more to the writeup

This commit is contained in:
Anthony Wang 2022-11-09 00:30:39 -05:00
parent f8219aec85
commit 211c42243b
Signed by: a
GPG key ID: 42A5B952E6DD8D38
1 changed files with 15 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
README.md
View file

@ -1,39 +1,46 @@
# Kela
A new federation protocol. Kela combines the best ideas from email, IPFS, BitTorrent, ActivityPub, Nostr, Yggdrasil, AT, and Spritely.
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, 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.
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**:
- **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**:
- **Secure**: Strong cryptography ensures that all connections in Kela are end-to-end encrypted.
## 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, 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.
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](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.
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 can store data on your server, and it will be replicated between them.
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