[X] Did you check to see if this issue already exists?
[X] Is this only a feature request? Do not put multiple feature requests in one issue.
[X] Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.
Is your proposal related to a problem?
There are two main problems this proposal attempts to solve:
The user's dependence on a single server. This proposal would allow users to be apart of more than one server and to move between servers to avoid a single point of failure for user data or other services.
The inordinate control servers have over their users, managing users' entire identity as well as what user's can see of the rest of the network, and what they can post. This proposal would make it so that servers cannot undetectably censor any known user and cannot meaningfully impersonate their own users.
Describe the solution you'd like.
The solution I will describe here is heavily inspired by the scuttlebutt and polycentric protocols.
Instead of a user's history and identity being tied and stored primarily on a single server, any data a user generates (whether that be a post, comment, or profile update) is instead recorded in an append-only hash-linked indexed log (a "user history"), each entry signed locally with a private key controlled by the user, and distributed to a set of user-chosen instances. These signed and stored chunks of data can then be distributed by these hosting instances to other server's users in different contexts. Here's an overview of possible types of signed chunks.
Post / Comment
If a user makes a post or comment, their client creates a new "chunk" containing roughly:
The hash of the previous chunk
The number of the chunk (counts up from 0)
ID of Post commented on or community posted to
Content of the comment / post
Signature, can be verified by public key.
The server then takes this data, and forwards it on to whatever server hosts the community that was posted in to be shown to other users when the post or comment is requested.
Profile / Settings Updates
These are basically structured the same except instead of a post/community ID and data, it's just a diff between the old profile data and the new, which the server promptly updates in its database to show to any user or other server requesting this user's profile.
Authority Update
If the user needs to register a new key, invalidate an unused key, register a server as a trusted for recovery, or mark a registered key as compromised, this is itself a chunk added into the user's history. This chunk is must be signed by a previously trusted key or recovery server.
Any other server can request this information to present comments or posts as belonging to a specific user's public key, as well as the validity/authorization status of that key (i.e. so posts made by compromised keys can be marked as such to users)
Username Recognition
This protocol doesn't outline any kind of global username consensus algorithm, so it keeps the existing system where usernames are associated with servers, but extends it so that a given user may have multiple usernames on multiple different servers. For these purposes, the proposal includes a chunk "username recognition" chunk jointly signed by an instance's main keypair and a user's client keypair signifying the instance's commitment of giving a username to a user.
This makes it very obvious when a username is given to a different user, and shows the history of a given user's name across different instances.
Instances may also use this mechanism to prevent a user from having multiple different names on different instances, by only allowing a user to register a new name if they do not have any previously registered names.
Username history could also be used to prevent a user from trying to register a username on too many servers, to avoid requiring servers to unnecessarily maintain long lists of users. Usernames could also be "collectively claimed", whereby if a username is registered to multiple trusted servers, new servers won't allow registering other users with that username. Servers may independently decide whether to federate with other servers that respect/disprespect this policy.
This is just my general idea for a solution. There are lots of other details around aspects such as the specific crypographic primitives but I want to see what people think of this proposal first before addressing the more nuanced design or implementation details.
Describe alternatives you've considered.
What I'm proposing here is kind of an comprehensive version of what has been proposed in other issues:
506 (manually exporting/ importing account data from/to different instances)
3164 (auto syncing user data across instances)
1985 (moving an entire profile to a new instance)
This proposal would solve the root cause of all these issues: there is no need for migration or syncing users if there is only one user distributed across multiple servers!
It would also solve issues like cross-instance bans (https://github.com/LemmyNet/lemmy/issues/3399 ?) and anything else that relies on associating data with an identity across instances, because you can just associate the data with a public key instead of a specific account on a specific server. Even if a user tries to ban-evade by changing the public key and username associated with the account (while keeping the same comment and post history), it would be easy to tell for the server that banned the user just by going through the history of keys in the account and checking them against the banlist.
Additional context
Related issue: LemmyNet/lemmy-ui#1571 (cross-instance syncing & linking feature request). I commented a shorter outline of idea there, but then I figured I should open a more comprehensive issue on the main repo because it is not a ui-specific issue.
Edits
7/7/23 - Updated proposal to include multiple key idea and username recognition idea + other small edits.
Requirements
Is your proposal related to a problem?
There are two main problems this proposal attempts to solve:
The user's dependence on a single server. This proposal would allow users to be apart of more than one server and to move between servers to avoid a single point of failure for user data or other services.
The inordinate control servers have over their users, managing users' entire identity as well as what user's can see of the rest of the network, and what they can post. This proposal would make it so that servers cannot undetectably censor any known user and cannot meaningfully impersonate their own users.
Describe the solution you'd like.
The solution I will describe here is heavily inspired by the scuttlebutt and polycentric protocols.
Instead of a user's history and identity being tied and stored primarily on a single server, any data a user generates (whether that be a post, comment, or profile update) is instead recorded in an append-only hash-linked indexed log (a "user history"), each entry signed locally with a private key controlled by the user, and distributed to a set of user-chosen instances. These signed and stored chunks of data can then be distributed by these hosting instances to other server's users in different contexts. Here's an overview of possible types of signed chunks.
This is just my general idea for a solution. There are lots of other details around aspects such as the specific crypographic primitives but I want to see what people think of this proposal first before addressing the more nuanced design or implementation details.
Describe alternatives you've considered.
What I'm proposing here is kind of an comprehensive version of what has been proposed in other issues:
506 (manually exporting/ importing account data from/to different instances)
3164 (auto syncing user data across instances)
1985 (moving an entire profile to a new instance)
This proposal would solve the root cause of all these issues: there is no need for migration or syncing users if there is only one user distributed across multiple servers! It would also solve issues like cross-instance bans (https://github.com/LemmyNet/lemmy/issues/3399 ?) and anything else that relies on associating data with an identity across instances, because you can just associate the data with a public key instead of a specific account on a specific server. Even if a user tries to ban-evade by changing the public key and username associated with the account (while keeping the same comment and post history), it would be easy to tell for the server that banned the user just by going through the history of keys in the account and checking them against the banlist.
Additional context
Related issue: LemmyNet/lemmy-ui#1571 (cross-instance syncing & linking feature request). I commented a shorter outline of idea there, but then I figured I should open a more comprehensive issue on the main repo because it is not a ui-specific issue.
Edits
7/7/23 - Updated proposal to include multiple key idea and username recognition idea + other small edits.