Add some random notes about public-key identity

1 files changed, 18 insertions, 1 deletions

diff --git a/README.md b/README.md
index d2e79b0..f84e61e 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,20 @@
 # LibreFed
 
-Highly experimental federation protocol using identity-based cryptography
\ No newline at end of file
+Highly experimental federation protocol using identity-based cryptography
+
+
+## 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.
+
+
+## Public-key identity
+
+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.
+
+
+## Replication
+
+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.