Community Grouping #3071
Comments
|
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. |
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. |
@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. |
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. |
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. |
|
There is a related discussion going on in lemmy-ui: issue 1113 |
|
@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 example@lemmy.ml and its in a group with stuff@lemmy.one and things@lemmy.world, you would want a toggle so you could switch between just posts from example@lemmy.ml and posts from example@lemm.ml 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" |
|
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 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. |
|
also see #818 |
|
Any consideration for the hashtag based approach #818 (comment) ? 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. |
@csm10495 That is what this proposal would solve. If you grouped your community (I'll call it !community@csm.social) with the remote one (!remote@example.com), then they are now in a community group. Any user who subs to !community@csm.social would see posts from all posts within its community group (including !remote@example.com). Users wouldn't not be able to posts links to !community@csm.social if they've already been posted directly in !community@csm.social or posted in !remote@example.com Note !community@csm.social and !remote@example.com 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 !community@csm.social and I could be subscribed to !remote@example.com 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 |
|
@zcdunn I think there are two separate conversations to have.
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. |
This already happens; it's the basis of federation. If a user follows a community, that community's posts are sent to the user's server. The same would be true of a community following another community. Deduplication would only require comparing the
Yes, that is intentional. As a moderator, you could choose to link with another community, which means your community is receiving new posts that someone else is moderating. That should require moderation collaboration. |
|
@zcdunn So that's an interesting point about intentional collaboration. I was thinking that smaller communities could pull in from larger communities without a vice-versa effect going. I don't see this as a big deal since federation implies those same users would be able to manually go into the other community anyway. I think the hash method would be a lot better. There are entire communities based around text posts that should be accounted for. However I do have some thoughts on this: Reposts are the name of the game on reddit. Would doing this prevent that? If so, we could get around this for a time comparison, but these should all be user configurable settings. I also believe what you suggested has far reaching enough implications that it warrants another ticket. A huge portion of moderator work is centered around removing duplicate links that are posted in rapid succession, or spam links. A hashing method would automated a ton of this, especially if we incorporate it with a spam blocklist. Thoughts? |
The point of the proposal is sharing posts between communities, which enables preventing of duplicate posts and consolidating conversation across the communities. Community !one@example.com may have different moderation practices from !two@somewhere.social. If !one@example.com is able to follow !two@somewhere.social without approval, deduping would prevent content from being posted in !one@example.com and its users would instead be commenting on posts from !two@somewhere.social. This could lead to a large mismatch in behavior/moderation in !two@somewhere.social. Requiring community follows to be symmetrical obviates any extra moderation. Yes, users in !one@example.com can also subscribe to !two@somewhere.social. But if they do, they have a direct relationship with that community and know they have to be aware of its rules. Those same users wouldn't immediately know when they're browsing !one@example.com that the post they're reading and commenting on aren't directly from that community but instead from another community that requires different behavior. (I think posts should have some indication of the originating community, but most users won't pay attention to that all the time).
Once two communities are grouped, they are effectively a single community. Subscribers to each individual community see posts from both, posts are deduped, and subscribers are commenting on the same threads regardless of which community they're subbed to. There would be no reason to allow reposting because if a post has been posted to one of those communities, it's already available in both. Users would still be able to repost it into another community or even create a post linking to the original post (though I think most users/moderators would find that spammy, just like reposts).
My suggestion is the topic of this thread. You can't dedupe posts without having a scope for the duplicates and a measure of uniqueness. The scope is the grouped communities and the measure of uniqueness is a posts' |
|
Duplicate of #818 |
|
@Nutomic This isn't a duplicate of #818. That issue is about allowing users to create their own groups of communities, but his issue is about linking communities to share content between them. EDIT: It looks like alot of people in that thread did start suggesting ideas more similar to this one, but the OP was requesting a user feature to group communities. That thread has kind of devolved into everybody suggesting their own ideas so there's not really any coherent discussion. |
|
If you are an active user (not moderator) of Lemmy, the requirement for this becomes apparent almost immediately. One of the biggest strengths of these forum are communities-at-scale. Being able to easily post and interact with large groups of people is the benefit to the user that makes Lemmy (and all other social media) appealing. As a user, I recently wanted to post to AskLemmy. Almost every single instance has thier own separate AskLemmy implementation. Naturally, I'd tend to post to the one with the most users. But inherently, I'm missing the majority of users by only being able to post to one. I.E., I posted to AskLemmy@lemmy.ml (which had 3k users), but by doing that, I'm missing out on the users from lemm.ee, behaw, lemmy.world which in total are far more than 3k. Grouping communities eliminates this poor user experience at the expense of creating more difficulty for moderators. I personally think this is a necessary tradeoff to allow Lemmy to reach critical mass for usage. No one wants to individually subscribe to 5 different versions of AskLemmy, nor do they want to cross post 5 separate times. User-side groups can obfuscate this initially from the user, but commenters will be restricted to the interactions local to thier instance, so you also miss out on much of the conversation generated from the post (lemmy.world commenters, cannot comment on behaw comments, etc) which again provides a poor user experience by limiting the ripple effect of the post. |
|
That’s a great breakdown of the problem. I would add that what we really want probably isn’t really ‘AskLemmy’ but ‘AskFedi’. At the very least for both Lemmy & kbin, but ideally (eventually) for all fedi apps. |
|
This recently came up again, cited by a user who was deciding to move back to Reddit. Merged communities is a really good idea, even if it is implemented at the most basic user interface level, so they just get a feed of x communities they merge themselves under one group name. Ideally though, this would be done by mods. Keep it simple and don't apply mod control to the merged communities. |
|
I've written up an extensive summary of this issue from the point-of-view of the /r/rust use case: https://blog.erlend.sh/transitioning-r-rust-to-the-threadiverse Group-to-Group follows as suggested by OP is a distinct feature and is indeed not a duplicate of #818. It's closer to LemmyNet/lemmy-ui#1113, but that issue mixes a lot of different concepts and has no clear resolution (it also ought to be moved away from lemmy-ui as it's by no means UI-specific). What's being proposed here has been clearly specified as FEP-d36d. I suggest reopening this issue and renaming it 'Group-to-Group following - FEP-d36d'. |
This FEP proposes a method of sharing content across federated forums to reduce the amount of duplicate content across forums. Previous discussions can be found on the [/kbin issue](https://codeberg.org/Kbin/kbin-core/issues/149) and the [lemmy issue](LemmyNet/lemmy#3071). Co-authored-by: Zachary Dunn <zdunn@rygen.com> Reviewed-on: https://codeberg.org/fediverse/fep/pulls/118 Co-authored-by: 0x1C3B00DA <0x1c3b00da@noreply.codeberg.org> Co-committed-by: 0x1C3B00DA <0x1c3b00da@noreply.codeberg.org>
|
I believe the proposal is extremely relevant to supporting the success of the platform. The danger is real for fragmentation and alienation of communities that share essentially the same individuals, topics, and values. Voluntary associations of communities supports the broader design objectives of integration without centralization. In fact, no particular reason would emerge that communities integrated as such may not be hosted on the same instance. I would contribute a few suggestions, as follows:
|
|
I have just realized the issue was closed as a duplicate, and I am agreeing with other comments that the issue absolutely is not a duplicate of #818. The objective of the current request is allowing a seamless integration of communities based on mutual agreement, not the creation of an external entity that encompasses several communities. I strongly suggest keeping the issue open. The topic is important, and many extremely valuable contributions have already been made to the discussion. |
|
@erlend-sh, I am understanding the proposed mechanism as presented in FEP-d36d to have the following features:
I am new to Fediverse discussions, and may have some inaccurate understandings. I realize, also, that the current location may not be most suitable for broader discussion. However, the observations I have given seem to be implied or stated by the proposal, yet I personally feel doubtful are the best choices for how users and communities would interact most successfully within a system such as Lemmy. |
|
Seems right to me 👍 The best place to discuss the mechanics of FEP-d36d is in its respective SocialHub discussion. |
and others
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
GrouptoGroupfollows. 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 theirfollowerscollection.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.
The text was updated successfully, but these errors were encountered: