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.
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.
join a meme sub
get joined to 15 meme subs
every meme is posted 15 times
surprised pikachu face
15 surprised pikachu faces
ftfy
I like this idea, however it would need to be intuitive to use and clearly advertised as a feature with a plain explanation up front. I say this because I’d never heard of this feature before and I used reddit for over 15 years (had to Google how it worked after seeing your comment).
Yes, users need ofc explanations, but that can be easily done, as much as people here are trying their best now to explain people the fediverse, that is quite more difficult to grasp IMO than a multi-reddit feature.
I like this idea better, also it shouldn’t be as hard to implement?
I am in this picture and I don’t like it. Lmao I literally had a multi-reddit called Linux.
Exactly. Just because I join a US politics sub doesn’t mean I want to join all US politics subs. The fact they are separate means I can find one that fits me. If this was reddit, joining /r/moderatepolitics would automatically sub you to /r/politics. Fuck that.
How about a mod option to voluntarity merge another community into their community?
This would be great
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.
Indeed - what you describe is why I’m really not worried about fragmentation. Federation means you’ll be able to see all of the relevant communities, and you can decide to subscribe to any or all of them.
In a community with 5m+ members, everything moved too fast
If people are satisfied with them, I think that’s OK, and more efficient than having a zillion.
Problems will happen if we go too low, and bigger instances start de-federating. Some might be tempted to start monetizing like Reddit.
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.
The example of federation most people have experience with is email. There will almost certainly be gmails and yahoos emerging over time, but they will have limited control compared to reddit, because if you don’t like the filtering/advertizing/whatever of one you’re free to leave for another
The email analogy breaks down when you consider that most email servers are run by big tech and cost a lot of money to upkeep
Or you can run your own email server for yourself and a few of your family.
There’s almost nothing in between gmail and some random person’s self hosted email server.
In terms of the fediverse,who the heck is willing to host a lemmy server for 1 million complete strangers? Not many people i think
If Lemmy takes off I wouldn’t be at all surprised if tech companies hosted instances that they monetize through advertising, and many people would be willing to have a home instance that showed them ads in exchange for high stability and potentially more user-friendly clients
They’d still have to release the source for their modded versions with ads, thus, ads can be mitigated from the instance client/app side.
Not necessarily, there are several ways they could release a proprietary app: either code it from scratch so they own the copyright, use OSS code that has a commercial-friendly license (eg. MIT), use an OSS library that allows them to link with their proprietary code (eg. LGPL).
But even if they did release the source code, I think they could still be profitable. Their main customers would be people who want something that “just works”, and a lot of those people would rather see a few ads than deal with downloading a modified version of the official client. People who hate ads and are willing to tinker are more likely to run their own insurance, IMO.
They’d still have to use the Lemmy API, thus, recognizing ads and/or reversing code should be fairly easy (when you actually know how everything communicates).
Just as a side note (am kinda curious to be honest) I always ran the official Reddit app (don’t mod anything, so… didn’t see the point in using 3rd party apps) and I never EVER saw a single ad in the app. Maybe it’s because I don’t live in the US, IDK, but would like to hear an explanation as to why ads weren’t served on my client… not that it bothered me, lol 😂.
Yeah, but we are social animals. Everyone* want’s to join the big group!
The goal of implementing this feature is to leverage the benefits of federation. If we wait until there is only a few big communities, the purpose of having federation becomes irrelevant. When an instance hosting one of those large communities shuts down, the community would have to migrate to the next major community.
By proactively implementing this feature, Lemmy can harness the advantages of federation while actively mitigating the challenges posed by community fragmentation and echo chambers. It provides a centralized hub that encourages cross-pollination of ideas, fosters community engagement, and ensures that valuable content is accessible to all users, regardless of the size or popularity of individual communities.
I disagree on two points:
- Fragmentation is a feature, not a bug. Echo chambers will always exist, but fragmentation is what keeps them contained to small pockets.
- A centralized hub would not necessarily foster community engagement. Seeing hundreds of comments on a post is often enough of a barrier.
see I’m not sure I see that as a problem. There are lots of reasons to spawn a new but similar community (bad community mods, bad server admins). There are lots of subreddits I avoided because they were just too big to get into any real info or discussion, just the same beginner questions asked over and over again.
The proposal does not necessarily imply merging all small communities with others. The implementation can provide an optional choice to community moderators, allowing them to decide whether they want their community to be included in the multireddit. This approach respects the autonomy of individual communities and acknowledges the reasons why new but similar communities may emerge, such as issues with community mods or server admins. By offering this flexibility, the feature can cater to the diverse needs and preferences of different communities while still providing the benefits of consolidating posts from communities with similar topics.
Who would control the multi-community, and how could a potential bad actor/community be dealt with?
I don’t think it’ll ever be perfect either. The setup Lemmy has just means it’ll be more resilient to breaking down entirely because there’s no single point of failure. So yeah hopefully it stabilizes more over time.
deleted by creator
From what I understand: Yes, because the users commenting could easily be from different instances
I agree. Time will show which instance most people will go to. The smaller instances will slowly quiet down, while the larger ones will gain in popularity. The issue will definitely sort itself out over time. I’m not worried at all.
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?
That’s how multi-reddit works, totally client-side, much better IMO than “forcing” the choice upon everyone at admin level.
Agree - Mastodon has lists, would like this too for Lemmy (even though I’ve not used them so far)
Why don’t you read the issue? It’s in lemmy-ui, so it’s clearly client-side. So just because you want to waste your time going through hundreds of instances to find similar communities, do we have to force everyone else to do the same?
Oh woah, dial it back, friend
Maybe don’t take disagreement so personally?
I too would like to do this myself and not have AI or anyone else decide for me what content gets lumped together.
I predict that this is also an issue that will slowly resolve itself over time, as critical masses of users gradually coalesce around one community, or more…but only if the extras are distinct in some way…which would very specifically be made more difficult by the sort of programming you’re proposing.
I’m not saying there’s no merit in your suggestion, only that it may not be the one-size-fits-all solution that you seem to think it is
Not taking it personally.
I would also appreciate the ability to customize, but it would be helpful to begin with a curated list of instances for each topic.
But who gets to curate that? How who has to sift through all of the 8000 instances and figures out the topic of each of likely thiusands of communities?
Automated sounds as though it’s purely based off of the community name? How does it figure out the difference between table top gaming or video gaming or even slots/gambling?
What about football? American or the rest of the world?
What about politics? Is it left wing or right wing?
Seems like a cool idea at first, but when you get into the weeds it becomes a pretty complicated issue.
OptimusPrime is a Deception here, apparently.
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.”
reddit also had that a bunch of places, for example /r/gaming /r/games /r/truegaming etc. etc.
I feel as others had suggested that client side multi
redditscommunities would be ideal so you could set up what groups you like to peruse yourself.I prefer sublemmys and multilemmys
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’m honestly more confused than I was before. With so many opinions, I don’t know how this could ever be implemented in a way that satisfies people.
It’ll be solved the same way anything gets solved in open source: those that can code make the final decisions.
Give me the few years I need to grasp how Rust actually works lmao
Open-source? More like open head from the SKULL SPLITTING HEADACHE!
Instructions unclear: do i put in the skeletons mouth or not
Thanks for the article. I really like the overall message about maintainers setting strong boundaries and being able to walk away.
I love open source. And it is so sad when good projects hit snags because of a toxic user-maintainer relationship.
“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 also started to learn rust for the same reason.
“Just go learn Rust”
Yeah that applies to a handful of people.
For what it’s worth, I’m VERY much for this.
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.
I am working on a multi lemmy manager that Id love to get some alpha testers to.
I don’t really know what that would entail but I might be interested.
As a web fronted, or mobile app?
I’m using jerboa (android app) and would find an equivalent of reddit’s ‘multi’ system useful. I’d likely switch to an app that provided that. I wonder if it could be implemented solely within an app, or if it would need backend support from lemmy.
I’m interested to test it!
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.
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 recently suggested @global for consolidated communities. There would have to be some kind of consensus on who and how communities would consolidate. I agree that having that does not get rid of all the other permutations.
I’d say just let the cross-federated communities redirect to each other.
deleted by creator
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.
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!
My instance is @lemmy.world, so this community/post is “local” to my instance, but in practice that’s not super important.
I think that’s generally true, however it’s worth noting that what you can see from other (non-local) instances is dependent on the admin of your instance. They choose with other instances to federate (exchange data, e.g. communities, posts, comments, etc) with. If they choose not to federate with a specific instance, you won’t see content from that instance.
There are already examples of this, but I don’t know the details well enough to be confident in expanding on it.
Excellent point!
And as if to illustrate my point, Beehaw is no longer federated with Lemmy.world, so @mountainmycelium@beehaw.org won’t be getting updates to this thread any more.
Yeah I just read that news and thought of this comment trail! My description did not age well.
Hopefully this is just due to sudden and rapid uptake of users to the fediverse and not something that happens regular once things have settled down a little.
Yeah, it’s not immediately obvious what the implications of an account on a particular instance are. I think over time it should become more obvious, for example meta data about instances on lemmy instance directory sites, so users know what they’re signing up for. I also think things will settle down as communities find an instance that works for them, and tools improve for more granular control over federation.
What do you need to know? (As I was typing this g0nz0li0 posted a reply, I’ll try to mention different things)
At a low level it’s not too bad, if you’ve gotten this far I think you’ve gotten through the worst of it. Things get a bit messy when you follow a link or leave your instance though. (Link replacement seems to be the #1 complaint and is extremely easy to fix though. I’d expect it to come quickly)
But for the most part just browsing the various front page at Beehaw should do you. If you’re interested in communities going to https://beehaw.org/search and changing it to all will help you find them. Just be wary because they open links that aren’t made for Beehaw lol. But you can hit subscribe there and then see them under communities > Subscribed and your front page will populate with them if you goto beehaw’s front page (Beehaw.org) and click subscribed instead of local or all. (Which local is communities that were made ON beehaw but anyone can see those if they search for them, and All is posts from every server on the fediverse. So they could be from anything (NSFW seems to be going crazy right now so that’s most of my all feed)) There’s also a bug right now that new posts get added to the top so the front page experience is a bit frustrating right now.
I like your username and profile pic. Were you an r/unclebens enthusiast by chance?
Hopefully those guides get moved over to Lemmy. I’m in Colorado where we just legalized psychedelics so I’ve been curious about trying to grow.
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 think conflicts can arise with hashtags just as easily as with community names, so it might be better to have an updatable and moderatable link instead.
Can you explain how conflicts can arrive with hashtags? I thought the whole idea is that they just let you tag content with its topics
Oh, I thought it was about tagging the communities and merging them based on those tags. Are you suggesting tagging the posts instead, and displaying all posts tagged the same from all communities across all federated instances in the same location?
But this can already be accomplished with the search feature. You only need to select ‘Local’ or ‘All’ and search for a word. People shouldn’t be forced to hashtag every post, so the result would be the same as it is now.
It could be done at the community or post level. I think because of the Mastodon backend Lemmy already supports hashtagging posts. But yeah my idea is that tagging communities would make it easy to merge communities with similar scopes
There could be conflicts between hashtags, as a hashtag for one community may not have the same meaning for another community. This would result in mixing topics and potential confusion.
I suppose that’s possible, but I don’t really view it as a serious problem that sometimes words overlap.
But one thing to consider is how divided it would be. Let’s say I wanted to browse martial arts so I go to #martialarts. Now what about people adding stuff like #MMA or #karate. None of these would show up in #martialarts. Seems like hashtags would be even more divided than communities to me
I would definitely consider that a serious potential issue, if for no other reason than so many communities will likely find a use for tags based on the nature of the community structure.
For example, I could see a ton of communities having tags for things like modposts, new member intros, meta topics, memes, questions, reviews, how-to’s/tutorials, guides, etc. and that’s just for broad post types that would apply to thousands of communities.
I think letting users manually make their own multi-lems, perhaps with the ability for communities to sort of team up to make uber-lems of closely related communities to help users discover more of them…but sub, unsub, multi, and un-multi as they see fit…is likely the best approach.
Yeah hashtag congregation would be provlematic. It should just be a many to many table, each community should be able to add another community to have their posts shown and vice versa
The hashtags could be very useful for finding communities you might be interested in though.
Cross-instance “multireddits”, that are also automatic and topic-based. #1113
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.
I think what I’d prefer is a more supported version of Reddit crossposting… I’m brand new so stop me if Lemmy already does something like this. For example, if someone has a vegetarian recipe community, a more general vegetarian community might automate a feature to crosspost their content, with clear linkage to the source… But a new discussion thread as the default in the crossposting community.
This allows the different related communities to choose their own moderation and regulation, but can also allow communities to be content aggregators.
I can definitely see name-collisions being an issue, where communities on different instances have the same community “ID”, but aren’t actually about the same thing. I’m still overall in favor of the basic idea though.
