Idea: if you mod a community on a lemmy.somewhere you should be able to migrate it to lemmy.elsewhere which would include all post & comment links being forwarded and subbed users having their subscription updated to reflect the new location.
I’m aware this would be a way down the road as user account migration alone is still not great but it would be a great feature for the fediverse to have to avoid centralisation and mod/server admin wars.
I think it should be a “copy community” feature, then mods can just prevent posts in the old community and make a sticky that points to the new location.
Making users automatically subscribe to a community on a different instance (even if it’s “the same community”) is pushing it a bit in terms of moderator power. Also makes things worse in terms of exploits and others have pointed out.
Mastodon uses aliasing for account migration. Your old account still exists on the original server, but it points to your new account. Following the old account automatically reroutes the follow to the new one. This could be done at the group level for lemmy without needing to manually lock the original group or ask users to find the new one.
The issue is that users might object to subscribing to a community on a particular instance. I guess it’s not the end of the world, you can always unsubscribe but I can imagine some people being very upset to be associated with certain politically leaning instances or worse.
Perhaps a notification when it occurs, so you could unsubscribe if you wish.
Data portability for instances and users is imo an essential feature of any fediverse app, and sorely missing here on Lemmy/Kbin. We’ve already seen the issue surface with the hacks in instances last week and other instances going down suddenly. Like mastodon, we need to be able to take our data to whatever instance we want easily.
Risky. Some hacker exploits a vulnerability, takes over the community and migrates it to some other server… then what?
Also, if a community leaves a specific server, what stops anyone else from re-creating it in the original server?
To the first, rollback.
for the first, you still have everyone subbed to the newly created community made by the attacker and all the links are still updated
if instead of migrating everything right away, you have the original server of the community give redirects for each request, then that won’t help if the original server is closing down, but it’s probably the only right way to do it, I guess you could also have an angry instance admin disable the redirect to keep the community on their own server
To the second, is that a problem?
migrating and then recreating the original is actually an issue that Github has when you rename a repo, Github will give redirects for the links to the old name of the repo, but if you create another repo with the old name then the redirects are no longer served and if someone clicks on an old link then they end up at the repo that stole the name instead of the repo that was renamed
so if let’s say there was an official linus_tech_tips community on beehaw and they moved to lemmy.world, some random person could create the community again on beehaw after the migration to appear official and hijack all the old links out on the internet
you fix that by keeping the old name reserved after migration, I don’t really think that’s a big problem in this case
I actually liked @Neato@kbin.social’s idea, instead of “migrating”, you just copy the community and then send a message to every subscriber, close the original community, and put a pinned post at the top, maybe a message in the sidebar too
But that also makes it incredibly easy for communities on defederated servers to set up shop elsewhere.
And those communities may be the sole reason that the server was defederated in the first place.
I think a possible outcome is that the larger instances would have to put a stop to open creation of new communities, to prevent toxic groups from setting up shop and moving all their objectionable content and users into the space.
I think it can be solved with a two step process. First, the mods of the community and only them can make a request to move from instance A to instance B, and second, the admins or mods of instance B approve the request, importing only the posts and comments from federated users.
What if an instance were able to block specific communities on other instances without defederating?
Allow the admins of the instance to enforce their rules?
Say you have an instance with a “no-NSFW” rule, for people who don’t want to randomly come across NSFW communities. Their admins could take care of the curating of rule-breaking NSFW communities without having to resort to defederating from the entire instance. This doesn’t have to be an outright block but just a filter that could prevent the community to show up in “All”.
A good community leaving a bad server can maybe work if the server doesn’t just turn that off.
A bad community that was hosted on a bad server can continue to be blocked on a server level.
A good server tolerating a somewhat bad community will let users continue to block communities.
Two good communities on one server might grow large and want to split servers.
Meh. I think if users focused more on blocking what they don’t want to see instead of defederating, then this wouldn’t be an issue.
This is only a problem if you’re one of the children who thinks: “I don’t want to see something, so neither should anyone else.”
Yeah exactly, defederation should be limited to instances with incompetent or malicious admins, not with crap communities.
