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?
This was an example, not an identifier.
lemmy.ml is the domain. And the instance on that domain has a private and a public key.
If you nuke your first instance and recreate it the keys will be different, which means you suddenly have two different instances for lemmy.ml when the new instance starts to federate. Which basically is lemmy.ml-1, lemmy.ml-2, …
So what should other servers do? Only accept the first public key they ever saw for a domain as an instance? Then block new instances from the same domain? Or is there a way to differentiate the instances? Or do you nuke all content of an old instance when a new one pops up with a different public key?
If someone creates a second instance for the same domain all hell breaks loose either way. Because the new instance can have myuser@lemmy.ml that already existed with the old public key. Should federation just crash at that point? Throw an error? Block this user because it existed in the past? Treat it as a new user, but with the same name (which would be horrible UI wise)?
I still don’t get what you complain about.
In an alternative timeline the keys are in no way related to any instance or domain or whatever. Not even to identically named
Personobjects on a recreated instance. AllActivityobjects are signed with a specific key. TheActoris also signed with the specific key. The private key is not stored anywhere except on the machine the user using the actor from.All activities performed by an actor and the actor are signed. If you copy over the activities to another instance the sign is still valid. If you rename the instance it is still valid. If you modify the action or the actor it becomes invalid. (Somewhat similar to how mail signing works.)
If you reuse a hacked/stolen/whatever actor, all actions you perform with this actor are unverified because the person misusing the actor cannot sign the actions. If you change the public key stored in the
Actorobject all previous actions cannot be verified to be done by the actor. This could be solved to make the public key store in the Actor a list. So you can add multiple keys with validity start and end date (all signed with the next key).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?