This is probably the wrong place for this, but is there any intention to have something like super communities, where the same community exists on multiple instances but is treated like just one?
Ie, if you sub to asklemmy on world, you see content from whatever other servers have asklemmy.
To OP and any smart coders out there: if you could implement this feature into Lemmy yourself, you could earn up to a cool €6000.
1-4 years and that much money is still unclaimed
I’m not very familiar with how these bounty contracts work, but I am going to assume it’s not happening if they haven’t decided by now :(
Why code a single time bounty for 6k that probably will take you months if you can work a regular programmer job and get 10k a month?
My man, “regular” programmers aren’t making 120k a year plus enough for taxes to end up with 10k a month take home. Seniors, people working in high COL locations, working for FAANG or whatever the buzzword is now, sure maybe.
But that’s not average pay.
Depends on the area and location.
I’ll quote what you just replied to
people working in high COL locations
SF Bay, Cupertino, Redmond, etc… the big “tech hub” cities are known reality warps.
This is one of those things that sounds simple and intuitive on paper (“just” take all these communities of the same name from disparate instances, smash them together so they all display on the same page) but once you start thinking about the details it becomes clear that it’d be a logistical nightmare and a clusterfuck to actually implement.
For a start, moderation would become diabolically complex.
- If multiple communities across instances are merged, each has its own moderators. Who can moderate which content? Everyone? Only the moderators for the instance in which the content originated?
- If it’s the former, what’s to stop a rogue moderator from a bad instance from merging their community and then deleting content/banning users who aren’t theirs?
- What happens if a user gets banned from one instance, but other instances have merged content in this community under which that user is not banned?
- Who decides what community and instancewide rules apply to the merged instance of that community, which will inherently include users from outside their instance?
- Who sets what the banner and sidebar look like, considering that nobody from any given instance can “own” the entire supercommunity?
- Etc.
I think the only way this could possibly work at present is if were client-side, i.e. you can create your own supercommunity by merging content into a single page on your own device, but purely for display and in a read-only fashion. This would not provide the implicit benefit I think you’re angling for, though, which would be solving the Fediverse fragmentation problem.
The way I’ve been thinking about would be to have the “meta community” be a separate thing from each individual community. Each individual community would opt in to joining, and would retain their own moderation and users, but the posts would be sort of cross posted to the meta community. The meta community mods largely just deal with removing posts that don’t fit. All the comments go on the original instance of the post and are moderated there, so the meta community mods might be allowed to moderate those comments on an opt in basis.
The idea is that it’s for very similar communities across different instances, but because it’s opt in there are probably other uses. The hope would be that each individual community could retain their vibe, while the meta community would have more of a firehose of content, and possibly filter some of those topics back down for more in depth discussion.
I’d also love for individual users to be able to group communities for themselves, and for those to be shareable, which seems much quicker to implement.
Yeah, I feel like a meta community is a clients side feature with server side hints.
Considering all the limitations, and the hyper-fragmented nature of the Fediverse, maybe it’d be worth adding a feature to “redirect” or “symbolically link” communities. For example, dota@nicheinstance.com would just open dota@lemmy.world (possibly with a notification banner or similar to clairify). Throw in some extra tools to improve moderation across instances and you’d have 90% of the benifit of “super-communities” without the complexity.
I know you can do this by just making a locked community with a post describing this, but its a very clunky solution, and given how fragmented the Fediverse is, and how unlikely that is to change (given the structure) it might be worth having a dedicated method.
There is a FEP that has a proposed way to address this: FEP-d36d: Sharing Content Across Federated Forums (https://codeberg.org/fediverse/fep/src/branch/main/fep/d36d/fep-d36d.md)
I don’t know that anyone has implemented it through.
Some Lemmy clients let you group communities. Depending on what communities you group together, it’s kind of like that. But like @dual_sport_dork@lemmy.world said, it sounds good on paper but the logistics become crazy once you factor in things like moderation and culture clashes.
Yeah the real answer is “Yes its possible, but only client side”. Making a web interface that allows grouping together different communities and their posts into one “meta community”. That way the origin and moderation of posts doesnt change.
You could even go as far as creating importable community groups curated by individuals like a playlist of sorts. If you like or dislike something you can add or remove it from those groups. Responsibility for what you group together lies entirely with the user and reports for individual posts and blocklists would apply just the same as usual.
PieFed has implemented Topics, which are groups of communities maintained by the instance admin. I think they plan to make topics per user at some point.
Yes. I think something like what Kbin did with it’s “Collections” would work fine, where it’s basically a crowd-sourced Topic. Currently topics are administered by the instance admin(s) which doesn’t scale very well but scaling isn’t much of a concern at the moment.
I’d proposed a potential solution.
I’ll paraphrase : Currently, every Lemmy instance (ie: Lemm.ee, Lemmy.world, etc) is an island. This is one of the strengths of Lemmy (Federation) as we don’t have to worry about information being restricted, censored, manipulated (ie: Reddit).
However, as things are currently, this Federation comes at the expense of splitting the community between instances. asklemmy@lemmy.ml vs asklemmy@lemmy.world is a perfect example. Posts are either duplicated (which creates noise) or it fosters a “Lemmy instance death by starvation”. Meaning, more and more conversations will eventually drift towards one of the two asklemmy communities, leaving the other one to “starve out”. This defeats the entire purpose of federating.
There has to be something better.
For example, instead of “every instance is an island”. Meaning the current hierarchy is “instance” - > “community” - > “post” - > “threads”. We could instead have “community (ie: asklemmy)” - > “post (ie: this post)” - > “instance (Lemmy.ml, Lemmy.world, etc)” - > “threads (this comment)”.
From a technical perspective, it would mean that each instance (that’s interested in hosting this supercommunity) would replicate the community names and posts (Not the threads).
Lemmy already kind of does this, when a user pulls a post from another instance. For example, I’m on lemm.ee but when I view posts from asklemmy@lemmy.world, lemm.ee will retrieve and cache it on lemm.ee. As long as each instance would share a unique identifier to associate the two communities/posts as “the same thing” (and this could simply be the hash of the community /post name). Everything else would be UI.
Each instance would take ownership of the copy of the community and post, which means they could moderate it according to their standards.
As an end user, you’d view a community and post, but the comments/threads would be grouped by the instance that hosts it. If there’s an instance you don’t like, you simply unsubscribe from it.
For future iterations, it might be nice if the instance itself would auto-subscribe or suggest other instances that host the same community to the user. Meaning, if I subscribed to asklemmy@lemmy.ml, I’d automatically be subscribed to asklemmy@lemmy.world. However, as the user, these are all separate subscriptions, so I can customize it as I see fit.
A recipe for some epic drama!
To respond to questions about implementation, I was thinking something along the lines of communities are federated with each other.
Some workflows:
Posting
I want to make a post to c/tech, so I post on tech@lemm.ee, my post then gets federated to the other instance and shows up there. (Servers would want to add de-duping for people who are subbed to both)Deleting my post
Similar to above, it gets marked as deleted on bothMod action:
Mod on lemm.ee removes my post, the event and reason get federated. The other instance could be set up to follow the action or have a mod action to do anything with it.But anyway, for now I’ll try to see if there’s a way to group communities, but I don’t think Sync for lemmy has that.
The reason I was thinking this is because this part of federation actually makes things harder. And then there’s the aspect of “where do you post this”, bc sometimes the community is bigger on another instance, so you cross post just because it’s essentially the same thing, just somewhere else.
I understand why some folks would want this, but I just don’t. I don’t want to interact with users from e.g. .ml so I don’t go to communities hosted on that instance. But if they were joined in, you’d get the same people in News and Politics regardless of where you go.
I would pretty much be forced to find or run an instance that federates with exactly the right servers. Even then, I’ll have someone talking about what u/shitfart said in their comment and I won’t have a fucking clue what they’re talking about. Then there are the people caught in between who see everything and wonder why people are talking like they don’t see one another.
It would just be an absolute shit show. My instance is having some federation problems right now and I’ll see someone say “I’m jumping on the bandwagon” but there is literally no one else [that I can see] who is taking about what they just said.
I totally get why this would seem to be a good idea, but I don’t like it.
The way I’d want it would be user built super communities. Like, I decide what groups to conglomerate…and no one else is the wiser.
It would be great to implement client side. I just don’t know how the comment system would work. Do you post to 4 communities all at once? Obviously moderation issues if it’s a single comment linked to 4 servers, but if it’s not then people who don’t have a client that combines duplicate comments on duplicate communities would see a bunch of garbage spam.
I guess I’m not saying it’s inconceivable that this feature could be done well, but the obstacles seem really tall. I can’t even imagine how I would implement this.
Good points. I’d make it totally client side so my actions with the fediverse are atomic and normal. At most I could specify which community in my supergroup the post will land on, but on the intake direction, I have one stop shopping for multiple communities. When I enter a post and comment on it, it acts like any other. The core premise is client side aggregation, not server side multiposting or anything
Edit I will say it is annoying when you see someone shotgun every similar community across the fediverse with their post, just trying to get it seen. I do not believe my client side grouping helps with that at all. Some sort of dedupe would be required, and thats scope creep
I was thinking the community could show you which ones it federated with and you could have a selection for which ones you want. Something like
This community federated with:
.ml | hexbear | .world- [] .ml
- [X] world
(I can’t get check boxes right)
But that’s more of an implementation thing and could be done client side
Seems to me all you have to do is possess and lock all but one community with a link to the main one. That resolves all the comment and federation issues.
