I’d hardly describe this as the product of a ‘great mind’, but I do think it’s important to discuss alternative ways of doing things. There’s some good reasons voiced here for why this (as written) is impractical, and it sounds like a solution with similar goals but better implementation is in the works, so that’s great to see. My favorite thing about Lemmy is that you can post something a bit out there like this and have a legitimate discussion about it; if this were Reddit, it’d have 400 downvotes and a bunch of replies telling me to kill myself, and that’d be the end of it.

Edit: Sorry, thought this was a different reply.

I mean block the instance’s posts from showing up on the community level, which would need to be a new option implemented with this hypothetical system.

Yep, it’s a valid criticism. Theoretically the recourse in that case would be to block the instance entirely, but it’d still require multiple moderator actions (across multiple instances).

In this system, each community needs moderators from each instance it is on. A small instance run by one person would face a challenge finding people to moderate potentially hundreds of communities.

Each instance would be responsible for moderating its own posts, so a single user instance wouldn’t need a moderator at all unless other instances were failing to moderate their content, but I agree, this is a hurdle, and would make it easier for bad actors to go to tiny instances and post spam.

You mention that a user who doesn’t like their instance’s moderation can use a different instance, but this isn’t easy. There’s no account migration at the moment. This is more of an issue with the lack of that functionality, since there are many other reasons people would want to switch instances.

Sorry, I might’ve been unclear - I simply mean that you could visit the community from your instance via that instance - e.g. [yourcommunity]/c/worldnews@lemmy.world - to see lemmy.world’s “view” of the community. Your account would still exist on your own instance.

If this was implemented, presumably it would require merging all existing communities that share names.

A fair point; while it’d benefit some communities to have their content combined, it would not benefit others; this is a very valid criticism.

So all the spam and CSAM would have to be taken down by each individual instance.

Or only by the instance from which they were posted. If an instance is a moderation graveyard and is generating CSAM spam, it probably just needs to be defederated from, but I agree that the necessity to rely on local moderators to cleanly remove a post is a problem with the proposal.

Would also somehow have to find a way for instances to pull the hashtags out of every federated instance too.

If each instance shared a list of communities that it hosts with each instance that is aware of it on first discovery and periodically thereafter, it would assist with this. Wouldn’t need to duplicate the content, just share a list of communities that exists. (I think that lack of duplicated content would actually be an improvement over the current system where, unless I’m mistaken, content is being duplicated, but I might also have an imperfect understanding of how it functions now.)

Well, under this theoretical standard, you’d only be posting to a single community; you wouldn’t be literally tagging communities on your post. The hashtag comparison was more to how you view hashtags on Mastodon (e.g. you’re searching for a hashtag and seeing all related posts from every instance.)

Okay, sure, but the underlying point is that the moderators of that community moderate all posts regardless of their origin, so biased moderators can direct the course of discussion. It’s more a problem for broad topical communities with polarizing topics.

Your proposal seems to target the same issues as with multi-community support https://github.com/LemmyNet/lemmy/issues/818, which just got 6000€ funding from NLnet. Which seems to be a cleaner way of achieving the same goal.

That’s great, maybe it’s (or will at some point in the future be) a non-issue, then. (For what it’s worth I did search for similar things before posting this, but apparently didn’t hit on the right search terms.)

Some suggested points are also against ActivityPub standard.

I’m not familiar enough with the intricacies of ActivityPub to be able to comment on that; this is obviously not a set-in-stone implementation, and it sounds like some version of the underlying idea is possible, judging by the above.

That being said, creating a private instance is a relatively difficult hurdle. By providing private communities, an admin can take care of the hosting, along with all of the other communities, while those who want something more controlled and closed can have an easily accessible option.

That’s fair, and I’m honestly probably just thinking about worst-case scenarios that won’t actually happen. There’s plenty of ways malicious actors could already be doing some pretty bad things and they don’t seem to be, so it’s probably fine.

Eh, we already have private communities.

I did mention further down the comment chain the one use case for this I can think of - communities for info and feedback about the specific instance to / from its members; things like donations, financial disclosures, etc. - that you wouldn’t want participation in from anyone not actually using the instance. It has its place; I’m more afraid of seeing popular communities going instance-only for whatever reason, with it being used solely to drive signups on a specific instance.

I mean it’s fine on paper. But like… imagine that a popular instance - lemmy.world, let’s say - has a community that’s very popular and, for whatever motivation, decides they want to push people to move to their instance (or at least create accounts there), so they change one or more of those popular communities to be local-only.

Best case, they fracture the community. Worse case, a very large number of users start making accounts there to use those communities, and abandon other instances. Worst case, they use the large influx of signups they get from such a move to promote themselves, grow even further, and eventually do something malicious.

We can already create private instances that don’t federate for those niche communities; I don’t really see what this feature is adding other than specifically having communities dedicated to that specific instance (With instance-specific information like donations, financials, outage notices, that sort of thing.)

Hopefully these don’t start getting used too frequently, as it kind of… defeats the purpose of federation. Would not want to have to make accounts on multiple instances just to participate in niche communities.

Just because it’s an edge case doesn’t mean 30% of your userbase won’t encounter it!

I work at a company whose entire business model is providing QA to other companies. I work directly with some very large, public companies, and some smaller ones. Almost all of them have some form of dedicated in-house QA, which we supplement.

catch (Exception e) {
    Exception.autofix(e);
}

Done!

Sure, but it doesn’t stop their votes from impacting what you see. So it’s just adding an extra annoying step for you, without solving the underlying problem. In fact, I’d say it’s an even worse experience because instead of seeing a post with 30 downvotes and 2 comments, you’ll see a post with 30 downvotes and 32 comments, but they’ll either all be low effort garbage, or they’ll be invisible (because you blocked them). I imagine the moderators don’t want to deal with an influx of reports about this, either; especially because they don’t need the extra step to see who’s doing it and ban them at the community level.

This just creates an incentive for low-quality shit-post level replies from people who really want to downvote. Rather than “Downvote and move on”, you now have “Comment ‘go fuck urself’, downvote and move on” among people who want to be toxic.

Bold of you to assume it was $24 and not $5.

This is great. It’d be neat if it was just a checkbox that you could choose to enable or not (for all filters, when it’s enabled).