Rather than communities being hosted by an instance, they should function like hashtags, where each instance hosts posts to that community that originate from their instance, and users viewing the community see the aggregate of all of these. Let me explain.

Currently, communities are created and hosted on a single instance, and are moderated by moderators on that instance. This is generally fine, but it has some undesirable effects:

  • Multiple communities exist for the same topics on different instances, which results in fractured discussions and duplicated posts (as people cross-post the same content to each of them).
  • One moderation team is responsible for all content on that community, meaning that if the moderation team is biased, they can effectively stifle discussion about certain topics.
  • If an instance goes down, even temporarily, all of its communities go down with it.
  • Larger instances tend to edge out similar communities on other instances, which just results in slow consolidation into e.g. lemmy.ml and lemmy.world. This, in turn, puts more strain on their servers and can have performance impact.

I’m proposing a new way of handling this:

  • Rather than visiting a specific community, e.g. worldnews@lemmy.world, you could simply visit the community name, like a hashtag. This is, functionally, the same as visiting that community on your own local instance: [yourinstance]/c/worldnews
    • You’d see posts from all instances (that your instance is aware of), from their individual /worldnews communities, in a single feed.
    • If you create a new post, it would originate from your instance (which effectively would create that community on your instance, if it didn’t previously exist).
    • Other users on other instances would, similarly, see your post in their feed for that “meta community”.
  • Moderation is handled by each instance’s version of that community separately.
    • An instance’s moderators have full moderation rights over all posts, but those moderator actions only apply to that instance’s view of the community.
      • If a post that was posted on lemmy.ml is deleted by a moderator on e.g. lemmy.world, a user viewing the community from lemmy.ml could still see it (unless their moderators had also deleted the post).
      • If a post is deleted by moderators on the instance it was created on, it is effectively deleted for everyone, regardless of instance.
      • This applies to all moderator actions. Banning a user from a community stops them from posting to that instance’s version of the community, and stops their posts from showing up to users viewing the community through that instance.
      • Instances with different worldviews and posting guidelines can co-exist; moderators can curate the view that appears to users on their instance. A user who disagreed with moderator actions could view the community via a different instance instead.
  • Users could still visit the community through another instance, as we do now - in this case, [yourinstance]/c/worldnews@lemmy.world, for example.
    • In this case, you’d see lemmy.world’s “view” of the community, including all of their moderator actions.

The benefit is that communities become decentralized, which is more in line with (my understanding of) the purpose of the fediverse. It stops an instance from becoming large enough to direct discussion on a topic, stops community fragmentation due to multiple versions of the community existing across multiple instances, and makes it easier for smaller communities to pop up (since discoverability is easier - you don’t have to know where a community is hosted, you just need to know the community name, or be able to reasonably guess it. You don’t need to know that a community for e.g. linux exists or where it is, you just need to visit [yourinstance]/c/linux and you’ll see posts.

If an instance wanted to have their own personal version of a community, they could either use a different tag (e.g. world_news instead of worldnews), or, one could choose to view only local posts.

Go ahead, tear me apart and tell me why this is a terrible idea.

HELL. NO.

 

There is a reason I don’t go on Mastodon (or on Twitter, for that matter).

permalink
report
reply
35 points

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.

Some suggested points are also against ActivityPub standard.

permalink
report
reply
8 points

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.

permalink
report
parent
reply
5 points
*

Or, I think this can be, kinds of, archived by ‘simple’ enhancement at client side without changing today’s server side implementation. At Lemmy client, user can choose to group several different communities to user defined virtual community. Like today’s client, we have ‘All’ and ‘subscribrd’ 2 big groups, If the web/app client allow user define more group like ‘news’ ‘meme’ etc, and combined then in one view, then that’s pretty much meet your needs? Tbh, this will be very cool feature if any client can do this, or there is already such client?

permalink
report
reply
17 points

That sounds great and all on paper but that also requires a ton of moderation overhead as now every small instance has to have enough mods to deal with everything being posted, since moderation would be local only. So all the spam and CSAM would have to be taken down by each individual instance. Would also somehow have to find a way for instances to pull the hashtags out of every federated instance too. The way it works on Mastodon is someone follows an account and that causes the data to get pulled in. On Lemmy you don’t follow users, you need a way to pull the data in.

The end result would be a mess of instances not even agreeing on vote counts with vastly different comments too, and even the posts.

Lemmy doesn’t aim to be an uncensorable platform. I join communities for the content, the users, and for better or for worse, the mods too.

The individual problems of having to deal with the duplicate communities will get worked on eventually.

permalink
report
reply
5 points

Good reply, like you explain this wouldn’t work. Just one thing:

Lemmy doesn’t aim to be an uncensorable platform.

https://join-lemmy.org/docs/users/05-censorship-resistance.html

permalink
report
parent
reply
4 points

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

permalink
report
parent
reply
11 points
*

Doesn’t your suggestion mean that a user from a small instance or their own instance can make a bunch of garbage posts (or even illegal posts) and then a moderator from every single other instance will have to delete their posts separately? That’s a ton of repeated work, and really opens up Lemmy to abuse.

permalink
report
reply
2 points

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

permalink
report
parent
reply
4 points

defederation is an admin action not a moderator action, and there are much fewer admins than there are moderators, so the workload would be a concern

permalink
report
parent
reply
1 point
*

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.

permalink
report
parent
reply

Lemmy

!lemmy@lemmy.ml

Create post

Everything about Lemmy; bugs, gripes, praises, and advocacy.

For discussion about the lemmy.ml instance, go to !meta@lemmy.ml.

Community stats

  • 265

    Monthly active users

  • 1.1K

    Posts

  • 14K

    Comments

Community moderators