Cross-instance "multireddits", that are also automatic and topic-based.

[zksmk]

I found the issue LemmyNet/lemmy#818 that talks about multireddits, but it seems it's about custom miltireddits that I assume would work like http://lemmy.ml/c/physics+linux@midwest.social, which is great!

This suggestion is a continuation of that, a second step, it's about an in-built automatic multireddit http://lemmy.ml/f/design feature that would display all posts from all /c/design from all federated instances.

I believe this would help decentralization and actual usage of other instances, and also lessen the creation of echo chambers.

VERY important note: mods of all communities would need to have a checkbox to opt-in/opt-out their community's posts from being displayed on this page.

[dessalines]

Dupe of LemmyNet/lemmy#818

[Visne]

This is not a duplicate, LemmyNet/lemmy#818 is about subscribing to a combination of arbitrary communities, this issue is about subscribing to all communities of the same name on all federated instances, even ones that might be added in the future.

I think this is extremely important for decentraliziation; without it it makes much more sense to start and join a community on the largest instance as it will have the most activity, but then it can still get banned, go offline, etc. and you get the same problems as a centralized platform.

Please consider re-opening this issue.

[Nutomic]

This would only work for communities which are already known by your local instance. It cant get new communities unless someone fetches them manually first. I suggest you read the federation docs and Activitypub standard to get a better understanding.

[Visne]

I know that it works like that, hence why I said "all communities on all federated instances".

I don't see this as a problem, as it is how Mastodon implements the ability to follow hashtags and its Explore page (where popular posts from other instances are shown). In fact, it's useful because it means that posts from defederated instances are not shown.

[dessalines]

I'm not necessarily opposed, but to me, using the name only to "group" communities across different instances, and view them in a single place, seems a little bit too centralized and global in our thinking.

Consider topic or regional based instances. An art instance, a woodworking instance, a city instance, a TV show instance, a content creators instance, all might have a /c/news community. None of those communities have anything to do with each other.

[Visne]

Well, in my opinion such a feature should be optional, such that you could still subscribe to a single instances' community. It should also be easy to exclude specific communities manually if the topics don't really align.

I agree it's not a very good fit for something like news (although I can still see it being useful, personally. Posts from smaller instances will get less votes anyways), but for other topics it would be.

I think it is especially useful for when an instance goes down, people from the community can still easily find eachother on other instances. It's also useful if the topic controversial, for example /c/piracy. Such a feature would really dampen any chaos that usually ensues after a large community gets banned on sites such as Reddit.

[Barbariandude]

I personally think it's a great optional feature. Basically a UI display mode which functions very similarly to a multireddit, displaying all subscribed communities that share the same name (that'd be the easiest to implement).

I am currently in the process of reading through the contributor documentation and trying to understand the code of lemmy-ui. As soon as I feel like I'm ready (hopefully next week, IRL obligations and work also eating time) I'll have a bash at trying to implement it for my first pull request.

[dessalines]

I'll reopen, but note that we won't have time to work on this. PRs welcome.

[Nutomic]

Seems like this is mostly a frontend issue then.

[db0]

I want to add my voice that this would be a good idea. I would like a way to acces /f/piracy and see content from both lemmy.ml and lemmy.fmhy.ml for example. The main reason I think this is very beneficial is high-availability. With the expected influx of reddit users on the 12th, it's expected many instances will buckle. By having a federated community as the main stop, discussions can smoothly fail-over to other instances with minimal disruption.

There is a problem of course that as you said, not every topic fits into this. So instead of a boolean true/false on whether to federate a community, I suggest a string where you specify in which federated community a specific community wants to join. So this way I can join lemmy.ml/c/piracy as well as lemmy.fmhy.ml/c/piracy2, say due to a community split due to ideological differences somehow.

[Barbariandude]

Ah, if that's the way people see this issue (as multireddits, basically) then it really is a dupe of LemmyNet/Lemmy#818.

[Visne]

I don't see it that way. My view is that just like how the home page has "Subscribed/Local/All" buttons, individual communities should have "Local/All" buttons. That way, I can view for example /c/memes and only see posts on this instance, and then when I click on "All" I will see all posts on all instances in their /c/memes communities as well.

This way, I can sign up on a small instance, post some posts on /c/memes, and then everyone (that is interested, thus clicking the "All" button) can see my post and interact with it. At the same time, I can press the "All" button and see posts from lemmy.ml/c/memes and others easily on my own instance. Now if lemmy.ml goes down because suddenly a ton of Redditors sign up, I can still click the "All" button and I can still find other users posting memes, on other instances.

Obviously people won't be making new accounts because of a little downtime, but if in the future a large instance goes down permanently, transfer of communities is almost transparent: it doesn't matter where people sign up, as long as they are using a community by the same name on some instance, they can still have a shared federated community. This is much better in my opinion than having to all decide on where to move, which is especially difficult if the old community is already gone. This way instances aren't just decentralized, entire communities are.

There is the problem of name collisions (think if r/discord and r/discordapp), but I don't think those will be major problems (it doesn't seem to be too big of a problem on Reddit, I can't think of another one besides the Discord one myself). It should still be possible for users to exclude a specific instances' community from the "All" page, just to clean up the results. Perhaps community moderators could also be giving the option to exclude a specific intances' community from the "All" page, but obviously that would only affect users on that specific instance.

[ashwebcode]

I really like the idea and @Visne's thoughts on how it would work. There could also be defaults set per instance with user option if someone wants to only view local. This could also help with decentralization. Instances with few users are at a big disadvantage at the moment. Yes, you can follow other instances but to new users it looks like ghost towns without seeing the federated activity. If users saw federated activity without having to manually search out and follow, it would be a positive for all instances.

[Bardak]

This is idea I worthwhile to investigate but I see two issue with the proposal.

1. Community names on seperate instances may not be be about the same topic. A major space I can see this being an issue is with communities for cities. Imagine all the different c/Richmond there could be.
2. News oriented community could end up with a unusable feed of redundant posts. Imagine what c/gaming would look like after a press conference with hundreds of duplicate for multiple stories.

[Black616Angel]

Why not make a new type of link?
How about e.g.: lemmy.ml/g/programming
Now you can choose to either go to you local community or enter the grouped programming communities of all federated instances.

This would of course not solve the reposts, but to be fair, Reddit also never solved that! 😉

In this way people would probably use groups and communities where they apply best and then reposts will most likely go down as well.

[krestenlaust]

There's the issue of duplicates, because not everyone would be using this 'view' and probably x-post.

Another issue would be abuse. People creating an instance and creating identical comms simply to end up in unsuspecting lemmings' feed

[jflix89]

I think all of the same !communities should be grouped together under /g/, with both the instance admin and user having the ability to filter/block out the ones they don't want to form their /g/community

[ghost]

I believe that instead of relying on community names, a more practical approach would be to provide users with a readily available list that they can easily copy and paste to access all communities related to a particular topic. To address the issue of duplicate news, a potential solution could involve grouping comments under the post with the highest number of votes among those sharing the same URL, while hiding the rest of the duplicate posts. However, it is important to acknowledge that some duplicates may still persist, and users would have to learn to cope with it.

[Black616Angel]

@JediMaster25 :

I believe that instead of relying on community names, a more practical approach would be to provide users with a readily available list that they can easily copy and paste to access all communities related to a particular topic.

A copy-able list is out of date the moment it gets published. So an updatable+moderatable link would be better. /g/ with @jflix89 s additions seems the best in that regard.

To address the issue of duplicate news, a potential solution could involve grouping comments under the post with the highest number of votes among those sharing the same URL, while hiding the rest of the duplicate posts.

The possibility of hiding posts leads to abuse and mistrust.

However, it is important to acknowledge that some duplicates may still persist, and users would have to learn to cope with it.

That is true. There will always be cross- and reposts no matter what.

And @krestenlaust :

There's the issue of duplicates, because not everyone would be using this 'view' and probably x-post.

If the groups become more popular and established, fewer people will not use them.

Another issue would be abuse. People creating an instance and creating identical comms simply to end up in unsuspecting lemmings' feed

The issue with creating instances is a good point especially for small communities. So moderation will be key here as well.

[MrScottyTay]

I don't think an automatic process would be best. It should just work in the way that a community should be able to link up with another community to show the others posts within us own community. Whether this be a two way link or one way works, the latter being the easiest to implement since you won't have to have direct consent from the other side to do so. This way it can be set up to be like an "auto" cross post but not automatic in a way that it can't be directly moderated and whatnot.

[sunaurus]

In my view, implementing this feature would be a UX downgrade for Lemmy, for the following reasons:

• Just the existence of such a feature will encourage people to create duplicate communities, without even trying to team up and build a single community
• It will become much more difficult for users to understand how one of these "combined" communities is being moderated and what the rules are for reporting posts
• Most importantly, Reddit has already proven that the root issue is actually a non-issue. Nothing is stopping users from creating multiple subreddits for the exact same purpose, yet there is no need for an automatic subreddit combination feature on Reddit, so it seems clear to me that it wouldn't be necessary on Lemmy either.

Please don't take this comment as an attack on the proponents of this idea, I am just trying to present my arguments for what I believe is best for the UX.

[randomletters]

I think this feature could be very positive if implemented well.

I am new to Lemmy and have struggled to fully understand the nuances of communities. My first instinct was to look for equivalents of my reddit subscriptions, Technology and Science being two examples. Beehaw.org and Lemmy.ml both have versions of these communities. I decided to subscribe to both communities on each server, which seems to be working fine, but I have noticed people posting the same articles on both.

If I understand the fediverse correctly, and specifically lemmy, people are encouraged to interact across servers, so there should be no need to cross-post, but this requires everyone to find and subscribe to every instance of a topic/community. Additionally, if someone wants to focus on a topic/community, they have to switch between each server.

In order to maintain distributed control and redundancy, I understand the need to allow multiple servers/moderators to control their communities and allow duplicates. I understand that some communities with the same name may not actually be equivalents. I still think this idea is a great one.

How I see it functioning:

• By default, subscribing to "Technology" would subscribe to all federated "Technology" communities
• Subscribing to "Technology@beehaw.org" would subscribe to just that community
• By default, creating a community would opt in to being a part of all federated communities of the same name
• Moderators could override this functionality for their community by whitelisting and or blacklisting other communities, effectively saying that their community is distinct or incompatible.

Addressing some of the problems mentioned by other commenters:

• Encourage people to create duplicate communities, discourage single community: I think this is already the intended nature of the fediverse, and definitely the reality (Technology for example). Recognizing that different servers/communities have different moderators is healthy, but encouraging users to be exclusive to one community is unhealthy.
• Difficult for users to understand how communities are being moderated and what the rules are for reporting posts: This is already an issue. If I am subscribed to Technology on two servers, which one should I post to? Each community must have a clear policy that is easy to access. When posting to a community a user will need to decide which server/community to post to. If moderation rules differ vastly, then the moderators should opt out of the grouping or users will just post to the community that suits their needs. This is a healthy way of taking some but not all power away from moderators, and allow for communities to separate and potentially rejoin over time.
• Not everyone would be using this 'view' and probably x-post: This is already a problem. Defaulting to a joined feed would help alleviate this more than ignoring it.
• Community names on separate instances may not be be about the same topic: Allowing whitelist or blacklist per community would solve this issue. Additionally, naming your community "News" when it is really "Richmond Virginia News" should be discouraged and this feature would naturally encourage community names to be more accurate.
• News oriented communities could end up with an unusable feed of redundant posts: Sorting by "New" would show redundant posts, but if the first post received all the upvotes it would theoretically "win" over the dupes in "Hot, Active, Most Comments".

[Visne]

@randomletters I fully agree with your comments and solutions. Additionally I think it should still be possible to only view local posts, but federated posts should be default like you said.

[jamon]

LemmyNet/lemmy#3071 (comment) is a very elegant solution. It allows many features with one change and it doesn't suffer the consequence of encouraging making small duplicate communities.

Benefits:

• Gives users a way to create logical groupings of communities--even with different names. For example, I could create an "AI" community that just follows a bunch of other communities like ChatGPT, stable-diffusion, etc. Ideally, I could even block posting to the community directly (and a good interface would let you choose to post to a specific upstream community instead).
• Supports creating more curated upstream communities that potentially have more restrictive rules, but with looser rules, allowing memes or pictures but also benefiting from the upstream content without resulting in duplicate posts.
• Allows truly "peer" communities to choose to follow eachother where that makes sense. Again, UI should allow you to choose to post to the community you're subbed to, or opt to post to an upstream community instead, directly.
• Doesn't encourage creating parasitic communities, as they would have their own distinct subscriber count/post count, which would cause them to be less prominent, less likely to be followed--unless they're adding something of real value (like creating a useful meta-community)--and even in those cases, having ease of "post-to-upstream" options encourage users to post directly to the community that gets them the most visibility, thereby discouraging unnecessary duplication, while encouraging value-add following.

As a side-note, a bot could already duplicate and repost/clone a community, so adding this as a core feature would make it significantly less intrusive if users do try to create duplicate communities unnecessarily.

As one final bonus--I think this could be 100% implemented as UI without changing underlying federation models.
(since they'd have few subscribers/posts directly to them, they would likely not be found/subbed by new users over the more prominent community).

[randomletters]

I have been thinking about my proposal and realizing that it has some flaws. In order to demonstrate them I have to show some fictional examples.

Topic Instances (Communities)

humor@a, humor@b, humor@c
funny@a, funny@b, funny@c

Users

u@a, u@b, u@c

Moderator Settings

humor@a whitelists humor@b
humor@b blacklists humor@c

Logical Behavior

Users inherit the whitelist or blacklist of their server. If no topic instance exists on their server it is the same as a topic with no whitelist or blacklist.

Subscribes to “humor” and Sees
u@a: humor@a, humor@b
u@b: humor@a, humor@b
u@c: humor@a, humor@b, humor@c

I will detail below my thoughts on why this is not great. The second scenario makes things even clearer.

Moderator Settings

humor@a whitelists humor@b
humor@b blacklists humor@c
funny@a whitelists humor@a
funny@b whitelists humor@a

Logical Behavior

Topics on the same server with conflicting settings are resolved by topic priority.

Subscribes to “humor” and Sees

• u@a: humor@a, humor@b
• u@b: humor@a, humor@b, funny@b
• u@c: humor@a, humor@b, humor@c

Subscribes to “funny” and Sees

• u@a: funny@a, humor@a
• u@b: funny@b, humor@a
• u@c: funny@a, funny@b, funny@c

Outlined below are the issues I have with several possible implementations:

Manual Subscription (Current Behavior)

• Users must discover other servers and subscribe.
• Cross-posts are not discouraged by default.
• A user “multi-lemmy” would not prevent the above issues.

User’s Server’s Moderators Determine Grouping (Previous Proposal)

• Takes agency away from the user and gives it to the user’s server’s moderators which the user may not agree with.
• The resulting groupings are different depending on which server the user is from with no intuitive way to know why.

Majority Rules

• This grouping would be determined by the topic instance with the most users, posts, or activity.
• Takes agency away from the user and gives it to the moderators of an arbitrary server.
• Would encourage gaming via spam users or posts to gain majority power.
• Gives moderators de facto power over other servers.

Consensus

• The grouping is determined by whitelists and blacklists that agree with each other.
• Whitelist and blacklist become useless because once one group differs then there are multiple groupings and no logical primary.
• Takes agency away from the user and gives it to the moderators.

No Whitelists or Blacklists

• There are no moderator controlled groupings.
• All instances are grouped.
• The user is vulnerable to bad moderation and spam instances.

Below is my new proposal based on further thought about real world scenarios.

User Controlled Blacklist

• Subscribing to a topic would automatically group all topic instances from other servers that are federated with the user’s server.
• Moderators would not be able to whitelist or blacklist other instances.
• Similar but not identical communities would not group together.
• Users would be required to moderate their topics by blacklisting bad instances on servers federated with theirs, possibly even their own server instance.
• Spam server creation could bypass moderation. This might be a high barrier to entry and server federation policies might mitigate it.
• This would create a 3 tiered system of moderation.
  -- Server admins would not federate with bad servers (assuming this is already a feature).
  -- Topic moderators would filter bad users and posts.
  -- Users would filter topic instances with bad moderation.
• This should put the least burden on users since they are at the bottom of the filter.
• Users could instead choose to subscribe to just a specific instance to avoid self moderation.

[jamon]

I think I was confused about your original proposal, as I can see from your explanation that it works differently than I had understood--so I'll re-state my opinion as my own separate proposal.

In my proposal, a user does not subscribe to "funny" or "humor", they still have to explicitly subscribe to a community@instance. Because of this, there's no arbitration of rules to deal with.

"multireddits" are accomplished by communities choosing to follow/subscribe to other communities.

if user1@a views funny@a, they will see all posts that are directly made to funny@a, as well as any posts that are made to communities that funny@a follows. This can be merged at the UI tier.

If user1@a views funny@a, which does not follow any other instances - they see only posts on funny@a.

If however, user2@a views funny@b, which follows funny@a and humor@c - the user sees posts from all 3 of those communities.

If "c" is blacklisted from a at an instance level, user1 will only see posts from funny@b and funny@a, and not humor@c, because its posts are not available to that user from their home instance. A indicator an accompanying message could inform the user that they're viewing a community which follows communities that are not viewable by them.

In my example, moderators for communities are only able to moderate posts that are made directly to their community, not ones that are posted to other communities, but they are in control of whether or not to follow those communities, so they've opted-in to that situation by following those communities.

Users who post to a community that follows other communities are offered the choice of whether to post directly to the community they're following, or to one of the communities that are followed by that community. They need not post multiple times, because posting to a more 'upstream' community would cause it to be seen by users of that community as well.

This has the extra advantage of individual users being able to create a community for the sole purpose of aggregating other communities that are related together--and that user can even share that community. For example, there are a ton of 'embedded programming' communities... I'd love to be able to follow a "multireddit" of all of those and let someone else manage that list--and if I ever didn't like which communities they followed, I could create my own multireddit or follow a different one.

There's simply no reason reason to automatically merge communities of the same name on different instances. Those communities can resolve that on their own by following eachother, or one following the other depending on their own preferences--and if neither are willing to do that, but they should be merged, the user (or any user) can just create a community that wraps the two of those.

This proposal avoids basically all the drawbacks of the proposals above--it doesn't create extra opportunity for spam, it doesn't have unintuitive moderation rules, etc. And it's a significantly simpler solution to implement.

Visual Example:

[tmarkov]

The idea of communities following each other is a great solution to allow users to automatically get content from new communities on the topic without having to manually search them.

However, I'd say there still needs to be an ability to merge communities on the user level, because I might want to see together the posts from communities with different moderation practices (that don't follow each other). But I think this can be a secondary mechanism - and fully manual with the user explicitly selecting the communities to merge.

[MrScottyTay]

The idea of communities following each other is a great solution to allow users to automatically get content from new communities on the topic without having to manually search them.

However, I'd say there still needs to be an ability to merge communities on the user level, because I might want to see together the posts from communities with different moderation practices (that don't follow each other). But I think this can be a secondary mechanism - and fully manual with the user explicitly selecting the communities to merge.

Why would the user driven version be any different (use case wise) from just subscribing to different similar communities and having them pop up in the subscribed feed?

[tmarkov]

Why would the user driven version be any different (use case wise) from just subscribing to different similar communities and having them pop up in the subscribed feed?

It matters for people who don't stay on the subscribed feed, but prefer to directly browse communities or topics.

[cutecycle]

The idea of communities following each other is a great solution to allow users to automatically get content from new communities on the topic without having to manually search them.

However, I'd say there still needs to be an ability to merge communities on the user level, because I might want to see together the posts from communities with different moderation practices (that don't follow each other). But I think this can be a secondary mechanism - and fully manual with the user explicitly selecting the communities to merge.

Why would the user driven version be any different (use case wise) from just subscribing to different similar communities and having them pop up in the subscribed feed?

multiple separate feeds from the subscribed feed can be useful (i.e. a personal feed of all cooking communities vs a personal feed of all programing communities)

[samuk]

@jamon I mentioned your proposal in the Kbin issue queue and Matrix channel. There seems to be some interest in your approach there.

I don't know if anyone is up for actually coding it yet.

Is anyone able to expand on the Jamon approach, but with some more detail on the actual Activitypub implementation.

https://codeberg.org/Kbin/kbin-core/issues/65#issuecomment-991826

[erlend-sh]

@jamon could you please repost your proposal as a new issue? I think it’s by far the easiest solution to what most people want here, but your idea goes largely unnoticed because it’s buried deep in these long comment threads.

Yet another proposal in the same spirit came up recently, but ‘Communities following other communities’ remains the superior solution.

https://sh.itjust.works/post/3508135

@busygent also seems to have independently come up with the same idea, but it solves a different problem than the user-specific community groupings topic it was brought up in. All the more reason to reboot the concept of C-to-C following as a standalone issue.

[shodanx2]

The lack of this automatic feature means the whole of the lemmy community on certain topics never comes together as a coherent hole.

Except in the case where there is ONE BIG community, which of course everyone goes to and all other communities languish in obscurity.

This is a terrible state of affairs which re-creates reddit-like centralization.

This creates the "ONE BIG" community on the "ONE BIG" instances and nullifies all benefits of being on the fediverse.

In my opinion is the most pressing problem and the biggest flaw of the lemmyverse.