Can we make federation less dependent on domain names?
-
I was also considering something along the lines of option 3. I'm not sure of a foolproof solution, even DNS has the potential for imposters and being revoked.
Yeah, the weakness of SSL is basically the same as the weakness of DNS: that someone can remotely impersonate you or revoke your identity. But there is a major difference: DNS is designed so that your identity is taken away as part of the system: you can not ever declare your identity yourself, you have to rent it from an external entity controlled by corporate, government or both. Whereas in SSL if your identity is taken away for the most part it's purely your fault (only you should be having your private keys).
-
It looks like some issues may arise if/when an instance's domain name changes. Is there any way we can change federation so that we don't need to rely on such a central point of failure?
Hypothetically an instance could federate an activity telling all other instances about it's new domain name.
But once we get post, community and user migration working there will be much less need for it - everyone could just move themselves.
-
Hypothetically an instance could federate an activity telling all other instances about it's new domain name.
But once we get post, community and user migration working there will be much less need for it - everyone could just move themselves.
I still don't understand how this is not akin to falsifying data. If we normalize servers copying data from other instances and just rewriting the URL, there is little in the way for malicious actors to create piefed instances to scam others pretending to be someone they are not.
-
Didn't mean it was. Just mentioned it as it was the most common example I knew. But thanks for the link! Reading it now.
-
It looks like some issues may arise if/when an instance's domain name changes. Is there any way we can change federation so that we don't need to rely on such a central point of failure?
Irc solved this by having list servers domains that give a list of irc servers so instead of having random servers that go down you have a network of distributed servers that work together.
-
I still don't understand how this is not akin to falsifying data. If we normalize servers copying data from other instances and just rewriting the URL, there is little in the way for malicious actors to create piefed instances to scam others pretending to be someone they are not.
Is Piefed implementing this in some weird way?
Iirc previous work on this in the fediverse involved a very clear way of doing it that makes sure to address the issue you're bringing up there.
The idea is that you send activities to announce the move and mark the original actor as having moved to the new actor (and the new actor as being the new home of the original actor). Instances then verify this by whether that actor relationship is specified correctly on both sides (does going new actor -> origin actor -> new actor lead back to where we started from?).
Is that not also Piefed's implementation? Because if it is, I don't see your scenario being viable. Since the move needs to be acknowledged by both sides, it cannot just be faked.
-
AFAIK, "community migration" is done in PieFed by having the target instance making a request to the source one to change, and if the owner authorizes it then it PieFed recreates the actor and its objects on the target instance. Then it is up to the owner of the source community to delete the/close the source community.
My objection is to this recreation of the objects. If someone creates a post on "community@alpha" and the moderator decides to move to "community@beta", history is being recreated and it makes "beta" with activity that is not original. Also, having the consent from the community owner is not enough, because it ignores the fact that the members of the alpha community might not be interested in being associated with beta.
-
AFAIK, "community migration" is done in PieFed by having the target instance making a request to the source one to change, and if the owner authorizes it then it PieFed recreates the actor and its objects on the target instance. Then it is up to the owner of the source community to delete the/close the source community.
My objection is to this recreation of the objects. If someone creates a post on "community@alpha" and the moderator decides to move to "community@beta", history is being recreated and it makes "beta" with activity that is not original. Also, having the consent from the community owner is not enough, because it ignores the fact that the members of the alpha community might not be interested in being associated with beta.
Oh yeah, this does not sound okay.
If user@delta creates a post on community@alpha, their post lives on delta, not alpha. Community@alpha should not be able to unilaterally decide that the post should instead live on beta. Delta needs to be the one to decide that.
Sorry for the political analogy, but this sounds to me like Russia and the US deciding on Ukraine's future without involving the latter.
-
AFAIK, "community migration" is done in PieFed by having the target instance making a request to the source one to change, and if the owner authorizes it then it PieFed recreates the actor and its objects on the target instance. Then it is up to the owner of the source community to delete the/close the source community.
My objection is to this recreation of the objects. If someone creates a post on "community@alpha" and the moderator decides to move to "community@beta", history is being recreated and it makes "beta" with activity that is not original. Also, having the consent from the community owner is not enough, because it ignores the fact that the members of the alpha community might not be interested in being associated with beta.
I almost feel like someone needs to do a write-up of the 196@lemmy.blahaj.zone debacle - while not a 1-for-1 example (it wasn't a migration attempt that functioned the exact same way as it would with PieFed), it's a good case study for userbase-community owner-instance dynamics that should be considered, specifically the bit in your last sentence.
