336
Lemmy.ml and beehaw.org getting hammered with traffic because of spez ama
(lemmy.blahaj.zone)
Everything about Lemmy; bugs, gripes, praises, and advocacy.
For discussion about the lemmy.ml instance, go to !meta@lemmy.ml.
I like the sound of this, just unsure how this would be able to authenticate an account on behalf of a home instance that's down, in a trustworthy way.
I'm not familiar with the inner workings of Lemmy and the Fediverse, so the following is based on similar implementations I'm familiar with...
SSO implementations usually require the website the user originally registered on (home instance) to confirm the account is real and authenticate it, and in most cases a new user account is automatically created using the SSO authentication details (this would prevent the user from appearing as if they're using their home instance).
To achieve what you want, I think we'd need some kind of way to export the user account and any signing keys used to prove the user is who they claim to be in the fediverse, and then re-import those to another instance. I'm not too sure if SSO would be able to achieve it if the home instance is down.
On the flip side, I'm pretty sure SSO with a Lemmy instance that is active could work. While it would bring a lot of benefit to less tech-savvy users, and a lot of convenience to us when we're given a threadiverse link to another instance, from a technical perspective I think that would be a challenging implementation. Users would need to be careful about having their credentials phished on a malicious instance too
i'd also be worried that some corp would try to take control of the centralized sso mechanism and thus control the user base. imho we must avoid the instinct to centralize anything.
but potentially maybe there's a federated directory where people could register and be assigned a server to do load balancing to key problems like lemmy.ml are experiencing (?)
Since we're a decentralized federated network, it would stand to reason that the SSO implementation would also be so. Maybe something built on top of DHT shared by every instance, which just stores user key hashes to verify they are who they say they are. That way there would be no issue with central authentication authority and all instances will go by the hash table for user auth.
Quick check and here's what mastodon has been doing on the issue https://github.com/mastodon/mastodon/pull/16221