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
ActivityPub (which is the protocol used by Lemmy, Mastodon, PixelFed, and other fediverse platforms) doesn’t have a built-in system for account migrations. Accounts are tied to an instance. Any migration features are handled at the application level, like Mastodon’s, and will be limited by the protocol.
ATProto, which the protocol used by Bluesky, has a more complex account system which does allow for migration. I’m not intimately familiar with the details, but the gist is that your DID is not tied to your instance, and your data store can be independent as well. I don’t know how this works in practice, since the ATProto ecosystem is basically just Bluesky, and a few other things that piggyback on Bluesky accounts. It appears to be at least a little complicated: https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migration.html
Honestly, yes, this is a problem with the design. ActivityPub is not resilient against servers going offline or going rogue. It’s a lot like email. If you change email providers, that means a new identity, and all you can do is point people to it as best you can.
Same reason it isn’t easy to transfer your Apple account to Google.
They are completely separate sites, that just happen to talk to each other.
Nonsense/disinfo. Apple and google accounts are hard to transfer because of technical differences, whereas on the fediverse they use the same format and everything.
You can’t do it on fedi because nobody’s built a mechanism to update all your content to use the new account.
Sure, it might not be completely accurate, but, it’s essentially the same idea, and should help basic understanding of the question asked.
It gets like half the info right, that’s not a good answer. Others in the thread have done a much better job of explaining it simply and well
There is no good way to transfer already sent messages and written posts. Transfering all satabase entries connected to your user account may be possible, but depending on how active you’ve been, this would already cause a lot of traffic. The next issue is images. Do you transfer them also? That would mean even more traffic. How do you handle federated content? Your messages not only live on your home server, they are duplicated to all federated instances. You’d have to contact all instances to change owner of those posts. Alternatively, your old server would have to keep redirecting to your new account. All in all, there are so many edge cases to consider for so little gain, it doesn’t make sense to invest dev time into it.
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.
I would love if at least the block list and subscription list could be moved more easily.
So youd like to have more of a centralized kinda thing? Maybe try Reddit.
Doesn’t Piefed have that feature?



