diff options
-rw-r--r-- | proposal.md | 24 |
1 files changed, 24 insertions, 0 deletions
diff --git a/proposal.md b/proposal.md new file mode 100644 index 0000000..cb6cd7f --- /dev/null +++ b/proposal.md @@ -0,0 +1,24 @@ +# 6.5820 Proposal + +## Group members + +Anthony Wang, Daniel Wang, ?? + +## Idea + +This project aims to use a distributed hash table to build a cryptographically secure federated messaging network with public-key based identity. The design is similar to other federated systems like email's and Mastodon's ActivityPub, but the crucial difference is that users are addressed by their public key, instead of a username@server address, and a DHT is used to resolve public keys to a user's server address. + +An example for how this system works: + +- Alice has an account on the server example.com with public key 464658c26f2003d3. Bobert has an account on the server mit.edu with public key cee5b4af3efaf109. +- Bobert tells Alice his public key so she can message him. +- Alice creates and signs a message with recipient cee5b4af3efaf109 and sends it to her server, example.com. +- This server must find out which server this recipient corresponds to in order to deliver the message. +- All the servers in the network form a distributed hash table that maps public keys to servers. example.com sends out a request with cee5b4af3efaf109 to the DHT and soon receives a response with the answer, mit.edu, signed by Bobert's private key. +- Finally, example.com delivers the message to mit.edu, where Bobert can now find it in his inbox. + +The two main advantages of public-key identity of traditional username@server addresses are that it enables users to easily migrate between servers and that it simplifies cryptography. In addition, user accounts can belong to multiple servers, and user data is replicated using primary-backup replication. + +## Implementation + +We will use the Chord algorithm for the DHT and implement it in Go. |