Comment on Can we make federation less dependent on domain names?
TheFogan@programming.dev 1 day ago
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.
gammaray@sh.itjust.works 1 day ago
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.
lambalicious@lemmy.sdf.org 1 day ago
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).