Hey everyone! After my first week of settling in here, I think what would give my lemmy experience the biggest boost of any single added feature would be Multilemmys (or Multicommunities), so we can see the combined feeds of multiple communities in a single streamlined feed. I guess the purpose of this post is to spread awareness of this as a concept and point to the ongoing discussion on Github:
Support for grouping communities / multi-communities #818
Cross-instance ‘multireddits’, that are also automatic and topic-based #1113
I have seen users post that this was how they initially thought the fediverse would work when it was explained to them. I thought this would be the case as well when I joined.
(Edit to add: an older post with discussion on this idea including devs’ thoughts at that time which shed light on why it does not work this way.)
Although I am new to this world, I feel this is one of the most intuitive abilities associated with the concept of the fediverse and that it MUST eventually be possible, the sooner the better.
This is similar to “multireddits”, and the equivalent way to use them would be to combine feeds from different communities that are on the same instance, so for example I have one multilemmy to combine the feeds from /c/politics, /c/news, /c/worldnews, /c/worldpolitics (all on lemmy.ml).
Then additionally with Lemmy we have equivalent communities hosted across various instances, and it would be a new and different kind of ability to be able to combine these into a single multilemmy, so for example I have a multilemmy combining lemmy.ml/c/politics, lemmy.world/c/politics, beehaw.org/c/politics, etc.
I found this idea mentioned a few times around lemmy, where @deadcyclo@lemmy.world and @communist@beehaw.org pointed out the above open github tickets for these ideas.
Those github discussions were a fascinating read for me! Its clear that the boffins have already put a fair amount of thought into these possibilities, and identified questions that will need to be answered such as
- how to deal with communities that have the same/different name but are or are not actually the same subject
- duplicate posts and/or cross posts
- whether to cause automatic/default links or not
- how to implement this in a way that is of most benefit to the health of the lemmy ecosystem
- there seem to be two separate use-cases also: one being communities intentionally linking to share content and the other being a user creating their own custom combinations, either for personal or public use.
- how to handle subscriptions
Discussion continues even this week! After reading through all the ideas, I don’t have any specific preference but I am excited to see what they eventually decide to implement as I’m sure it will be rewarding. Personally I think getting some cross-instance version of this should become a priority as soon as they feel they’ve adequately responded to the reddit migration, which I imagine would be a month or two down the road.
I gotta end by saying how happy I am to be here after leaving Reddit, this really feels like the start of something incredible. Cheers!
P.S. in the meantime, a user has created a FireFox addon that might be useful, I have not checked it out myself.
“Missing the MultiReddit experience? I built a Firefox Add On for that” - @Leraje https://lemmy.ml/post/1611805
Community Grouping #3071 is an issue I created and it’s specifically not related to multis. Its purpose is to allows mods to unite their distinct communities into a logical community.
Thanks for explaining, I like that approach too
Rereading my comment, it comes off a little brusque so I want to clarify a bit. I think user-defined multireddits are a good feature and could exist alongside my own proposal. Users having more control over their own feed is a good thing.
But my proposal has a different goal, which is to reduce duplication of links and keep conversation more centralized. It’s not a feature most users would even be aware of because it’s only manageable by community mods.
@0x1C3B00DA @syzizeky Without a pointer to the original comment, I believe this is exactly the feature I’m looking for, when I say that having {sub}@{every individual instance} will just dilute the conversation to well below useful/interesting levels.
The way I put it is I want a CNAME such that !foo@bar —> !foo@baz and you subscribe to the former if you’re on bar, and unless the CNAME is taken down because the !foo@baz folks go off the rails, they’re treated as identical. 1/2@0x1C3B00DA @syzizeky
Is this similar to what you’re talking about?
(Yeah, I’ll go look at your timeline in a moment to see if I can find the comment and the original thread.) 2/2@0x1C3B00DA @syzizeky If it was https://lemmy.ml/post/1146528 then I think we’re talking about the same thing from different directions. And really nearly anyone is more qualified to come up with valid suggestions towards the goal than I am… :)
I actually hadn’t fully read #3071 before now, but now I’m really in favor of it. I would describe it as cross-instance friendship, and I think its an elegant mix of centralized and distributed.
We should want to centralize the conversation by reducing the duplicate submissions so that we tend to comment on the same story in the same post, but I see it as a big negative if we encourage the conversation to always take place on the same one instance and discouraging the same community from popping up on multiple instances.
As db0, visne, and randomletters pointed out on GH issue #1113, it would be great if (as with your suggestion) the event of any individual instance vanishing would only lose us a part of the conversation (or none, with backups?), and anyone browsing would hardly notice the difference.
I agree also that with your idea the problem of duplicate posts would tend to take care of itself when users adapt to the cross-instance view.
As randomletters suggests here, having one community spread across multiple instances may be undesirable if it
- 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.
I think this is just a different way for mods to exercise the agency they already have over a board. I think mods are free to not make these links, and things will remain as they are on their boards, which is just fine. I think mods should choose whether to default their community to local or cross-instance. I also like that your proposal is totally compatible with the idea of user-created private or public multilemmys (#818), and if user multilemmys could still be created by subscribing to communities at the local scope that would preserve or restore the agency that randomletters is concerned about above? Seems right that user-created multilemmys come separately and later. (I think the unidirectional subscriptions such as described by jamon’s notes on #1113, are better suited for #818 and multilemmys, rather than #3071.)
Regarding intuitively conveying why/what groupings are different per instance, maybe we could make graphs or visual representations of the federated content? Maps of the links to visualize the differences between links? Pie charts?
Lastly, some notes I made regarding the post submission page, mostly unrelated to our discussion but I’m not on github.
- Lemmy does not check a submitted post’s url for matches, only the title.
- The rules of the community you intend to post to could be shown when you are preparing your post, maybe also the rules of the other linked communities in case you want to select based on that?
- If I am currently subbed to similar boards across many instances, its hard to tell which community is on which instance because the list of communities to select from lists their informal name, and they are all so similarly named.
