Over the past few days, I've witnessed a remarkable surge in the number of communities on browse.feddit.de. What started with 2k communities quickly grew to 4k, and now it has reached an astonishing 8k. While this exponential growth signifies a thriving platform, it also brings forth challenges such as increased fragmentation and the emergence of echo chambers. To tackle these issues, I propose the implementation of a Cross-Instance Automatic Multireddit feature within Lemmy. This feature aims to consolidate posts from communities with similar topics across all federated instances into a centralized location. By doing so, we can mitigate community fragmentation, counter the formation of echo chambers, and ultimately foster stronger community engagement. I welcome any insights or recommendations regarding the optimal implementation of this feature to ensure its effectiveness and success.
The underlying problem here is the lemmy community being spread out across many instances, and this solution doesn't really fix the underlying problem.
This is just speculation, but I think eventually 1-4 instances will grow much bigger than the rest. I think when this happens, communities will become much less fragmented and the problem will solve itself.
tl;dr while this is a good idea, I think if we just leave everything the way it is the problem will solve itself.
I honestly wouldn't want that, a feature like multi-reddit would be much better IMO.
I personally don't want to be "automatically" subscribed to all tech communities for example just because I joined one, nor I want to be flood by an immense feed because all communities of the same type are put all together, that takes away individual choices IMO.
We had exactly the same problem on reddit, but multi-reddit solved that very well by leaving the choice to individuals instead of being forced by admins.
EDIT: for those who don't know, multi-reddit is a reddit feature that allows you to create different "labels" into which you can combine different subreddits, which label to create and which subs to combine is totally a user choice, those labels become "tabs" into your UI that you can use as they were individual subs.
So for example, I can create a label/tab called "linux" and use it to combine r/linux + r/linuxmx + r/xfce, etc., than I can create another label called "games" and combine r/MMORPG + r/wow + r/guildwars2, etc., and so on.
multi-reddits can be private, that is only the user who created them can see them, or they can be made public, so if some user doesn't want to create their own, they can use multis created by other people.
I tend to agree with your take on this. I'm getting serious FOMO over here and over-subscribing because I don't know which sub will be the one to "take off."
Why not make this purely client-side?
Give me the option to merge what I see as like-minded feeds into one feed. Label it and be able to scroll it as one feed. All without the need for admins or instances to do more work?
I don’t think I’m understanding this right cause it sounds like you’re trying to make it more fun by adding more rules. If there are 20 groups that are all about pickles that’s fine they each like running things their own way. Eventually one group gets popular and that’s where the majority goes. I think your frustration could better be solved with something like tags where groups could choose to associate certain tags words that makes search easier like tag: pickles-fermenting-homemade-cucumbers and that could clear up search from people just wanting to share pickle Rick memes.
I think you perfectly described my issues with comment sections on Reddit for the last few years. That attempt to appeal to an audience rather than further the discussion.
I used to love comment sections as much as, if not more than, the actual post on Reddit. It felt more like a conversation that had insight and humor. It got too big for it's britches and became that soulless monolith.
I get an almost nostalgic vibe from this place. It's nice.
I see very little discussion about the implications of this for moderation, and it feels to me like they get very sticky. With traditional human-curated multi-reddits, you as a subscriber must engage with the idea that you are choosing to aggregate multiple communities into a single feed, which is intuitive enough, the subscribed feed already works that way.
But by making it automatic, the software hides the fact that it's pulling together discrete feeds from communities with different rules and different moderators. This feels very awkward to me. I'm all in favor of traditional multi-reddits, which can be used to create this sort of feed for yourself. I'm still on the train of "duplicate communities will sort themselves out if community discovery is made much easier and popular communities reliably show up at the top community searches, mostly irrespective of what instance the search was performed on" (obviously defederation takes precedence here).
I think a community needs to add the option of a topic hashtag, so communities can group together in that way if they want to, and people can subscribe to these hashtags if they want to (with the ability to remove single instances of they want to)
The theme here is "if they want to" giving choice to both the communities and the subscribers
Damn, this is a lot of discussion and I don't see a single person actually volunteering to actually go code the feature. It's open source, you know? If anyone cares about the feature, go learn rust (like I'm trying to do now) and code it up.
EDIT: In case anyone reads this, please look at entitlement in open source. It's an eye-opening read for those not familiar with the headaches involved.
I like the general idea of merging communities, but I'm not sure if I like the idea of it being automatic. What if instead communities could apply "hashtags" for their community, and then you could efficiently browse multiple communities at once. For example, I'm subscribed to a few different TTRPG communities across a few different instances, but what if each of those communities was tagged "#ttrpg" and then I could browse #ttrpg instead of browsing any of those individual communities.
One of the pain points for those coming into this to fill the Reddit void is fragmentation. Beyond being a huge improvement in usability, information would be shared much more easily this way. For someone who spends a lot of time in IT/tech related subs, that’s very important to me.
TL;DR: The suggestion is to implement an automatic multireddit feature in Lemmy that displays all posts from communities with the same name across federated instances. It aims to promote decentralization, avoid echo chambers, and ensure high availability. Community moderators would have the option to opt-in or opt-out their communities from being displayed. There are discussions about potential issues such as community name collisions, duplicates, abuse, and practical implementation. Some propose using a new link format, while others suggest providing users with a list of related communities.
Whatever y'all decide, please just remember what McLuhan said: "The medium is the message." What's the message implicit in your decision? Be deliberate.
We need both options. Some systems like USENET use a global groups list (rec.radio.amateur.misc is the same group everywhere). Federated communities need a similar option.
Sure, let me create my own c/gaming if I want, but also give the option to… merge? combine? cross-federate? Not sure what term fits here.
!gaming@me, !gaming@you, and !gaming@them can be 3 separate, distinct, and independent communities (like it is today).
!gaming@me, !gaming@you, and !gaming@them could also be the same !gaming community, replicated and synced across all 3 servers.
Here’s an idea. Add another name to the community designation. So you could have !gaming#context@instance. (Or whatever separator makes sense. You could even just use a subdomain like !gaming@context.instance, but that might be harder).
In this model, #context refers to a shared view of the world that instances can choose to participate in. As the instance admin (or maybe a mod??), I choose to join #context1 but not #context2. When I do, All the !communities under #context1 become available for me. I still choose the ones that are appropriate for my instance. This would mean that when a new instance joins the federation, it acquires the shared set of #contexts that the federation publishes. A different federation of instances could still have different contexts.
(All of this still feels clunky. USENT’s simple hierarchy still makes so much sense, but it unfortunately places all the control at the group level, not the instance/user level.)
I would kill to just have some help/pointers figuring out how to navigate this... Fediverse?
I've made a couple posts, on one, maybe two, um, Instances? In the communities there?
I don't know. All this change is coming at like, the WORST time in my personal/professional life and learning a whole new world is just... Daunting. (waahhhhhh 😭)
I like multis and I think discoveribility is a bottleneck, but I'm very wary of this idea. If you merge communities together like this, you essentially multiply the users in that community. Moderation isn't 4 small instances anymore - it's one large one with 4 separate mod teams each handling a quarter of the posts
I think this is more likely to lead to polarization and eventually echo chambers than if you kept them separate - outrage drives engagement more than anything else, and explosive growth is a great way for a fraction of the group to dominate the first few pages of comments, which turns off moderate voices, which works like confirmation bias to make the outraged believe they're the prevailing voice of the community, which again drives them to post more incendiary comments, and the whole thing spirals
If you want to avoid echo chambers, the best way is to throw a small group together and make them get along through mods that are involved in the community
But then you'd probably end up with most members of one community slowly joining the rest, which is a healthier growth model, but still not great
My intuition is that the ideal solution involves encouraging users to join a single smaller group, but being exposed to top posts from sister groups to avoid fomo. Possibly through something like the way Reddit handled crossposts, where you get the post but not the comments, and a small link to the discussion in other communities. It could be automated if the post crossed a certain threshold of votes, keyed to a certain deviation above the daily average of the original group and optionally with a minimum up/down vote ratio.
This would help keep moderation ahead of participation, and hopefully build a tighter knit community - people are less willing to be jerks to people they recognize than strangers you get in a larger population. By encouraging users into one small random group instead of shopping around for the one that best fits their view, I think we could resist natural grouping by beliefs.
To go further, if this works we could consider a mechanism for "mitosis", a splitting of a group when the mod team feels the culture of the group is getting past their ability to manage in a nuanced way
The goal is decentralization after all, not distributed centralized groups
I don't see any problem. If the problem is the server admin is not able to moderate the communities, he can disable automatic community creation and define an approval process. He can also close dead communities, apoint moderators, merge proposals...
Hmm, I don't disagree with the fragmentation but that's the nature of any new social platform. It's also been proven out that eventually one or two communities for a topic will become the dominant one with the others falling into disuse.
Attempting to merge communities early or artificially will cause moderator strife as minor disagreements balloon. Especially in a multireddit community where no one mod(team) has absolute control.
I don't have a reason from a technical point of view, but from a social one. Forcing communities and instances together early will only cause strife. After a few years where two communities have a track record and proven 'behavior' would the multireddit not cause issue.
on one of my other accounts i am collecting communities that all have the same name across instances just so that whichever place people end up moving to for that is consistent with the others. having them all roll into one would be a massive amount less work and is pretty much absolutely ideal for what i'm trying to do.
there absolutely needs to be an opt-out or even an exclude feature tho. as someone pointed out, some instances are run by not very nice people (tm) and there are also regional-based instances like my native one the aussie zone. yeh sure it'd be great if all the "australia" communities were merged (or most of them at least) but 2nd or 3rd for size is the melbourne community, and there's also a melbourne in florida and people from neither one particularly enjoy being mistaken for the other. region-based communities need to be able to maintain their own exclusivity for community reasons, yeah? another community on the aussie zone is called "gigs" and it's not about rock concerts that happen in new york city if you get my drift. you have a great idea, but it needs to be optional, and easy to withdraw from if desired.
Sounds like something. I don’t know enough about the tech to provide a meaningful comment but I can see the problems you’ve mentioned and something doing these lines sounds like it could be a good solution.
The problem is not a technical nor architectural problem but a user/usability issue.
Look at the workflow how people create a new community. They are registered on one instance, probably fixed to that bubble and probably don’t interact with other instances at all (subscribing to other communities is a pain. Other problem.) They might (if at all) search for a similar community on their instance. If they don’t find one, they’ll create a new one. Searching every single community is not implemented in this flow. You need to call up feddits search to do so.
My suggestion: Either do a name (fuzzy) check when creating a community, listing the ones already existent on other instances. Or at least implement the search feature from feddit.