A loosely moderated place to ask open-ended questions
If your post meets the following criteria, it's welcome here!
Looking for support?
Looking for a community?
~Icon~ ~by~ ~@Double_A@discuss.tchncs.de~
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 this would be the easiest way honestly. It seems the least extra work or changes. Mods don't even need to work together, just with their own posts. If they're too different on their own, they won't federate anyways.
If people really want a supergroup, it would in this situation only take a new community that does nothing but federate existing ones. But it may not even be needed.
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.
So what should be easier now is finding those communities/magazines, maybe on a post of one of these communities with links to the other ones
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 thinking it would also have the plus of better integrating with mastodon.
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.
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.
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.
This is impressive despite my lack of understanding.
Have my upvote. Without such an ability, I fear fragmentation of communities will be a fatal flaw of Lemmy's success
Isn't that the whole point of Lemmy? So there's no community that's too big to fail?
Ideally you'd want 3-4, but 300.
not the whole point, imo
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.
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.
I agree with this post 100%. Super Communities need to be able to be shared too - I’m sure there are some folk who will just want a quick start and would love to just subscribe to a premade “top 10 /c/technology communities” or something. And then it could be expanded later etc.
Honestly the multi Reddit model works really well. When I see a multi that I like, I can clone it and change it how I need. It basically acts like a fork.
Yes, this. It allows decentralization to still exist protecting users from future reddit overlords, while still allowing each user to customize their experience by aggregating what matters to them personally. It also makes it super easy to remove one specific instance of a Beatles "sub" when it gets too raunchy, racy or just not what you personally want to see anymore.
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.
I don't like the idea of a voting system for mods, as it can be gamed very easily by bot accounts. Democracy is sadly under threat due to AI, and so I think the wall-gardened approach might be necessary: users choose an instance of north that suits them, and if the mod is a dick, then those users let the mods of the other north instances (under that super community) know, and the mods of other instances make the decision.
Great ideas, sounds ideal to me
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
We definitely need multireddits here! And cross-posts. Helps immensely in aggregating and discovering communities!
You’re already posting in a super community!
Aww shucks bloodfart ☺️
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.
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’m assuming that people would downvotes pictures of cats which had the #dogs hashtag
Honestly I'm not sure. One problem on reddit is that people just upvote things they like that show up on their frontpage regardless of where it's posted, which means all the big subs blur together.
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.
Maybe using tags? A community can tag itself in areas it wants to both be included in and excluded from. And allow users to surf tag feeds to comment and upvote on, also allow us to organise our communities within groups in our own way?
I had the same idea. Tags are already there to gather posts related to a topic in a single page. The difference in experience would be the curation reddit's subreddit system allows. Curation and moderation. Otherwise, an agreed upon tagging scheme should do the trick if the only concern is subscribing to topics.
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:
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.
Maybe an option would be to have a virtual "parent" community, or a community group that communities can join. For example, the supercommunity "memes" could contain meme communities on different instances, aggregating posts and comments when queried. Posting would only be possible to a given community though.
This brings an issue with moderation however. If a participating community would be taken over and used to post spam, there would be no clear mechanism to exclude that community from the parent community. Perhaps it would be better if these parent communities where user curated, so the creator would add one or more communities to the parent, allowing other users to subscribe/unsubscribe from the parent at will.
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.
Well yes and no. I think the point is to avoid 500 arbitrary half dead Cat communities, or to help users find there niche for their town or interest so you aren't left with multiple dead communities reposting questions all over the place hoping to find the community with the answer by sheer dunb luck while also thinking that Lemmy is dead.
Finding out that the official photography sub lives on glasgow.xyz is a big ask. So maybe it would be a good start to keep things fractured but allow an easy way to group them into a feed like the way multis work. Looking at my subscribed list is a horror show right now and I shudder to think of the infighting when three growing communities butt heads trying to spam each other's users to grow there own. If I can organise my coms into categories and folders that would be a start. Maybe creating feeds by tag? And subscribing to tags?
[This comment has been deleted by an automated system]
I think B is a good idea but I wonder how it would work. Maybe open an issue on github.
I know nothing about programming, so I'm kind of hoping someone involved can take this further.
Edit: to add, I also only discovered Lemmy a few days ago, so my grasp on the whole process is tenuous at best.
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.
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.
This is kind of what I was thinking, too. There's no limit to how many duplicate subs there can be on Reddit but that didn't stop people from eventually finding the "main" subs. Lemmy just needs a critical mass of users first, so that the clear winners are easily seen. With numbers being so low right now, there's no clear winner among duplicates.
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.