Support for grouping communities / multi-communities

[esjarc]

Reddit has a very useful feature called a "Multireddit" (more recently "custom feed"). A multireddit is a subreddit that combines different subreddits into one (and you can choose a name, a description and the visibility for the multireddit). This is very useful to divide all your subreddits into different topics, e. .g:

hardware: Subreddits about hardware (e. g. /r/googlepixel, /r/thinkpad, ...) software: Subreddits about software (e. g. /r/lemmy, /r/matrixdotorg, ...)

As these topics don't have much in common, it doesn't make sense to have them all mixed together in the home timeline and that's where something like multireddit would come in handy. Such a feature helps to prioritise and organise the Lemmy feed.

Even though this feature might not be needed at the moment, as Lemmy doesn't have a high post frequency yet, this will become more important in the future, once federation is implemented and more people start using Lemmy. Mastodon also has a similar, but quite restricted (limited to four hashtags only), feature called "hashtag timelines".

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/91770739-support-for-grouping-communities-multi-communities?utm_campaign=plugin&utm_content=tracker%2F126011972&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F126011972&utm_medium=issues&utm_source=github).

[dessalines]

From other closed post:

I'm up for suggestions on the best way to do community groupings. I think I'd prefer this be done as shareable urls like reddit: https://www.reddit.com/r/NoStupidQuestions+explainlikeimfive/ .

Then possibly your right sidebar, maybe above Subscribed communities, would list your saved multi-communities? And when viewing a multi-community, you could have the option to save that to your profile.

[esjarc]

I think this is a good idea in general.

But how would you deal with federation in that case? Someone might want to combine lemmy@lemmy.ml and admin@mylocalinstance.example.com.

My suggestion would be (if federation is actually possible to implement for this feature) to default to the local instance if no server name is given, e. g. lemmy.ml/c/chromium+firefox = lemmy.ml/c/chromium@lemmy.ml+firefox@lemmy.ml and to combine communities from different servers, if you include the server name, e. g. lemmy.ml/c/chromium+firefox@lemmy.mozilla.org = lemmy.ml/c/chromium@lemmy.ml+firefox@lemmy.mozilla.org

[Quadrubo]

Just dropping by to say this, especially with the influx of new people migrating from reddit, this would be a great feature. I personally just tried out lemmy and to me, there seems to be no particular reason of why there are 2 different programming communities, one on beehaw.org the other one on lemmy.ml. As Lemmy grows there will be more instances and more duplicate communities which would be nice to be able to combine into one.

[Visne]

@Quadrubo Check out LemmyNet/lemmy-ui#1113, I think you would find it interesting.

I think there's basically two ideas here:

1. User defined groups: basically combining communities I find interesting into a group, for example "software" which shows posts from both /c/opensource and /c/programming. I think that this is the idea of this issue.
2. Cross-instance/federated communities: when viewing a community on your instance, being able to press a button to see all posts from all communities with the same name on other instances. This way you could see posts on /c/programming on both lemmy.ml and beehaw.org, as well as all other instances, at the same time. I think this is the idea of LemmyNet/lemmy-ui#1113.

I think both ideas are good and both should be implemented, and I think there's some minor overlap: when viewing a group it should probably also be possible to view federated posts of all communities in your group, and when you are making a group it should probably be possible to include specific communities on other instances (like https://github.com/LemmyNet/lemmy/issues/818#issuecomment-838338454 proposes).

[ShadowJonathan]

From an API perspective, and specifically from Mlem, we'd likely want to see the ability to either arbitrarily "group" together multiple communities in a single pagination call, or be able to address a "multicommunity" natively via the app, and use it for such pagination.

Either approach would work for us, but a server-stored "multicommunity" would help with syncing data between apps, and the web UI, possibly.

[aodhan-domhnaill]

What if there was another notion like feddit.de/m/<name> which aggregated all communities with the same name,

• lemmy.ml/c/<name>
• lemmy.world/c/<name>
• feddit.de/c/<name>

[ShadowJonathan]

You may want to exclude specific communities if they come from problematic instances, so I'm not sure if that'll be the best

[LouisRomeas]

Another thing to consider which makes me skeptical of the naive solution of confederating all same-named instances together, is that if Lemmy instances are going to evolve – both in their naming and contents – similarly to subreddits, we might want to avoid situations like this ... in case one community on one specific instance uses the same name as others on other instances, albeit ironically or in a derivative way. Another example that comes to my mind being the inverted duo formed by r/trees and r/MarijuanaEnthusiasts. If such things were to happen in the Lemmy Fediverse, sorting out communities by their names only would mean a whole lot of incorrect matches (meaning having to hand-pick communities anyway in the end).

I would be more in favor of letting each community decide which "sub-federation(s)" to join – and each of these sub-federations deciding which communities they let in or not.

Although user-defined community grouping looks like a very interesting feature indeed, and I support it being added, I don't think this feature alone would be the most user-friendly way of dealing with this issue, from a UX perspective. It would mean that a new Lemmy user who just created their account would have to start all the grouping work by themselves; compared to a Lemmy-wide grouping which would've already been available and done for them as soon as they would join.

But again, I'm not against the user-defined groups for more customizability, I simply don't think it will be enough for a real user-friendly (and especially newcomer-friendly) experience.

[Visne]

Ideally instance admins could choose between a blacklist and whitelist model, so they can either choose to exclude specific communities from the larger federating community, or they can choose to hand pick what communities to add to the larger one.

I'm personally very much a fan of having the blacklist by default, in general I think communities by the same name will be essentially about the same topic on all instances. If you then get a r/AlzheimersGroup or r/trees situation it is trivial to exclude that community from the federating community. But it will still be easy for users to see everything on the fediverse about a specific topic, without instance admins having to hand pick all instances.

[dadino]

Auto grouping of similar communities should be done by community tagging, not by name. A community should be able to add a (limited) number of tags to itself, then using a /t/canada url you'd get posts from all the communities with that tag. You could also use /t/canada&hockey to only get canadian communities that talk about hockey.

This would be a separate feature from the manual grouping, that would allow me to build my "home automation" multicommunity that only has hand picked communities by me ("home assistant" and "smarthome", but not "hue", for example)

An evolution of these 2 concepts would be the ability to add tags to a manual group, bringing in all the communities with those tags, together with manually added (and maybe manually blocked) communities.

[ShadowJonathan]

hmmmm, multicommunities based on a combination of community tags and user tags would work

tbh then there should be a way when selecting multicommunities (by tags) to either only allow community-set ones, user-set ones, or all tags

[dadino]

I don't think users should add tags to communities, what I'm proposing is something like this:

Multicommunity: "Home"

• Manually added communities: "homeassistant@lemmy.world" "smarthome@feddit.it"
• Manually avoided communities: "matter@lemmy.world" "zigbee@lemmy.lm"
• Add communities with tags: "home_automation" "home_improvement"
• Avoid communities with tags: "hue"

[hurricaneryan]

I'd vote for having multicommunities being something users define themselves, rather than some sort of auto grouping.

For example, you may want separate multicommunities- one grouping for "hardware" and one grouping for "software", whereas I may want them all grouped into one for "technology".

This seems like something that would be very personal to each user.

[Die4Ever]

I'd vote for having multicommunities being something users define themselves, rather than some sort of auto grouping.

For example, you may want separate multicommunities- one grouping for "hardware" and one grouping for "software", whereas I may want them all grouped into one for "technology".

This seems like something that would be very personal to each user.

The downside is that a user won't be able to subscribe to every community in the set with 1 click

[dadino]

The downside is that a user won't be able to subscribe to every community in the set with 1 click

If multicommunities are public, there could be a "copy mc" that creates the same multicommunity for your account (so that you can modify it), or you could just subscribe to that multicommunity

[ryanpeach]

I think keeping it a user choice is best, and then maybe a sidebar of "admin maintained" lists, which could include recommendations to add a community of the same name in a federated instance if it exists. But essentially we should "share" multicommunity lists, like trading cards.

I would start implementing the naive feature: Add a multicommunity db object which is a list of communities attached to a uuid, a name, a description,and a user (owner). Implement CRUD endpoints. Implement a copy to user endpoint. Implement a make public/private endpoint to make it public or private. Public multireddits go on the users profile. Admin public multicommunities go on the sidebar. A pagenation endpoint, and you're good.

Then later you can implement more advanced rules, tags, etc.

The url could be: https://beehaw.org/u/<username>/m/<multicommunity_name>

For admin users you could just make it https://beehaw.org/m/<multicommunity_name>

I assume there is some singleton "super admin" to each instance in my argument, otherwise I'd create the concept of an instance level multicommunity

[pcamilo89]

The downside is that a user won't be able to subscribe to every community in the set with 1 click

If multicommunities are public, there could be a "copy mc" that creates the same multicommunity for your account (so that you can modify it), or you could just subscribe to that multicommunity

I agree that multicommunities should be managed by each user to their own liking, you could have the option to set each one as public/private, so others can see yours, and you could copy or subscribe to an existing one.

The url could be: https://beehaw.org/u/<username>/m/<multicommunity_name>

The URL suggested seems good for named multicommunities, and you could have the alternative to have URL groupings too, so you can bookmark it on your browser or share it without it being linked to a user, with the format:

lemmy.ml/c/chromium@lemmy.ml+firefox@lemmy.mozilla.org

An additional thing to this last alternative could be to add a button on the UI to add this 'group' to your user saved multicommunities

[ryanpeach]

I worry about these url groupings just being way too long. A multicommunity could have hundreds or thousands of communities.

Once we have this system set up, a system like the proposed "beehaw.org/f/news" could be achieved by setting up "beehaw.org/m/news" (an admin multireddit), in the future with a flag which turns on an option to automatically add new same named communities to it from federated instances if they haven't already been removed. That way maintenance is a bit more automatic for the admins, but also people are in complete control.

[Genfood]

Auto grouping of similar communities should be done by community tagging, not by name. A community should be able to add a (limited) number of tags to itself, then using a /t/canada url you'd get posts from all the communities with that tag. You could also use /t/canada&hockey to only get canadian communities that talk about hockey.

This would be a separate feature from the manual grouping, that would allow me to build my "home automation" multicommunity that only has hand picked communities by me ("home assistant" and "smarthome", but not "hue", for example)

An evolution of these 2 concepts would be the ability to add tags to a manual group, bringing in all the communities with those tags, together with manually added (and maybe manually blocked) communities.

I like that idea, next to the manual approach, mentioned before. I don't see an issue with having both, maybe by side of time and development.
One should think about that these kinds of features, reduce the problems the federation approach brings.

Definitely a manual one is needed but also some kind of an automated one.

The tagging-feature, doesn't need to be called the same and should perhaps be treated as something different.

[jordan1776]

I worry about these url groupings just being way too long. A multicommunity could have hundreds or thousands of communities.

Once we have this system set up, a system like the proposed "beehaw.org/f/news" could be achieved by setting up "beehaw.org/m/news" (an admin multireddit), in the future with a flag which turns on an option to automatically add new same named communities to it from federated instances if they haven't already been removed. That way maintenance is a bit more automatic for the admins, but also people are in complete control.

I think the URL groups would be useful for quickly grouping a few !s together, but named /m/multiname would probably be the way most people would interact with them.

I am not sure if automatically adding communities to a instance level multi would would be a good idea, I would think those are multis curated by the owners of that instance. Effectively just a normal multi but instead of saying "Curated by /u/someUser" it would say "Curated by Lemmy.ml"

[ZeusOfTheCrows]

it would be nice if they supported rss feeds as well. communities currently support rss, but i worry it might be forgotten as they're a weird url currently ([instance]/feeds/c/[community].xml?sort=[sorttype])

reddit supports them by adding .rss to the end of the url (reddit.com/user/[username]/m/[multireddit]/.rss); which is a lot more predictable

[busygent]

What if communities could subscribe to each other as sibling communities?

For the similar / related communities, we could let communities decide which other communities show up together. This would allow communities to self select who their sister communities are. It would federation at a community level rather than a user level.

Meaning if you subscribe to lemmy@lemmy.ml - lemmy@lemmy.ml moderators could choose to "subscribe/join" to lemmy@lemmy.world.

Your client would use this as an indicator to automatically show those communities under "lemmy@lemmy.ml" and your subscription to lemmy@lemmy.ml controls your subscription to the siblings. Moderators could change their sibling communities at will.

This would allow moderators to control which sibling communities they want to join with as they set the tone for their community and keeps the power in the moderator control.

Tangent, the client could even show an icon indicating that the post actually came from a sibling community lemmy@lemmy.world.

[ryanpeach]

I think we might also want to think about how mastadon hashtags play into the lemmy ecosystem. Like kbin is doing. I think interoperability will be a major selling point for fediverse, and we have a huge development advantage over them by having a rust backend instead of PHP.

[ryanpeach]

What if communities could subscribe to each other as sibling communities?

For the similar / related communities, we could let communities decide which other communities show up together. This would allow communities to self select who their sister communities are. It would federation at a community level rather than a user level.

Meaning if you subscribe to lemmy@lemmy.ml - lemmy@lemmy.ml moderators could choose to "subscribe/join" to lemmy@lemmy.world.

Your client would use this as an indicator to automatically show those communities under "lemmy@lemmy.ml" and your subscription to lemmy@lemmy.ml controls your subscription to the siblings. Moderators could change their sibling communities at will.

This would allow moderators to control which sibling communities they want to join with as they set the tone for their community and keeps the power in the moderator control.

Tangent, the client could even show an icon indicating that the post actually came from a sibling community lemmy@lemmy.world.

Not a bad idea to be honest… No new urls required. Communities could also subscribe to mastadon hashtags, and could even auto-append hashtags to community posts to contribute up to mastadon.

[ryanpeach]

Actually what if we did backup to the tag idea but replace tags with mastadon hashtags. Maybe by focusing on interop with mastadon we can get interop between lemmy for free. Communities have hashtags, hashtags are auto appended to posts to that community in the activitypub stream, hashtags are received by any whitelisted or nonblacklisted host as posts, including mastadon posts.

Seperately, multicommunities are manual and user based, a later feature.

Edit: after thinking about it, a community should probably have a seperate "publish to" and "subscribe to" hashtag list. For instance "c/TechNews" might publish to "#TechNews, #tech, #news" but only subscribe to "#Tech, #TechNews" because subscribing to "#news" would be too generic for that subreddits feed.

Communities should also be able to block users (and other communities) tags from showing up on the feed. Maybe because they feel one community is specifically misusing a hashtag, but not the whole instance.

[jamon]

@ryanpeach -- that's precisely what some of us have been talking about in the other newly linked issues. I put together a diagram here: https://github.com/LemmyNet/lemmy/issues/3071#issuecomment-1595303910 and there's some more discussion on here https://github.com/LemmyNet/lemmy-ui/issues/1113#issuecomment-1595273502

[JustAnotherSoftwareDeveloper]

@Nutomic Can we close either this or https://github.com/LemmyNet/lemmy/issues/3071 and combine threads? I feel like these are essentially the same.

[betapictoris]

Couldn't this be implemented by using some sort of RegEx system? For an example:

• /c/technology@*: All communities that federate with with your instance that are named "technology".
• /c/tech.*@*: All communities that federate with with your instance that start with "tech".
• /c/self ?-?hosted.*@*: All communities that start with selfhosted, self-hosted, self hosted, or self -hosted on instances that federate with yours.
• /c/tech.*@*@(?!lemmy.world).*: Same as the second, but exclude those on lemmy.world.

That way people would be able to share the feeds that they create and also have the control to be able to exclude some communities or instances.

[milandamen]

I think that would make it far too complex, and hard to secure.

I think the original proposal https://github.com/LemmyNet/lemmy/issues/818#issuecomment-809854739 would work the best, with the least edge cases.

In addition, a nice to have would be that you could have a user subscribe to a community group, so they will automatically get all the changes done to the grouping. For this you would just make a community_group table, and join that many-to-many with users. The creator of the community group would manage it; and if you made the group yourself, you of course manage it yourself (like a multireddit).

I looked a bit into adding the basic feature described in the linked comment, but the way the server and client code is set up right now makes it a bit difficult, because only 1 community may be given to GetPosts/QueryPosts.

[alejandrociatti]

What if there was another notion like feddit.de/m/<name> which aggregated all communities with the same name,

* `lemmy.ml/c/<name>`

* `lemmy.world/c/<name>`

* `feddit.de/c/<name>`

Simple counterexample: /c/trees on an instance can be about botany and about pot on another one...

[trashhalo]

Do you all think there might be value in descoping this as much as possible to land and add value to our users even if it doesn't hit every use case we want this to?

You could build a small version that mimics twitter lists.

As a user of lemmy I can create a list that features one or more communities. I can name it. I view it like I would any other community. The end.

For now they cannot be shared to reduce scope further. Over time you could expand scope to shared lists and lists shared on servers etc. But you got to start somewhere.

[Die4Ever]

Do you all think there might be value in descoping this as much as possible to land and add value to our users even if it doesn't hit every use case we want this to?

You could build a small version that mimics twitter lists.

As a user of lemmy I can create a list that features one or more communities. I can name it. I view it like I would any other community. The end.

For now they cannot be shared to reduce scope further. Over time you could expand scope to shared lists and lists shared on servers etc. But you got to start somewhere.

the smallest scope possible while still adding value would probably be a textarea input box where you can paste many community names at once and follow all of them lol. Then a community could pin a post with a list of communities they think are related or put them in the sidebar.

[Die4Ever]

I think as long as the backend API supports requesting the feed for multiple communities at once, 3rd party apps could work out the details of the UX before this gets added to the default lemmy-ui

[fievel]

Clearly needed in lemmy because of its decentralized and open nature. I mean that multiple communities will always exists for a same topic and that's great, it's one of the strong point of lemmy openness.

But as a user, I don't want to look at related communities one by one, or in the same home feed as other unrelated communities.

Now for the ways to implement it, there are probably a lot of ways to achieve this need, it could be customizable filters on feeds, meta-communities, or any other ideas.

[Die4Ever]

for anyone who wants a way to group and view multiple communities together, Summit for Lemmy already has this feature

https://play.google.com/store/apps/details?id=com.idunnololz.summit

[doug-wade]

To add a quick user story for why this feature would be useful for me: I am a sports fan, and I don’t want to look at any of the communities that are talking about my sports team until after I’ve had a chance to see the most recent game, to avoid spoilers. I’d like to create a “multi-community” that contains all the communities that might have spoilers (the team community, the league community, the sport community), and then browse my multi-community only once I’m ready. This is the same for any group of related communities that have spoilers, like movie communities. Note this means the names of the communities I want to group may not be related (c/mls, c/sounders, c/soccer, etc)

[fishpen0]

So this might sound crazy but I currently simulate "multireddits" by having multiple Lemmy accounts with different subscriptions in home. I switch profiles in my app to switch my home to a different multi. The downside is obviously that my interactions come from a different "me"

It almost seems like the most interesting way to implement this would be to actually implement sub-accounts. Nothing new needs to be engineered into the feed, it's really just hot swapping one profile for another under the hood when querying for "home" and a ux tweak that ensures actions are performed only from the parent account

[gnu1dea]

As reply to fishpen0: I disagree, that would exclude all the people that lurk without an account. I still think the most flexible solution would be like the one reddit uses (domain.net/multi/sub1+sub2+sub3+etc. or so) or similar suggestions in this issue…

[leonwang908]

Is that implement type community_id from CommunityId to CommunityId in GetPosts API? I read the PostQuery function in db_views. for ListingType == Subscribed the function will get multiple community_id and query data feed. so looks like it will not be a huge change from an amateur programmer.

[Die4Ever]

Now that Lemmy marks posts with a hashtag (for Mastodon) based on the community name, maybe we should be able to view posts from all communities with the same name across different instances? It'd be basically the same thing, so I could browse the games@all feed or maybe call it like #games but that might make people think it will include Mastodon posts that don't belong to a community.

[sevonj]

Edit: This is assuming that multi-communities are actors like communities, and not just query params.

Hi, I come from a similar issue at Photon frontend: https://github.com/Xyphyn/photon/issues/421

That issue is not about public multi-communities, but rather organizing user's own subscriptions. I think private grouping is important to consider, because I see a potential problem of many people reserving public multi-community names just for personal use that has no benefit from being public.

For public multi-communities, I vote for simplicity: just a manually managed list of communities instead of anything convoluted, like automatic tag or name matching, much less regex.