Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross-instance account linking/syncing? (nomadic identity) #1571

Open
3 tasks done
AlexBlackRaven opened this issue Jun 25, 2023 · 4 comments
Open
3 tasks done

Cross-instance account linking/syncing? (nomadic identity) #1571

AlexBlackRaven opened this issue Jun 25, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@AlexBlackRaven
Copy link

Requirements

  • This is a feature request and not a bug report. Otherwise, please create a new bug report instead.
  • Please check to see if this request (or a similar one) already exists.
  • It's a single feature. Please don't request multiple features in one issue.

Describe the feature you'd like

Managing accounts from other instances (from your own instance) seems like it would be a useful feature for lemmy. Smaller instances are not as stable as big ones (hosting costs, drama and falling off in popularity can make em fall off sometimes). Since there's effort to create topic-specific instances and people's interests are often different, there arises a need in managing communities on other instances than your own. Of course, you can make your main account a moderator on a different instance (or so I think, I haven't tried yet), but this just means that the list of moderators gets cluttered and you have to manage a lot of accounts. I guess this is slightly related to the "multireddit" topic.

There are bound to be some things to consider on how to handle accounts linked to others from defederated instances. I'm just not able to think it this far through and most definitely will miss something important, but some way to manage multiple accounts would be nice for personal convenience and overall fediverse stability.

@AlexBlackRaven AlexBlackRaven added the enhancement New feature or request label Jun 25, 2023
@techno156
Copy link

What you're looking for might be "nomadic identity", where you just have one account that can work across multiple instances.

I believe it's somewhere down the line, but there's no concrete plan for implementation just yet.

@AlexBlackRaven AlexBlackRaven changed the title Cross-instance account linking/syncing? Cross-instance account linking/syncing? (nomadic identity) Jun 25, 2023
@AlexBlackRaven
Copy link
Author

What you're looking for might be "nomadic identity", where you just have one account that can work across multiple instances.

I believe it's somewhere down the line, but there's no concrete plan for implementation just yet.

Ah, thanks, I changed the title so it's more searchable. Good to know it's on the radar already, even if far down the line.

@zyansheep
Copy link

One way to do this would be to have universal identities (pub/priv keypair) and then record users' comment, post, and profile history to a distributed self-verifying user-append-only datastructure (essentially a per-user blockchain, append-able only with the user's private key) as seen in scuttlebutt and polycentric. Parts of this datastructure can be kept track of by different servers based on the posts / comments those servers care to store, or the user themselves to avoid losses of data.

Benefits of this system include:

  • Easily be able to see if a given server is censoring a user's post/comment/profile (because each block in the chain has a count, so if the server sends block 49 and block 51 but not block 50, you will know you are missing something).
  • Servers can't replicate someone's cryptographic signature (and lemmy clients could do signature verification to make sure)

Downsides:

  • If you lose your keys, you lose your account :(, maybe this could be solved via password-protected recovery data split among multiple trusted servers / other users?
  • If someone steals your keys, they can post as you or invalidate the existing public keys to a new set, this probably means that servers will have to step in and verify for the rest of the network which key is the legitimate one, this can probably be done through the existing account system.

Ultimately, this system would allow some of the burden of maintaining identity to be shifted from the servers to the users, while still allowing the servers to manage important parts like names, preventing impersonation and providing account recovery mechanisms.

This is a difficult problem, and I don't know how well it would work for lemmy (would likely need a sizable update to the server protocol and clients and managing the transition from server-based to cryptographic identities would be difficult), but it would definitely be a big step towards solving one of the major issues with federated protocols :D

@DHager
Copy link

DHager commented Aug 5, 2023

It feels to me like "prove instance administrators aren't removing content" is an additional step beyond nomadic identity which brings in a lot of complexity and resources.

In contrast, consider a much narrower use-case: "I posted a lot on an instance X, it shut down for some reason, now I'm on instance Y and I want to prove I am the same owner of both accounts."

One way to solve that would be if the user created each of the two identities with a public key, ideally in some way that is intrinsic to the identity so administrators can't meddle without creating a new identity. Then the user can wield their private key to sign content that they submit.

  • Sure, if you lose your key you're stuck, but it'd still be a step up in control.
  • Yes, administrators could censor you, but they wouldn't be able to impersonate you except with unsigned posts, and even then you could go to another instance and make verified posts calling attention to their actions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants