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

  • Wildmimic@anarchist.nexusEnglish
    2·
    18 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.worksEnglish
      0·
      16 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.