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.
Isn’t a few large communities eating up the others like the opposite of what Lemmy is trying to do?
i keep hearing people call for this like its going to happen and be the only way things will be. Look at reddit, look at the history of some of these subs.
there will always be multiple copies of various communities. what software gives us the ability to do is sort and filter and tag (we need to add this) to our hearts content so instance admins and users have control over what comes across thier feeds.
Joined communities will have many of the same centralization problems reddit has now. I’ve seen this call mostly from users who were on reddit long after it was large. It seems many have no idea that almost every topic on reddit has 4-6 subs around it usually.
I think it’s only a problem if it congregates to 1 instead of 4 or so. If one of the 4 goes rogue or disappointing its users, people can easily just jump on a different one. Most servers will suck and that’s ok. Good ones will attract users.
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.”
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 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’m new too, but here’s what I’ve learned in the last week:
You’re a user of and logged into @beehaw.org. This post (and the community it was posted to) exists on the @lemmy.world instance. You can see and post to it from your beehaw.org instance, because @lemmy.world also exists in the Fediverse.
My instance is @lemmy.world, so this community/post is “local” to my instance, but in practice that’s not super important. All that tells you is where I enter the fediverse, from there we’re able to see and post in communities from across instances. For example, I can see communities/posts from @beehaw.org, where you are. I am subbed to a few communities there.
It’s possible that a community like /c/games exists on @beehaw.org and on @lemmy.world. You would see them as games@beehaw.org and games@lemmy.world, and they are separate communities (despite having the same community name) so you can sub to one or both. OP is basically suggesting a feature to group (for example) games@beehaw.org and games@lemmy.world so that it just looks like one big community.
More experienced Lemmy and Fediversers, please correct any errors I may have made it this post!
I read on another post in a different community that some servers have neo-nazis running them? If that is the case, no thanks, I don’t want that.
Actual neo-nazis or people you disagree with?
How will this help the posters reach the fragmented communities? Will they just pray that everyone is using the the aggregator?
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.
Another day another “When will the thing not meant to be Reddit be Reddit” post
How about a mod option to voluntarity merge another community into their community?
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
Make it user specific. Feeds are combined solely from the individual user’s perspective. Consumption would be easier but submissions are still federated.
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 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.
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.
The thing is that say i want to see all the pickle content across the lemmy-verse, i want to just be able to subscribe to an umbrella “pickles” category and get all the c/pickles content from any instance my instance federates with without worrying that i missed a community or something. If there are 20 groups but i only know of 1 or 2, odds are that i’ll miss the biggest ones with a bunch of pickle content that i want. And I don’t want to have to manually go through, search for all the biggest instances, and subscribe to each pickle community one by one. Plus, say a new instance is started and it’s pickles community blows up. I’ll miss it because i already searched through and subscribed to all the pickles communities that were available when i joined. I’d rather default to subscribing to all the c/pickles communities my instance sees, and then if one instance is posting stuff i don’t want to see i could manually exclude them
Tldr I guess it depends what you think will take more effort to do manually. I think having to manually find and subscribe to every community i want from across the lemmyverse (and periodically run the search again to find new communities) would be way more work than subscribing to every c/pickles my instance can see and manually excluding the instances or instance-specific-communities i don’t want content from
Yes the fragmentation is a feature not a bug. There are dozens of reasons why people might want to leave a community and create their own alternative version. With blackjack and hookers.
Combining communities should be a front end feature… Allow users to merge their views if they want. But it should not be enforced at the backend or federation level.
Eventually there will be third party apps which can do this merging in their interface if someone wants it.
This seems like a devisive topic.
The fragmentation is not a feature to me, but something I view as detrimental.
Or just make it user-side. Let users create their own feed combinations. They’d still have to select a specific instance for posts.
Feeds would be consolidated but posts and comments will still be federated. And one user will be unaffected by how another user organizes their feed.
That seems like a good solution. Let me subscribe to a half dozen different game comms and put them together into one “games” list that shows up with pretty much the same interface as a single community, so I can browse just “games” content that I have subscribed to.
having subscribed to multiple games communities, the issue then becomes content duplication; the same trailer or article will get posted in three different communities, and I don’t actually want to see it three times in my feed. I’m not sure there’s a good way to solve that, though.
(I’m subscribed to multiple communities b/c I’m not sure which one will have the largest comments sections, and those are what I’m really interested in.)
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.
“An ounce of planning is worth a pound of cure.”
Nothing wrong with rushing into projects when you’re learning a new language, but on big OSS projects it’s a good idea to make sure you’re working on something that the maintainers are willing to merge. Getting community consensus is a good thing.
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’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”
Honestly, we’ve all seen this happen in every community that fragments for some reason. Whenever reddit banned a subreddit, 1,000 mini-subs would spawn, eventually coalescing into 1 or 2 main communities. Whenever a migration happens (Tumblrinos moving to reddit, redditors moving to various reddit-like things, forums moving to reddit, fark migrations, usenet, IRC, etc) they always fragment initially only to end up with a relatively few coalesced groups that hold similar ideas.
c/news might end up with 10,000 news subreddits (even one for each local newspaper!) but eventually it comes out to something like: c/news, c/leftnews c/rightnews c/ihateallnews with the most active (by far) being one of the generic ones. The others might technically exist, but if you search “news” and get one that has 10,000,000 subs and another that has… 3, well, you’re just not going to bother.
I think it would need to be voluntary; mods on different instances have to agree to be a joint mod group. If an instance decides to break up, they take their mods with them, etc. Might he complicated, but it seems doable.
If the mods were willing to agree to this, why would they not also agree to simply merge the communities? Frequently, when mods choose to maintain overlapping/competing communities/subs… it’s because there’s conflict about culture or moderation policies. This mechanism feels very duplicative of existing patterns, and limited in much the same ways when cooperation breaks down between mods of different communities.
There’s an advantage to splitting the load amongst multiple instances. If community@host1.com has issues, the subscribers to community can still access community@host2.com.
Further, preventing centralization is a core focus of the fediverse, with all the pros and cons that come with it. The reddit migration is a testament to that philosophy.
If an in-fight happens between two instances’ communities, host1 won’t be able to boot host2’s entire existence, just their agreement to be in sync. Voluntary syncing of communities seems to me a natural extension of the federated philosophy.
There’s an advantage to splitting the load amongst multiple instances.
I don’t have links handy, but the devs have said multiple times that federation replication load is not a limiting factor. It’s the browsing load that matters, which is already spread across the instances that subscribers hail from. There isn’t a performance issue here to fix, at least around the current network size.
If community@host1.com has issues, the subscribers to community can still access community@host2.com.
Again, user-account federation already provides this. If the host where the community resides is down, I can still read existing posts, and post and comment with users on my local instance. I don’t see significant further benefits in splitting the community hosting.
Voluntary syncing of communities seems to me a natural extension of the federated philosophy.
I don’t disagree with this, the challenge is that the federated philosphy makes everything it touches very complicated. A sprinkle of federation in the core of an ecosystem brings enormous resilience against the ecosystem getting coopted against the will of its users. A heaping spoonful of federation makes it an unusable mess. The complexity of federated design needs to bring very big benefits to “pull its weight” in complexity. The tradeoff looks positive for me for federated replication even though the cost in complexity is large, but I don’t for meta-communities. They seem like cosmetic improvements over the existing capabilities.
But fair enough, I see where you’re coming from. It’s not madness, on-balance it’s just not something I see providing value in proportion to its conceptual complexity.
If the host where the community resides is down, I can still read existing posts, and post and comment with users on my local instance.
Can you help me understand how that all works? I ran into this today where an instance wouldn’t let me submit due to performance issues, and I jumped instances to be able to provide some (potentially) important breaking news to “community.” If they were fully in-sync and one instance didn’t “own” the community, when things stabilized, my content would have replicated instead of being stranded on a lonely instance. As it stands, that content will never be part of the “real” community.
But fair enough, I see where you’re coming from. It’s not madness, on-balance it’s just not something I see providing value in proportion to its conceptual complexity.
Right on. I’m still new to the fediverse and am probably missing some foundational concepts still. Love where it’s headed though.
If the host where the community resides is down, I can still read existing posts, and post and comment with users on my local instance.
Can you help me understand how that all works?
I’ll preface this by saying I haven’t read the code and it’s certainly possible there are errors in my mental model, but my belief is:
- When the community-instance is up and it gets a post from a user local to the community… It write that data to its db and asynchronously sends federated messages to instances with users that sub the community. Those instances write it to their local DB.
- When the community-instance goes down and someone on a user-instence tries to read the post, it gets read from the local-db cached copy.
- While the community-instance is still down and user-a on a user-instance posts or comments, again it goes into the local DB and async sends a federation message to the community-instance… the message doesn’t immediately get through though.
- While the community-instance is down, if user-b on the same user-instance browses the community, they see user-a’s content from step 3 in the user-instances-db. If user-c on a different user-instance checks, they won’t see user-a’s content until the community-instance comes back up to process the federation messages from step 3.
- When the community-instance comes back up, it accepts the federation messages from step 3 and updates all subscribed instances so user-a’s content is viewable everywhere.
It’s possible I’m mistaken about 3-5, but if you had trouble posting… my guess would be that your own user-instance was struggling and slow. But if you’ve rules that out maybe the update behavior when the community-instance is down works differently than I think it does. The reading in step 2 I’m quite certain about though.
I’m pretty sure you can’t post to community-instance if they’re down/having issues to the local DB. The instance I’m on is very stable and every time I think it may be an issue, it turns out to be the other instance.
It sounds like a lot of the “sync” behavior I was thinking of is already built-in if we can just expand on it a bit.
