They shouldn’t have to. Their server is intact, only the server address is unreachable forever.
Like your house still stands, but your street name is suddenly gone from all street signs and maps.
The problem is for the entire ActivityPub fediverse that identifies instances by domain names. If a server moved their domain they had to have a way to broadcast the name change to all the other instances. Mastodon had a way to this; Lemmy has none.
It’s like you getting a new phone number and you have to ask everyone in your contacts to change your number in their address books.
>If a server moved their domain they had to have a way to broadcast the name change to all the other instances.
even if lemmy had a way to do this, doing it for all the users at lemmy.ml would create a large load of federated network traffic between instances, and at the level of a single instance it would cause a lot of database changes (I’ve heard that the sql schema for lemmy isn’t very optimized).
also, as activitypub doesn’t prioritize synchronization (unlike git and matrix), there could be a lot of desynchronized state, with the name change of users reaching some instance but not others.
it would be interesting if lemmy.ml really went the clean slate way (and I think the original intention of the devs in running that instance was just to test their code, not to have it become a “flagship” instance), it would sure showcase a valuable lesson in the fediverse…that you shouldn’t rely too much on big instances (there is no huge facebook/twitter/reddit-like thing here).
even if lemmy had a way to do this, doing it for all the users at lemmy.ml would create a large load of federated network traffic between instances, and at the level of a single instance it would cause a lot of database changes (I’ve heard that the sql schema for lemmy isn’t very optimized).
but at the moment it’s generating a lot of server load as is, proportional to how many users on .ml instances are subscribed. every time a post is created or a comment added, the server software tries to post updates to the unreachable instances and fails, filling up the error logs.
if an instance migration tool is on the roadmap, now’s the best time and use case to re-prioritize and fast track it. any work the lemmy dev’s not taking on on this issue would be work for the admins of all the other instances.
They shouldn’t have to. Their server is intact, only the server address is unreachable forever.
Like your house still stands, but your street name is suddenly gone from all street signs and maps.
The problem is for the entire ActivityPub fediverse that identifies instances by domain names. If a server moved their domain they had to have a way to broadcast the name change to all the other instances. Mastodon had a way to this; Lemmy has none.
It’s like you getting a new phone number and you have to ask everyone in your contacts to change your number in their address books.
>If a server moved their domain they had to have a way to broadcast the name change to all the other instances.
even if lemmy had a way to do this, doing it for all the users at lemmy.ml would create a large load of federated network traffic between instances, and at the level of a single instance it would cause a lot of database changes (I’ve heard that the sql schema for lemmy isn’t very optimized).
also, as activitypub doesn’t prioritize synchronization (unlike git and matrix), there could be a lot of desynchronized state, with the name change of users reaching some instance but not others.
it would be interesting if lemmy.ml really went the clean slate way (and I think the original intention of the devs in running that instance was just to test their code, not to have it become a “flagship” instance), it would sure showcase a valuable lesson in the fediverse…that you shouldn’t rely too much on big instances (there is no huge facebook/twitter/reddit-like thing here).
but at the moment it’s generating a lot of server load as is, proportional to how many users on .ml instances are subscribed. every time a post is created or a comment added, the server software tries to post updates to the unreachable instances and fails, filling up the error logs.
if an instance migration tool is on the roadmap, now’s the best time and use case to re-prioritize and fast track it. any work the lemmy dev’s not taking on on this issue would be work for the admins of all the other instances.
I mean restart in clean slate, but yeah i feels like they won’t take that path.