Just a random thought experiment. Let’s say I have my account on a lemmy instance: userA@mylemmy.com. One day I decide to stop paying for the domain and move to userA@mynewlemmy.com, and someone else gains it and also starts up a lemmy instance.
If they make their own userA@mylemmy.com, how do federated instances distinguish who’s who?
Have I misunderstood the role of domain names in this?
You still don’t seem to grasp the issue I’m pointing to.
You have instance 1, lemmy.whatever, this instance federated content to lemmy.ml. So now lemmy.ml holds content from lemmy.whatever.
Instance 1 gets nuked. Either because someone stole the domain, or the admin simply lost the private keys and had no backup. Or they had a backup but it’s old and half their users got lost. A new Lemmy instance gets set up on lemmy.whatever (with a new key obviously). This is Instance 2.
Now lemmy.whatever starts federating content to lemmy.ml, but from instance 2.
How do you differentiate content and users from instance 1 and instance 2? It’s the same domain, but different instances as the keys don’t match. Do you block instance 2? Do you delete everything from instance 1 and now instance 2 is the “true” instance for the domain lemmy.whatever? Do you mark all new content from instance 2 as “unverified”?
Sure, with private keys in place a user test@lemmy.whatever from instance 2 can’t modify content from the instance 1 user test@lemmy.whatever. But the instance 2 user could create new content under the name of the old user. How is this federated? Do other instances show the guy as test(2)@lemmy.whatever because the keys don’t match?
Let’s stop it here. Instances are completely irrelevant in my idea.
*sigh* The keys are in the
Actorobjects and in theActionobjects and not in the instance. You cannot validate any instance, you cannot validate if an action was performed on a specific instance. You cannot prevent actors of the same name after the previous instance was wiped.All you can do is validating if an action was performed by an actor existing at the time the action was perfoed and that both were signed with a specific key.
So the only things you secure are access to existing posts, comments and roles, but without any further checks if this is still the same user, correct?
So if user@lemmy.whatever creates 10 posts, 100 comments and is the moderator of 5 communities (on other instances) then the public key would secure that only that user can interact with that data. Makes sense.
But now the domain gets stolen, a new Lemmy instance is set up, a new user@lemmy.whatever is set up. This user is named user@lemmy.whatever, exactly the same as the original one. They just don’t have the right key to interact with their old content.
Now that user wants to moderate one of those communities again, are they treated like a different user (because keys don’t match)? Or just locked out (because you can’t have two users with the same name as moderator for the community)? Your whole idea makes sense, but when it comes to enforcing those ideas you run into a dozen issues both for federation and when it comes to present the data in the UI.
And you get phishing issues on top. If they are treated as separate users by other instances, they could just write another legitimate moderator “Hey, it’s me, user@lemmy.whatever. I got accidentally kicked out of the community, can you re-invite me as moderator please?” so all the work you put in for security is for naught.
The only thing I secure is that for a given
Actionby a givenActorit can be validated that those were signed with a given key.Everyone can interact with that data, but since those are signed with a specific key the sign would become invalidated.
Since the key and signature are just additional attributes of the
Actorobject they’ll be the same user federation-wise. An instance admin needs to manually validate why theActoruses a different key now. If theActoris used to perform malicious things it can be verified that those things are done with a different key. What’s done with this information is up to the instance admins.Exactly. Key signing does not prevent social engineering.