lemmy
lemmy copied to clipboard
LemmyNet
Community Grouping
A lot of new users are really concerned with the idea of duplicate communities, e.g. lemmy.ml/c/gaming and beehaw.org/c/gaming.
While I don't think this is as big of a concern as they do, I think we could mitigate it by allowing Group to Group follows. If a community admin finds a remote community that seems to overlap theirs, they could send a follow request to the remote community. The community receiving the follow request would not automatically accept the follow request; it would show a notification to the admin. If this admin accepts the request, both communities would add the other to their followers collection.
When a post is made in a community, the community would send the post to any following communities so those remote communities could display the post. If a user tries to create a post with a link, the community would check its own posts and the posts from followed communities to determine if its a repost.
EDIT: I submitted this feature request to kbin too.
It's awesome that you're thinking about this.
One thing I'm wondering though is if this proposal is implemented, how would this prevent dup communities? After all, admins could just ignore the follow request.
And even that assumes that the creator of a dup would actually even take the step to follow the community they would be duping. I'd imagine they would still want to create the dup community, even if it's already been created, since they may intentionally want to compete with the original and have their own mods, more control of it, etc.
I think that having to manually set up all these groups really stifles federation, blacklisting when appropriate seems like much less work and allows users to federate with eachother even if admins are not very motivated to set up groups.
I think that having to manually set up all these groups really stifles federation, blacklisting when appropriate seems like much less work and allows users to federate with eachother even if admins are not very motivated to set up groups.
So are you suggesting this type of grouping happen automatically instead of by moderator intervention? That would be problematic on several fronts, if that's the case. Issues such as working through variations in naming come to mind, along with pulling in one-off "dead" copies that never gained traction. The current status quo is having multiple "duplicate" communities showing up in the user's feed.
I think the proposal above strikes a good balance, as it would put the communities in control of how they group up (if at all), and this would likely happen anyway due to user pressure. With the way this federation works, the same userbase are likely following the various duplicate communities anyway.
I don't think the user should see the group right away, I think the user should look at a community, and then by default they will be in the "Local" tab, and they can then click "All" to see all communities with the same name. That way it functions the same as the home page, although this time it's limited to the community name.
@markcellus I don't think this proposal would prevent duplicate communities at all. I'm don't think there is a way to prevent duplicates and I don't think that would be a desirable thing even if it were possible. Like I said in the OP, I don't think duplicate communities cause any harm to the fediverse. Communities will either gain a critical mass of users needed to keep themselves relevant or they'll die off and users will find other communities. Eventually, most general topics will have a large thriving community and many niche communities. Each can have their own moderation policy and community culture without interfering with each other.
The main purpose of my proposal is to address the issue of duplicate posts and the "right" community. Federation is messy and multiple communities will be created for a topic because an instance is new and its users don't know about the huge community on another instance or some similar situation. New users who may be unfamiliar with federation could be confused about which one is the "right" one to subscribe to or knowledgeable users may subscribe to all of them just so they don't miss anything. With my proposal, if you find a community in a community group (this could use a better name), you'll be able to subscribe and receive all posts from the wider community group not just the individual community and you'll only see posts once instead of once for each community.
by default they will be in the "Local" tab, and they can then click "All" to see all communities with the same name.
@Visne communities having the same name does not mean those communities are duplicates of each other. Language is weird and there's plenty of reasons why they may have the same name but not actually be related. Even if they are about the same topic, one community may not want to associate with another community.
Mods don't have to set up these groups. This is how it works now. You can easily subscribe to multiple communities whether they have the same name or not. My proposal just makes it easier on new users who may be confused about the presence of multiple different communities and makes it less likely that you'll see the same post over and over.
It's a really cool idea, I guess one semantic question is:
Are you informally merging two groups by having both Actors follow each other?
OR
Are you mirroring an existing group locally, and pushing your responses back to the source? (Kind of like how GitHub lets people Fork repositories and send data back upstream)
Personally I think that if the mods of multiple communities mutually agree to "group", then when users subscribe to one of those grouped communities, the user is prompted that the community they're attempting to subscribe to is in a group with x, y, and z communities, and they're asked if they want to be subscribed to all communities in the group or just the one community they clicked "subscribe" in.
The mutual agreement for grouping being an important part, as it would mean that mods of one community would submit a grouping request to another, and the mods of that other community would see the request, and all other communities in the group, and could accept or ignore the grouping request. That way, it wouldn't be automatic on creation but would be optional for communities that wanted to sub-federate, themselves. Perhaps communities in a particular group could also choose to ignore specific communities in a group if they didn't want their local members to act like it, should a specific community they didn't quite agree with enter into the group at a later date, though that scenario isn't something I'd put much thought into resolving.
How would you guys feel about adding a toggle to allow/disallow community grouping in a users profile settings? That way it's left to the user whether they want to group similar communities across various instances(such as gaming in the given example above) or not.
Wouldn't grouping mean that you'd see a bunch of duplicate posts in the same view? A lot of communities post news articles and if multiple communities in the group are making similar posts, you'd see a bunch of duplicate posts.
I would be in favor of a unidirectional community-level subscription so that community X at instance A can decide to subscribe to community Y at instance B (without permission from Y).
Comments and votes made to posts in X viewers' views of Y posts would go to Y as if they were made there directly.
There would need to be deduplication if Y also subscribed to X so that posts & comments to not duplicate infinitely.
If X is subscribed to Y, the Y posts in X would be subject to Y's moderation. It may also be useful to provide an ability for X moderators to hide posts&comments such that they do not appear in X viewers' views of X (but remain unaffected in Y).
This system would also happen to allow users to create something analogous to a public multireddit or other generalized aggregator of other communities.
@Kealper @markcellus My idea was that you would only need to subscribe to one community in a community group and then you would receive all posts posted to any community in the community group (but deduped so you don't see the same post over and over). If a link has already been posted in community A and someone tries to post it to community B in the same community group, the post creation interface will let them know that link has already been posted.
@rhino1998 That's exactly what I'm describing except it would require a two-way relationship.
@DeadSuperHero Both, I think? The goal would be once communities have formed a community group, subscribing/posting to one community would be the same as subscribing/posting to any other community in the community group.
@jazir5 There would be no need for a user toggle here. This proposal is about communities. A non-mod user doesn't have any control over a community so a user setting wouldn't have any affect over that community.
you would receive all posts posted to any community in the community group (but deduped so you don't see the same post over and over)
Sure, but how would a post qualify as a "duplicate"? Post titles or post links aren't a good way to determine duplicates because the comments in each post would certainly be different.
@jazir5 There would be no need for a user toggle here. This proposal is about communities. A non-mod user doesn't have any control over a community so a user setting wouldn't have any affect over that community.
I'm referring to the group being included at the user level. So in this case, the user would be able to toggle whether they want all of the federated groups that the mods/admins have permitted to be grouped via their named community(e.g. gaming on lemmy.ml) or whether they want to only see local instance results with no grouping of like-named servers whatsoever. This functionality would probably be even better if it can be granularly targeted towards specific subs/communities depending on what the user wants to appear in their feed.
@markcellus I meant for the posts to be deduplicated by ID (localized to source instance), not by content, so the same post from the same community from the same instance wouldn't be duplicated from X -> Y -> X subscriptions (or other larger cycles). Potentially this could be made simpler (and implicit) by having the subscribed content in community Y not federated to viewers from X's instance, so transitive community subscription does not work.
@zcdunn Why do the community group relationships have to be symmetric? (Also what happens if X <-> Y group and Y <-> Z group? Do viewers of Z end up seeing content from X?)
Asymmetric subscription would allow smaller communities to unilaterally decide to aggregate content from larger communities.
The biggest risk of asymmetric subscriptions I see is that communities could exist that effectively "steal" content from other communities, but any posts made to the community by the user actually go to the subscribing community. Consider the degenerate case of communities X and Y where X has no/minimal content by itself and Y has lots of content. Users viewing X could add posts to X mistakenly thinking users viewing Y would see it, effectively shadow-banning themselves at the post level.
@markcellus I think the post link works fine. Right now when you try to create a new post with a link, your instance will tell you if there are any other posts (that your instance is aware of) with that link. My thought was communities in a community group would prevent reposting a link that's been posted to a community in the community group and it would show the existing post for that link. This would prevent duplicate posts across the community group and keep conversation on a single post.
@rhino1998 You bring up a good reason in your final paragraph why I would prefer a symmetric relationship. But one of my main goals with this proposal was to try to centralize conversations happening on the fediverse (obviously without relying on a central authority and giving up the benefits of federation).
As for your question, I don't think viewers of Z would see content from X. Y would only federate its own posts, not posts from its wider community group. This is the same situation as a microblogging context where a user A follows user B and user B follows user C. User A would not see posts from user C because B doesn't federate C's posts.
@jazir5 so if you subscribe to [email protected] and its in a group with [email protected] and [email protected], you would want a toggle so you could switch between just posts from [email protected] and posts from [email protected] and the wider group? Personally, I don't think this is necessary because the idea is that all three communities are based on the same topic and so logically they are the same community. It should be almost transparent to the user.
But all that said, I don't see a user toggle conflicting with this feature. I think it could be a later addition if this proposal is accepted.
@jazir5 so if you subscribe to [email protected] and its in a group with [email protected] and [email protected], you would want a toggle so you could switch between just posts from [email protected] and posts from [email protected] and the wider group? Personally, I don't think this is necessary because the idea is that all three communities are based on the same topic and so logically they are the same community. It should be almost transparent to the user.
But all that said, I don't see a user toggle conflicting with this feature. I think it could be a later addition if this proposal is accepted.
@zcdunn Correct! I think leaving it up to the user whether they want the grouping feature at all would be the best of both worlds, because then the feature isn't completely foisted upon a user with no option to choose the larger federated group or not.
I think user control is absolutely imperative to allow the user to be fully in control of what content they see. My interpretation is that there is absolutely no downside to allowing full user control of the content they see (also, I'm so tired, I sincerely apologize for any redundancy in this comment).
This toggle-ability would solve/mitigate the conflict that others in this issue are suggesting here. I just don't see any downside with a toggle. A toggle essentially allows Lemmy groups to function as it does now, and also allows the additional functionality we are requesting. That way it's opt-in/opt-out.
I just had a random thought. What if there was an option to group/display communities with the same display name. That way moderators could modify their community to opt in or out of a grouping by distinguishing themselves visibly.
soaps@foo, soaps@bar, soaps@buzz -> "Soap Opera Fans" and "Soaps, Detergents, and Cleaners" humor@foo, funny@bar, jokes@buzz -> "Funny Jokes and Humor"
I described over here, what I think is a variation of @rhino1998 's suggestion. It's much simpler and more intuitive, and more useful in general ways than the proposals that try to combine communities just because they have the same name, or relies on agreements or group-creation.
It simply affords communities the ability to follow other communities, which would be resolved at view-time by the user's interface. Here's an example of that:
One way I would suggest re-framing this feature is by allowing the mods of communities to republish posts from other communities, especially communities of other federated instances. They would be giving up some mod authority because they can't moderate the discussion of other instances they publish, but that's a choice they have to make as a mod of a community. Ultimately, they would also only be able to to republish content from other instances federated with them as well.
For users, they could still decide to block instances they don't like, or create and moderate their own community (or potentially a private community) that republishes content from other communities.
Having some kind of tagging system that could help automate the process of which content to republish to your community Ultimately, duplicate communities should exist across different instances - it is just something that has to be accepted. This way, admins don't have to think about breaking local communities in order to federate or de-federate.
@gsisko That's not a re-framing, that's exactly what I'm proposing. A community in a community group would show posts from other communities in the community group.
They would be giving up some mod authority because they can't moderate the discussion of other instances
They wouldn't be giving up any authority. They would still be able to moderate all posts within their community. If a post comes from another community, a mod could choose to remove it from their own community's feed. If the mod blocks a user from their community, that would prevent any of that user's posts from showing in the community, even if that post was coming from another community within the community group.
They wouldn't be giving up any authority. They would still be able to moderate all posts within their community. If a post comes from another community, a mod could choose to remove it from their own community's feed. If the mod blocks a user from their community, that would prevent any of that user's posts from showing in the community, even if that post was coming from another community within the community group.
That's a good solution, Mods wouldn't be able to remove the thread from another server instance, but they would be able to remove third party posts from appearing in their feed, which is most certainly the most rational way to tackle that issue. A+++ for the foresight!
I may be a little drunk here, and I may have only skimmed this thread so, if someone else has said this already, sorry. But what Iād like to see is simple grouping at the user level. Let me make my own groups of communities, I can view these groups as if Iām looking at the whole subscribed view. Then, when posting, there should be a default community in the group to post to of the users choosing (editable), and perhaps give the option to post to all of them. Limits would be likely required on that.
Any consideration for the hashtag based approach https://github.com/LemmyNet/lemmy/issues/818#issuecomment-1602243367 ?
Personally I don't think symmetric sync is a good idea, instance owners should have full control over their communities, which means why should they have to ask permission to subscribe their community to another community?
Would a user have to set the hashtag? Maybe if we have a list of topics and a user can post AND add in corresponding topics, then a user can subscribe to a topic.
.. which sounds like hashtags, but I sort of want it structured so that #dog and #dogs wouldn't necessarily be different.. or if it did would be the same thing somehow. I also don't really want people shoving a bunch of random tags to wind up everywhere.
My case is similarish I started a community and someone else started a similar community that has much more traction. In a perfect world we merge and users easily find the merged one.
Now I'm sort of considering just closing mine down and linking to theirs, but that sort of kills the benefits of federation.
.. sort of like we need community federation. Without it, the community winds up split.
In a perfect world we merge and users easily find the merged one.
@csm10495 That is what this proposal would solve. If you grouped your community (I'll call it [email protected]) with the remote one ([email protected]), then they are now in a community group. Any user who subs to [email protected] would see posts from all posts within its community group (including [email protected]). Users wouldn't not be able to posts links to [email protected] if they've already been posted directly in [email protected] or posted in [email protected]
Note [email protected] and [email protected] would both still exist. A user could still find either in search and subscribe to them (even both, though it wouldn't have any additional effect). The community group would not have its own name or URL. You could be subscribed to [email protected] and I could be subscribed to [email protected] and we would see/participate in the same threads.
Another note This proposal has nothing to do with hashtags. The grouping is achieved with just a Follow request between Group actors (communities)
@zcdunn I think there are two separate conversations to have.
- The ability to create curated "multi-groups". So community A can also automatically bring in posts from community B and community C.
- The ability to create community groups where posts are deduplicated.
The second one seems more challenging technically and philosophically.
On a technical level, it would require the ability to dedup and track posts across servers. I don't have much insight into the code, but that's considerably different than just allowing moderators to populate subs with remote posts (clearly denoted as such) automatically.
On a philosophical level, it seems that the second feature would almost necessitate explicit buy in from multiple communities. I'm pretty sure we have all seen our fair share of mod/admin drama over the years. The amount of times these community groups would be both instantiated and maintained.
I don't really have the right to insist on anything since I don't even know the first thing about RUST, but I really feel like we should focus on @jamon 's suggestion.
