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' :)
this post was submitted on 10 Jun 2023
12 points (100.0% liked)
Asklemmy
43945 readers
1063 users here now
A loosely moderated place to ask open-ended questions
Search asklemmy ๐
If your post meets the following criteria, it's welcome here!
- Open-ended question
- Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
- Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
- Not ad nauseam inducing: please make sure it is a question that would be new to most members
- An actual topic of discussion
Looking for support?
Looking for a community?
- Lemmyverse: community search
- sub.rehab: maps old subreddits to fediverse options, marks official as such
- !lemmy411@lemmy.ca: a community for finding communities
~Icon~ ~by~ ~@Double_A@discuss.tchncs.de~
founded 5 years ago
MODERATORS
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.
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.
This is how it's done on mastodon
I was also thinking it would have the plus of better integrating with mastodon and other ActivityPub apps that use hashtags.
I'm a terrible coder and I also won't have any chance to even start figuring out Lemmy until at least Tuesday night.
This would be lovely. Then once that functionality was working, we could create a Reddit-style front-page for new accounts that subscribed to a bunch of popular hashtags. That would really help to ease onboarding and make instances feel a bit less isolated.
Have my upvote. Without such an ability, I fear fragmentation of communities will be a fatal flaw holding back Lemmy's success
Isn't that the whole point of Lemmy? So there's no community that's too big to fail?
not the whole point, imo
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 kind of like the idea for B. I'm not sure how to determine who the authoritarian figure would be to decide which 'cats' get to be in 'super cats'. Could some be excluded from the super group if they're pro-dogs/racist/etc? Is that against the whole idea?
Any update on this?
I couldn't find any comment from the devs. Was there one?
There is an extra problem, not mentioned here. When there are subs with the same name, it is actually impossible to know of choose which sub I am posting to. Like here.
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.
That's programmer logic. What we need is that mods of example.com/c/community and instance.xyz/c/realcommunity can agree on connecting, and from then on, everything from either would show up on the other as well.
No need to make things too complex.
Even after they connect, a user needs to subscribe to topics of their interest. It would be burdensome for a user to subscribe to the same topic multiple times on multiple servers, because everything is fragmented.
Maybe something closer to migration management in mastodon? Two groups of moderators on separate servers agree to a common set of moderation guidelines, publish an event or setting which says "these communities are merging", and from that point on they act like aliases for a merged community which share responsibility across servers.
These "merged" communities could be visually flagged as distinct from the normal rules / moderation of their respective servers to prevent conflicts arising from differences in server management.
Feature support would be limited by the server events are sourced from. E.g. if beehaw.org and lemmy.ml merged their technology communities, people on beehaw still wouldn't be able to downvote posts or see downvotes, but lemmy.ml would unless they explicitly disable to feature as a part of the merge contract.
When subscribing, you might see a list of merged communities which share responsibility for moderating the final one, and you have the ability to choose which "entrypoint" you use.
I think tags are a good idea, it doesn't have to be too complicated (like proposal 1A only) but there should be a limit of around 5 tags a post and 5 tags a community.
I think that it fair.
This is impressive despite my lack of understanding.
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.
[This comment has been deleted by an automated system]
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.
This is what I want. A way for users to create their own "lists" similar to multireddits, which come up on their feeds as part of a super-community, and then they can share that list with other users.
No hassle for the moderators. No change to the system outside of the feature's own self-contained stuff.
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.
I think this is the ideal solution, but you should be able to share the groups you create with others, exactly like multireddits. That way, collections of these groups could be made available to others, for them to add to their feed.
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
Yup, essentially the same thing happens on Reddit and things always seem to work out in the end.
Could potentially be hundreds though, and puts a lot of work on users to look around for the best one -> most likely the communities in bigger instances will win out.
This is a discoverability problem that can be solved separately from the duplication "problem" though. Reddit has all the same duplication, there's /r/tech and /r/technology, there's /r/DnD and /r/dndnext, there's suddenly 3 million aita communities. What makes people not sweat this at Reddit is that subreddit search is MUCH MUCH better than Lemmy's community search. You always find the biggest subreddit first, and there's no danger of finding only the small/irrelevant community because the big/main one didn't show up in your search for confusing federation reasons.
If community search was effortless and worked to discover the biggest relevant community irrespective of the server it's on, I think people would immediately stop caring about community duplication, similar to how it's rarely cited as a problem on Reddit even though it's rampant there as well.
view more: next โบ