What about allowing communities to federate with others?

Eg. The mods at gaming@lemmy.ml and gaming@beehaw.org could decide their communities have the same audience and ideology. They choose to federate with each other so anyone that subscribes to either or both will get posts for both. Mods will then work together to moderate.

Then if 1 set of mods decide to change their policies or go in a different direction they can then de-federate and break the 2 communities apart again.

I think just being able in my client to "aggregate" different communities/magazines (I'm writing this from kbin) would be great. Like multireddits. This way, everyone can decide for themselves what smaller communities they want to subscribe to. I think neither Lemmy's clients nor kbin support this right now, unfortunately.

I was thinking the idea of hashtags at the community and/or post level could be an idea. That way it could aggregate the various communities on instances under one umbrella. E.g. https://lemmy.ml/#gaming could bring up every federated and indexed community tagged gaming. A community such as the pokemon one on lemmy.ml could have tags #pokemon and #gaming in order to appear both at the superset of gaming as well as connect with other pokemon related subs if there was pokemonGo or pokemonTCG.

It would likely require an update of lemmy system itself, I'd have to spend a lot of time with the code to get an idea of how to implement it.

I think a simple solution to this problem would be to be able to integrate several subscribed communities into a single timeline, similar to Mastodon Lists.

I would call this feature 'Mingling' :)

I propose two ways to create super communities:

Proposal 1) Tag and tag health)

A) Community tags: Here each community is associated with a set of tags (for example, the community 'Earth' can have tags #geology #geography #climate_change). When users post original content to these communities, they will be automatically suggested to add these default tags, but they can remove some tags or add other tags.

B) Tag health: A user Alice who consumes the content can view these posts, upvote some posts, downvote some posts, and can also report an inappropriate tag. Based on these reports, a numeric value can be ascribed to the health of each tag in that community. If the tag #climate_change is reported in a post, then that tag health would reduce.

For example, the community 'Earth' can have tags #geology (90% health), #geography (80% health), #climate_change (40% health).

C) Super-Community: A user Bob can create super communities based on community tags and tag health.

He can create a super-community '#geology' which would lookup 'Earth' and pull the appropriately tagged posts from there. These tags are considered healthy, but Bob can set his own health threshold (say he sets it at 70% health).

He can also create a super-community '#climate_change'. This will not lookup posts from 'Earth', not even the appropriately tagged posts, because a lot of these posts were reported to be bad.

D) Tag Algebra: A user Charlie can create a super-community with multiple tags. For example, he can create (#novels OR #light_novels) EXCEPT (#tragedy AND #drama).

E) User Interface: When user David tries to create a super-community, he would simply enter the relevant tag(s). An advanced customization option would be hidden by default, but the user can expand it if he wishes. Upon expanding, he can see the default health threshold, and can modify it if he wishes. He can also see a list of all communities with that tag, along with their tag health, and a toggle button which automatically turns on or off based on the health threshold. The user can also manually override the automation, and specifically set one community to be on or off.

F) Conclusion: Unlike a central repository of super-communities, this approach can dynamically add new good communities. This approach can also remove old communities which have been abandoned by their moderators, when their tag health has deteriorated.

Proposal 2) Machine Learning Classification)

This is an extension of the first proposal of tag and tag health. Here we consider the following problem:

A) Problem) Suppose a community considers itself to be a neutral #news community. However, they have an unknown bias (capitalist, socialist, communist, etc). This bias is not reflected in the community tag or the post tag. However, users of one bias group would be dissatisfied to see posts of a different bias group.

Users outside the community cannot set unofficial tags or unofficial descriptions for the community since that can be abused. Then how would users create super-communities in a satisfactory manner?

B) Solution) Tag subgroup) Communities that share the same tag (say #news) would dedicate some of their server computing power for appropriately grouping themselves.

Suppose there are communities News1, News2, News3. Each community (say News1) would observe whether its own users upvote/downvote content from other communities (News2 and News3). Based on this, it would establish a positive link strength or a negative link strength with other communities.

In addition, moderators can also add a section called suggested similar communities, and dissimilar communities.

Based on these link strengths, all communities with the same tag (or tag algebra) can be grouped into multiple groups. When a super-community is created with this tag (or tag algebra), then the communities are grouped together if they have positive link strength with each other. However, if some child community has high negative link strength with other communities, then they would be classified into two or more groups, such that each group has positively linked child communities.

C) User interface) When user Emily tries to create super-community #news, it will get automatically created if the child communities do not have too much negative link strength with each other. However, if some news communities have a different theme from other news communities (negative link strength), then they would be auto-grouped into two or more groups.

Emily would see an advanced setting which is auto-expanded, and it will show two or more different groups. Each group would have a snippet that shows a couple of highly upvoted posts. Based on these snippets, Emily can choose any one group, or she can also choose any/all combination of these groups.

D) Conclusion) We can avoid the problem of duplicate communities with conflicting themes on multiple server instances.

Have my upvote. Without such an ability, I fear fragmentation of communities will be a fatal flaw holding back Lemmy's success

There is no problem if there are more communities with the same topic. The ones wich are better moderated and actively updated will eventually gain in popularity and stand out

That's exactly what I thought of. Here's my proposal (though I don't know if this can be implemented in the technology or if it would be compatible with ActivityPub):

Suppose we have two similar communities (i.e., north.pole and north.star, but they both tackle northness but in different instances). The mod from either communities would send an invite to the other to form a "group" or "federate" or "ally". Now, if the other mod approves, here's what happens:

Whenever you post something in a community that has a group, it would be synced with the communities in other instances that are allied to it, including upvotes, comments, and other metrics. So if I post in north.pole, people in north.star could see my post too because we're in an "alliance" and vice versa. They can also upvote my post and I can upvote theirs. There would just be a sign (probably a flair-like design) that would tell users in other instances from which instance the post came from.

With regards to moderation, here's how: they are basically separate communities with content syncing between them. Suppose a user in north.star posts something offensive and against north.pole community rules. The mods in north.pole can block that post from appearing in the north.pole feed.

And here's an unrelated gripe: there should be an instance-standard "ouster poll" for communities that are dead. With what I see right now in the influx of Lemmy users, many communities are dead and users are willing to revive them but they can't because the moderators of those communities are already inactive and redundancy is a pain in "advertising" membership in Lemmy already. There should be like a poll of interested users where they would agree to "oust" the inactive mod (of course there's also a qualification for "inactive") and replace them with probably a democratically "elected" moderator.

While I am on board with the idea, I don’t think it should be a programmatic solution at the community level. Rather, either the third party app or the server (let’s say Beehaw for an example) should allow for the option to create collections based on community identifiers. It would be more of a display function.

The reason I think this needs to be done at the user level is because everyone has their own organization models. At one point, I had all my subreddits aggregated by Library of Congress Categories (since may home library is organized that way). Some people may want to put c/Beatles in a Music category, while others may want Bands or even others by genre.

What would be nice is if the communities had tags to identify their subject matter. For instance, c/Beatles could be #britishinvasion #music #beatles #band #60srock etc. That way people could look by tag and aggregate that way (plus it would make it easier to find c/GeorgeHarrison c/PaulMcCartney c/JohnLennon c/RingoStarr ;-) )

The way I would see this play out is that the user would have to option to create a “Super Community” and give it a name. Then there would be a search by name, tag, subject etc. and the results would have a toggle that would add, or subscribe and add, that community to the super community.

A solution like this would preserve the sovereignty and integrity of each of the servers. All the servers are offering are possible some more discrete identifiers (should they choose) to make themselves more findable. The control is placed on the user to organize and curate their selections.

I don’t mind responding to different communities with similar subjects. I did it all the time on Reddit. But it would be nice to, say, focus on my “Apple” super community or my “Worldbuilding” super community. When you have eclectic interests that span a vast array of topics, being able to aggregate “like topics” is a boon.

True fragmentation seems like it would be a huge issue.

Also allowing easy exporting/migrating between instances should be possible.

From my understanding (having literally discovered lemmy and the fediverse like an hour ago) mastodon supports things like grouping and account migration, so I assume it should be possible with lemmy?

Also I'll be honest I have no idea what mastodon is.

Kind of like multireddits? I hope so

I've mentioned this elsewhere but it could just be a UI thing handled by/for each user, that way moderation and control will stay where they are

Basically I could make a group of communities/magazines, for example
selfhosted@kbin.social
selfhost@lemmy.ml
selfhosted@lemmy.world
selfhosting@chirp.social
selfhosted@lemmy.ml
selfhosting@slrpnk.net

For browsing, up/downvoting, and commenting it could be totally transparent. When you want to make your own thread it could just have you select the specific magazine/community from a drop down.

This wouldn't fix the problem of seeing multiple duplicate posts from each.

You’re already posting in a super community!

Even within Reddit communities, a lot of posts ended up in multiple places, and the 'crossposting' function seemed off to me, because everyone voted on and commented in different places.

I wonder if a 'tag' system wouldn't work better, where a post shows up under multiple hashtags. This way, a picture could go under '#sea #thalassophobia #submarines #pictures' all at once.

If everyone votes on the same post, posts would receive negative attention for inappropriate tags (I'm assuming that people would downvotes pictures of cats which had the #dogs hashtag).

I had the same thought here: https://kbin.social/m/linux@lemmy.ml/t/9828/uhhh-what-do-I-call-the-subreddits#entry-comment-42869

B sounds like a sensible solution to the issue, but maybe not so much in a thing that communities "join", but rather "connect" to. The former sounds like a centralized thing that has to be hosted somewhere, the latter being something that exists purely through the communities that are part of it. However, I suspect this needs to be a feature within the actual fediverse type protocol that all those instances (including Mastodon) use, to make this an actual possibility.

To some extent, this reminds me of the old BBS system. Local BBS had their own discussion boards, but they could join a larger one called 'fidonet' which allowed them to share global discussion groups between other BBS. So you could have a local news section, but there might be a news section on fido which would include more global topics. They were fully independent.

That made sense in the context of early the early 90s though, now it's a bit different. social media which is too far splintered ends up not being that social. Good to have alternatives, but yes, if you have 250 different cat groups, it's almost overload. There needs to be some kind of a happy medium there.

Lemmy is decentralised, so there's no way to establish the concept of a 'super community' without decided a specific instance plays that role - an instance that, ultimately, is hobby run and just as vulnerable to outages as the others. What happens when the instance running the Super goes down?

There's also no way to make a Super any more official than any other. It can handshake a bunch of instances, but unless a user registers to the Super, they still need to search for them like they do now to introduce them to their own instance. A 'Super' may as well just be an instance deciding to put a Megathread of federated servers in its own Support community.

If the Super federates with a bunch of different instances, it also limits those instances abilities to defederate from each other. We'd end up with one of the following:

1. several 'supers', each with their own federations (meaningless bloat compared to the current system - you also can't prevent somebody from making their own super, so this is practically inevitable anyway)
2. many instances that are effectively 'shadowbanned' because they aren't in 'The Official Super'
3. users using the Super to be active across defederated communities and limit moderation's ability to keep out bad actors
4. large instances becoming defederated from the Super to limit 3.

I'd suggest users subscribe to duplicates, for a few reasons (ultimately about federation and safety in redundancy).

1. Connectivity.

Until an instance first reaches out to introduce itself to another instance, communities are not visible. Somebody on lemmy.ml can look for 'gaming', but until somebody searches for !technology@beehaw.org to introduce lemmy.ml and beehaw.org to each other, then beehaw's communities like beehaw.org/c/gaming will not be in the results.

Having duplication helps communities find people across many instances. While it's true that one will likely get bigger than the other, people cross-posting in them or being active in both will allow them to act as bridges to each other, improving how instances network.

2. Longevity.

Lemmy is federated. That means we have dozens of different servers running in different homes, basements, hobbyist offices. It's not centralised, and they're passion projects. So not only is decided which instance should be the 'official' one meaningless, having at least two active somewhat-duplicates provides a level of redundancy if one of them shuts down. (Say, the owner dies, or goes bankrupt, or their office is hit my a natural disaster.)

3. Community.

So you raised the idea of each smaller community having duplicates. This is a problem for a platform that wants an aggregate that reaches as many as possible, such as a tech support community. But for social communities, the smaller ones have their own niche. You might not get as much volume in cat pictures (you can always sub to more cat subs if you wish) but the c/cats on your own instance is going to develop it own instance-specific community, where you know each others' cats by name. Hey @kittypaws@lemmy.meow, how is Madame Biscuits doing today? She seems to like her new bed!

I was wondering the same thing. This is one of those double edge features. On the positive side if a community moderator is no good, or an instance is getting too big, there is the simple option to just make a new community on a different instance. The downside is having a bunch of duplicate small communities is not always a better option than one big centralized one.

I like the idea of super communities, but I am not sure that is even possible with the fediverse/lemmy. There might be some way to do this manually with instances dedicated to a certain topic, but that seems like it would be overkill. Also it would be interesting to see who would end up responsible for moderating the super community.

I also think option B is a good idea. It could split up the load of a large topic.

As for maintaining the distributed philosophy of Lemmy, I think it could possibly work by moderators of each community vote on/approve other members of a super community, like and alliance or union. They may want to agree on a standard set of rules. Then if you subscribe to one, it can pick up the others automatically. And if a community/moderators go rogue then the members of the super community moderators could vote to expel that community.

This keeps it still mostly simple/automatic for most users while allowing for a decentralized way to group communities and handle bad actors.

Not sure how feasible it is on the technical side or how it would fit into ActivityPub. But hopefully we find some solution to these fractured communities.

Doesn't that go against Lemmy's philosophy? I see where you're coming from, and I agree there should be some way to find all related communities. But putting them all under the same umbrella makes all depend on the "meta-community" and its administration.

[This comment has been deleted by an automated system]

I personally like the idea of a linking bot that would cross post automatically accross communities and deduplicate things posted by the same user on both.

You could also just cross post things with relevent tags and crosspost then in relevent communties

For this to happen every single instance will have to fetch every community from every instance to aggregate posts and make sure new similar community is added which isn't feasible (I think).

Give it some time, and I think organically 1-2 most popular communities will emerge for each specific topic and people will then just subscribe to those ones.

I don't think this is an issue tbh.

The full name of a community includes the instance is running on. For this community here the instance is asklemmy@lemmy.ml . If you are referring to community you should include the instance to avoid confusion.

To the issue of duplicate communities: That issue existed on reddit too. Communities with slight variations in the name always existed. Sometimes the owners of some variation of the community just decided to forward their users to a "main community". Sometimes multiple communities coexist. I believe that in most cases a certain "main community" will establish itself as the one that the majority just accepts as the "real deal" because it has the most activity and the best moderation policies.

I think B is a good idea but I wonder how it would work. Maybe open an issue on github.