Submitted 2 months ago by gammaray@sh.itjust.works to fediverse@lemmy.world
It looks like some issues may arise if/when an instances 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 mean DNS is always the issue… but then that’s kind of the double edged sword as well isn’t it?
Conceptually 4 options come to mind.
DNS as current - weakness domain name changes or DNS outages or poisoning
IP address - Issues, migration etc… some instances may need to move services etc…
SSL private/public keys - probably the strongest I’d imagine. only real weakness I can see is… 1. it has no ability to find a server, and I guess if a server is hacked and it’s private key is stolen, federated servers would not be able to spot the imposter.
I do think 3 might be the strongest option. I don’t know anything on how lemmy etc… works. I’d imagine a strategy would be, When A and B federate with eachother, A records B’s Domain name, IP, and public key (and B gets A’s as well), if DNS goes down attempt recorded IP. If neither work wait for an incoming connection and if the new connections public key matches an existing public key, it assumes the identity.
But as far as the user side I don’t really know. Obviously we can only match users as their domains. I can’t imagine how I could find you again with gammaray@sh.itjust.works when sh.itjust.works domain is unregistered.
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).
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 instance 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.
Are instances changing names that often? Hexbear is the only one I have heard of and iirc that was only temporary.
Instances go down a lot – often permanently. e.g. kbin.social, lemm.ee, etc.
When an instance goes down, it takes out all the user accounts and communities on it, and it’s hit or miss if you can find copies of the posts on other instances.
silverpill@mitra.social 2 months ago
Yes, domain names can be replaced with cryptographic identifiers: https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md
Auster@thebrainbin.org 2 months ago
How interesting. Isn't the
did:system also what AT Protocol (Bluesky) uses? 👀silverpill@mitra.social 2 months ago
That's correct.
did:prefix is used to denote cryptographic identifiers, in theory one could even take adid:plcidentifier from Bluesky and then use it as identity for an ActivityPub application:https://github.com/bluesky-social/atproto/pull/3943
onlinepersona@programming.dev 2 months ago
DIDs aren’t unique to Bluesky
gammaray@sh.itjust.works 2 months ago
Thanks. This is a little complicated to wrap my head around. Is this already implemented and we just have to toggle it, or is this something that needs a special/unreleased version of lemmy in order to activate?
silverpill@mitra.social 2 months ago
I doubt that it will be implemented in Lemmy, the application architecture needs to be different in order to support cryptographic identities.
But there are other implementations (they are listed near the end of the document).