>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.
>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.