this post was submitted on 15 Jul 2023
522 points (97.1% liked)

Fediverse

28490 readers
926 users here now

A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).

If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!

Rules

Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy

founded 2 years ago
MODERATORS
 

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.

top 50 comments
sorted by: hot top controversial new old
[–] gelberhut@lemdro.id 87 points 1 year ago

Yes. It is a must have feature, actually.

[–] hot_milky@lemmy.ml 61 points 1 year ago (2 children)

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.

[–] Kichae@kbin.social 21 points 1 year ago (1 children)

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.

[–] hot_milky@lemmy.ml 8 points 1 year ago (1 children)

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.

[–] hitmyspot@lemmy.world 5 points 1 year ago (1 children)

Perhaps a notification when it occurs, so you could unsubscribe if you wish.

[–] reiver@mastodon.social 6 points 1 year ago (2 children)

@hitmyspot @hot_milky

That is what happens on Mastodon now when someone moves their account from one server to another — you get a notification of them following you from the other server.

load more comments (2 replies)
[–] Neato@kbin.social 4 points 1 year ago

Have something like a mass message to subscribers with a link to the new instance.

Then the old instance owner can take the old community name back.

[–] Gutless2615@ttrpg.network 43 points 1 year ago* (last edited 1 year ago)

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.

[–] elbarto777@lemmy.world 39 points 1 year ago (3 children)

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?

[–] average650@lemmy.world 25 points 1 year ago (1 children)

To the first, rollback.

To the second, is that a problem?

[–] Die4Ever@programming.dev 8 points 1 year ago* (last edited 1 year ago)

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

load more comments (2 replies)
[–] RickRussell_CA@kbin.social 32 points 1 year ago (5 children)

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.

[–] assa123@lemmy.world 18 points 1 year ago

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.

[–] ralC@lemmy.fmhy.ml 11 points 1 year ago

Let instance admins approve or deny the requests then

[–] Hypersapien@lemmy.world 4 points 1 year ago (1 children)

What if an instance were able to block specific communities on other instances without defederating?

[–] samae@lemmy.menf.in 7 points 1 year ago (1 children)

Users can already do so, what would instance-level block bring?

[–] copygirl@lemmy.blahaj.zone 3 points 1 year ago (4 children)

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

[–] Aux@lemmy.world 4 points 1 year ago (5 children)

That will break federation in a very bad way. Imagine you're on such instance which doesn't want NSFW content, but you subscribe to a NSFW community. Admins block it and you don't even know it, you just don't see your community anymore. What do you do? Create another account elsewhere? The whole point of federation is to use one single account EVERYWHERE. Otherwise it's no different then Reddit and Hacker News - just two random online sites and you have to create a bazillion of accounts everywhere.

Admins should not block anything coming from outside instances. Admins should never defed. Instead you, as a user, should have all the tools to moderate your own feed. If you give away your rights and freedoms, you'll lose them forever and you'll be abused on Lemmy the way you were on Reddit.

[–] copygirl@lemmy.blahaj.zone 3 points 1 year ago (2 children)

If you want your freedom – whatever that means to you – you go to an instance that represents those values. Admins that run their own instance get to decide how they moderate that instance. And that includes blocking (or defederating) whole instances, communities, or individual users. You don't have to sign up to one that does something you don't like.

Besides, you don't seem to understand the importance of moderation. If it wasn't for the ability to defederate, we'd have tons of fake instances with fake users creating fake posts. Not to mention people going out of their way to make others feel miserable. Do they have the right to spew their hatred? I have my opinion, but it doesn't matter. I happen to also have the right to join an instance that has a policy to take care of that stuff so I can browse for things that actually interest me.

load more comments (2 replies)
load more comments (4 replies)
load more comments (3 replies)
[–] dudebro@lemmy.world 4 points 1 year ago (1 children)

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

[–] Molochalter@lemmynsfw.com 9 points 1 year ago (1 children)

Yeah exactly, defederation should be limited to instances with incompetent or malicious admins, not with crap communities.

The feature to allow a user to block a server not just a community should help with that.

[–] explodicle@local106.com 4 points 1 year ago

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.

[–] sickpusy@sh.itjust.works 20 points 1 year ago

This is indeed a very important feature. It needs to take into account that if similar name community exists on another server how the merger would proceed as well in terms of exporting and importing cache of posts and comments.

But generally it should be easier to transfer from one instance to other.

[–] indigomirage@lemmy.ca 19 points 1 year ago* (last edited 1 year ago) (1 children)

At first I thought this was a great idea. But need to understand a bit more about the security implications for those that subscribe and post to the communities that want to do a move. It's one thing to trust your credentials to the host server, but quite another to implicitly trust the community mod who wishes to move. How would the old posts migrate? How would integrity of the constituent posts be preserved? How easy would it be to inject comments into to historical posts and republish them on the new, official, server? Could you be held liable (whether officially or through reputational risk) for posting content that wasn't really yours? Maybe there are good mechanisms to maintain integrity of data? I'm just not sure what they are.

I think there may be implications to this that are not obvious.

Happy to have these concerns assuaged, of course!

load more comments (1 replies)
[–] kukkurovaca@lemmy.blahaj.zone 14 points 1 year ago* (last edited 1 year ago) (2 children)

It's going to be incredibly necessary in the long run. Decentralized means some proportion of important communities are going to be on servers that will eventually be shut down for various reasons. Not everybody who's running an instance now will run it forever, but there may be communities with important conversations that folks will want to preserve.

Mastodon has account migration and Lemmy community migration should work similarly.

[–] RxBrad@lemmy.world 8 points 1 year ago (1 children)

Mastodon migration is still somewhat limited.

Your posts don't transfer over, being the big catch.

(Most everything else does, though)

[–] Kichae@kbin.social 5 points 1 year ago

Ok, Calckey migration, then.

[–] Emperor@feddit.uk 5 points 1 year ago (2 children)

And Lemmy should also have account migration.

[–] CMahaff@lemmy.world 6 points 1 year ago

I made a tool that does this until we can get something baked into Lemmy itself: https://github.com/CMahaff/lasim

There are a handful of other options out there too if ya search for em. Mine backs up / copies subscriptions, blocks, and a handful of profile settings.

[–] mojo@lemm.ee 13 points 1 year ago

It should, but the Lemmy devs are swamped right now to add more features. Before, they had a pretty small dev team too. Now that there's a lot more eyes on Lemmy, hopefully we'll get more features while they iron out the stability issues.

[–] Emperor@feddit.uk 13 points 1 year ago (1 children)

Just thought I'd flag this up: !issue_tracker@lemm.ee

It's a community to coordinate idea suggestions as well as image tracking. Perhaps this could be flagged up over there with a link back here or cross-posted.

[–] Deez@lemm.ee 3 points 1 year ago (2 children)

Does a bot post issues raised / commented on Lemmy, back into GitHub? Or is it just one directional?

load more comments (2 replies)
[–] linuxFan@lib.lgbt 12 points 1 year ago (1 children)

Additionally, if your server disappears *cough* VLemmy *cough* you should be able to load a backup from somewhere and register your channels on another server. I realize this is still a crawl-walk-run scenario and that's going to be far in the future. But we can still hope for it.

load more comments (1 replies)
[–] AndrewZen@lemmy.world 11 points 1 year ago (1 children)

server gets defederated, server moves to new server, defederation bypassed.

[–] dudebro@lemmy.world 3 points 1 year ago

This is part of why it's better to have users block servers instead of servers block servers.

[–] Lifes_Like_Plinko@lemmy.fmhy.ml 8 points 1 year ago (1 children)

And somehow be redundant/mirrored/backed up. Hacks, crashes, instance owner gets pissed, decides to take their sandbox and everything in it. Lots of ways and reasons that communities wlll disappear and a way to recover might be helpful.

[–] barryamelton@lemmy.ml 4 points 1 year ago (3 children)

All of this could be there with the matrix.org protocol. The matrix protocol saves the comments and content in a directed graph, and that graph is copied to every instance, once one views it. It may not scale though. But it has benefits, such as encryption (making communities private or gated when under attack)

load more comments (3 replies)
[–] NENathaniel@lemmy.film 7 points 1 year ago

Yep, I lost my communities when vlemmy shut down

[–] ziggurism@lemmy.fmhy.ml 6 points 1 year ago

Absolutely. I don’t think we really have fediverse until we get this.

[–] FreddyNO@lemmy.world 6 points 1 year ago
[–] MrFlamey@lemmy.world 4 points 1 year ago (1 children)

What actually happens when servers are federated with one another? Does the content of each server get mirrored for redundancy, or does it just mean that users can see users, posts and communities from servers that are federated? When they defederate, does content that was previously visible to users just vanish completely, or is it merely that new content (created after defederation) will not be visible?

load more comments (1 replies)
[–] Chozo@kbin.social 4 points 1 year ago* (last edited 1 year ago) (3 children)

I feel like this opens up the doors to "impostor" instances opening up, copying content from another instance and re-uploading it elsewhere. I can already think of tons of opportunities to commit various types of fraud this way, honestly.

There may also be legal issues with importing user account data and content, as well.

[–] WhoRoger@lemmy.world 7 points 1 year ago

Nothing is stopping anyone from copying content already.

Legal issues - possibly, but then everything you write or do is federated already.

load more comments (2 replies)
[–] d4rknusw1ld@lemmy.world 4 points 1 year ago

Yeah there HAS to be a way to cache all the posts comments replies etc at a certain point. Maybe every so often it flashes a cache on your server; saves everything; and lets you either create new with what you had OR move or.

load more comments
view more: next ›