sure you can just make a new one, but all of your old posts and comments won’t show up. Not to mention your DMs too

it seems kinda counterproductive to the goal of lemmy being federation where you can just move to another instance if yours gets bought by Elon or an admin goes corrupt, but it’s not made simple to do that.

I’ve seen many people be on lemmy.ml that would switch but they’ve been using it since the start of lemmy and they don’t wanna restart

I know mastodon has a little “hey this user has moved to @user@newinstance” popup but that’s not really that elegant either

  • litchralee@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    1 day ago

    I’ll take a stab at answering the titular question, which also requires answering the related question: “what really is federation?”

    In my conception, federation makes the most sense if we rewind to a (almost) bygone era, in the early 21st Century where every specific communities hosted their own web forums, before a time when Facebook groups or Discord “servers” were mainstream. Of those, I think the ones which endured the longest are those related to automobile enthusiasts, usually about a specific model (eg Corvette), in order to exchange tips and servicing info.

    What federation solves is the challenge of maintaining a different login – aka identity – on each web forum that someone frequents. Back then, it was a separate username and password for the car enthusiast forum, another for the regional gossip forum, yet another for the anarchist forum. And despite that, the underlying credential was usually the same: an email address.

    So instead of managing an identity at each different web forum, federation is the idea of having a single identity that can travel to different domains. The open model of email is instructive, because sending an email necessarily interacts with the destination domain, which is usually not the same as one’s own. Phrased another way, the postal system was the first federated communication system, where different states honored the single identity and allowed free* passage. One might compare this to one of the EU’s four freedoms, the free movement of labor: a user may do work (ie write a post) on any instance in a federation, on equal standing whether they’re local or not.

    In the modern context in the 2020s, such a freedom is in stark contrast to the commercial alternatives: using a Facebook, Google, or Apple login to access any particular website more often than not puts oneself on a different (ie lower) standing than if they logged in with an untethered account. The usual problem is that such a common identity is tracked and sold to marketers, which explains why so many sites use these single sign-ons as a default, and only begrudgingly support “old school” account creation for that specific site.

    And worse so, if Google decides you are unworthy of a Google Account, then you simultaneously lose your online identity and any semblance of access to those services which you were using. Federation solves the latter, because if your federated identity is banned from your home instance, the freedoms of federation means you can create an identity elsewhere and use that to access Fediverse services, apart from the one which originally had reason to ban you.

    Nobody can deny you access to every instance, and that’s what makes it powerful: there is no centralized arbiter for the network. Sure, this means there will be some very ugly parts of the Internet that get to exist and possibly interact with the rest of the decent web. But just like with the majors, the challenge of moderation still remains albeit different. Some segments are wholly an island unto themselves (eg certain right wing circles that also use Fediverse software) because nobody else will federate to their instance.

    Going back to the original question, the central issue is that while the network is decentralized, a single identity necessarily is centralized on their home instance. And there’s no real way around this, because having a single identity means it must be unambiguous to reference: if I @ you, there must be exactly one possible identity, or else everything breaks down. So the notion of “transferring” an identity would become a horrible routing kludge like how “portable telephone numbers” are implemented in the Telco space: the original exchange has to remain alive to forward to the new exchange. And that’s basically unworkable in the decentralized Fediverse in general, because instances can come and go.

    There is no way to guarantee that one’s home instance stays alive forever, which limits the identity’s lifetime. If we had it leave a note that you’ve moved, how to we retrieve the note after the original instance is down? Telco could do it because there’s a centralized listing of all valid exchanges, but there is no such thing on the Fediverse. It’s the sort of thing that requires a “dying message” ledger, and it’s hard to imagine how something like DNS could solve that knowledge challenge issue.

    At bottom, creating identity resilience is hard and we don’t have it yet. But that’s because federation was always going to be difficult, and in spite of that, we seek out the world we want, not compromise with the world we were given.

    • Wildmimic@anarchist.nexus
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      23 hours ago

      Only possible alternative i know of is what Bluesky is doing - separate out the identity part into another service. Changing the location of the identity can then be resolved by updating the id that a comment is attached to; this edit can then be lazily be federated to prevent long standing accounts from grinding smaller instances to a halt.

      But that needs a lot of changes for a small payout - if you are on lemmy to establish a following, you probably haven’t understood Lemmy.

      • litchralee@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        0
        ·
        21 hours ago

        My cursory understanding of the BlueSky/AT approach is that posts are not anchored to the identity, but to a value akin to a DOI like how research papers are referenced. And in that way, something like a BlueSky post can be hosted as a standalone document, whose provenance is through a linkage to the user identifier maintained by the separate identity infrastructure. I believe this is why hyperlinks to BlueSky posts do not – and cannot – include the author’s handle, whereas Fediverse links often do (but aren’t required to).

        So yes, the server that hosts content is separate from the identity server. But the part I still don’t see is how to update a document’s associated identity if a user changes to a different identity server. It is indeed a separation of concern – which is very healthy and I do follow developments in the AT space which could be used to drive improvements in the ActivityPub world – but the same scenario is still doomed: if the identity server skips town suddenly, can former users restart with a new identity and reassociate to their prior documents? How can this be done securely?

        But my original point remains: the challenge is nontrivial and no one should underestimate the complexity, whether it’s in the ActivityPub or AT model. This federation thing is hard.