EDIT: Thank you for all the great responses! I agree that a forced implementation is no longer the way to go. I’ve left the post as is, aside from this comment, in case anyone wanted to reference part of it. At this point, I think implementation 1 (Sincere Request) is the way to go if anything.
I’ve seen a few of these posts, some with really cool solutions, but a lot of them are difficult to implement, or complicated for casual users to understand. Here is my proposal on how we can coordinate communities that share the same topic, while also keeping the spirit of federation.
This post has some general thoughts on why I think this is the best solution. It also has some possible implementations, including a trivial one that works already without any automod or code changes.
General Thoughts
This talks about why I think this is a better solution. Feel free to skip to ‘proposed solutions’.
Leave vote counts alone:
- Some proposals talk about sending vote totals to the original post or having all cross posts share a total vote count. This leads to issues since larger communities can manipulate which posts show up, and it creates an incentive for users to spam posts to unrelated communities. This also might lead to implementation issues, where the vote counts don’t properly federate out. It’s also confusing for casual users, and it takes power away from individual communities to decide if a particular post is relevant or not.
- With all that in mind, I also don’t see much of a benefit in playing with the vote counts. It might be better to leave them alone.
What are the issues we’re trying to address
- Comment threads are disjointed. Users need to open up multiple posts to see what is being discussed. With small communities, a few users are just talking into the void. This issue is addressed.
- Can’t see relevant content without subscribing to multiple communities. While this can be seen as a downside, I think it has an added benefit because each community can decide if a post is relevant or not. Forcing posts into one community may lead to other drama with linking/unlinking, and it’s very confusing for casual users to figure out who’s actually going to see a particular post if it automatically appears pops up in other communities.
- Scrolling past multiple identical crossposts in a row. My proposal doesn’t address this directly, but it may offer a way for apps and frontends to deal with them.
Proposed Solutions
The general premise here is:
- User makes a post in community A
- User makes crossposts in communities B, C, and D
- Posts in communities B, C, and D are locked, with a link to the post in community A
- If someone wants to make a comment about the content, they can do so in the main post in community A
Benefits
- User can pick which community to have the comments appear in. They can base this on rules, moderation style, or if they want to promote a niche community
- Everyone else is free to upvote/downvote the posts independently
Issues that need to be addressed:
- A malicious user can post a scam or misleading content, and then lock the post with no easy way for people to call it out. While this can be reported to moderators, people may fall victim to it before the post is removed and the user is banned. Simply checking for a redirected post isn’t enough because a user can make that post be on an instance/community they control, and remove comments calling out the content.
Implementations
- Sincere Request: After making a post, the user can paste in a standard comment asking people to comment in the linked post.
- Doesn’t require any code changes and you can start doing this right now
- Relies on commenters listening to the request
- somewhat silly, but this is the easiest implementation
- Automod locks top level comments: After making a post, the user can leave a comment to trigger automod.
- automod will prevent any top level comments, but still allow replies to the original comment.
- requires updates to core lemmy for partial locks, or for an admin level bot that can remove comments from posts based on characteristics
- Automod locks post entirely: After making a post, the user can leave a comment to trigger automod.
- automod will lock the post entirely, and leave a comment on how to deal with issues
- anyone can message automod with a link to the post, and have it be unlocked to discuss issues
- doesn’t require updates to core lemmy, but it does require an admin level bot
___
This kind of defeats the purpose of having multiple federated communities. Politics on lemmy.world and politics on Beehaw are different communities with different rules and different people who can even see them. Some people are subscribed to individual communities because they like that community, not because they want to join in a free for all with the entire fediverse. They don’t want to go to lemmy.world because the first poster liked lemmy.world traffic or moderation better, they chose the community they subscribed to because they liked it better.
I think the better solution is a front-end collecting comments for a particular link in from all the communities you subscribe to. If you subscribe to three different politics subs and they all post the same link, then all the comments could be displayed at once, either interspersed (with some method of considering traffic when comparing vote totals) or in collapsible sections (effectively like a top level comment for each community).
I feel the same too.
I think the merging can be part of the federation process as well. Since I’m going to receive posts from the same server, it can combine these posts and give me back the combined view. There will be some kind of repost ID/link so that the server knows how to combine them.
This works for viewing all the comments so far, but it doesn’t solve the discussion aspect since commentors from each community won’t be seeing or responding to the other comments. This is a bigger issue with smaller communities, where they’d mostly be top level comments / chains with minimal depth from each smaller community. Yes you can see all the comments, but the discussion quality is poor.
It’s also not as helpful when the automation fails. Something I’ve found is that the ‘crosspost’ field starts to get crowded on posts that link to a popular website. Combining comment sections from ALL of those posts isn’t as useful as having some intentional action from the OP.
A key aspect about this proposal is that it requires the OP to do something. If it doesn’t make sense for a community (ex. different intents behind the Politics communities), then OP shouldn’t lock their post. If OP does it anyway, then you can downvote that post.
Everyone who’s subscribed to the same communities will see all of each others’ comments. The ones that won’t be seen are those in communities a user intentionally doesn’t subscribe to, which is a good thing.
And putting the choice of where conversation takes place in the hands of the OP isn’t good. There’s already issues with the first poster in a “no duplicate submissions on the same topic” community getting to set the tone for conversation through title and text. This just makes it worse. Downvoting a bad link still means the conversation is being denied in the community of users’ choice and the solution to that is allowing duplicates, which is just the status quo plus extra spam.
Everyone who’s subscribed to the same communities will see all of each others’ comments.
This still relies on everyone using the same app/front-end.
I guess I’m thinking about how it would be helpful in more general cases. If someone has an issue with a FOSS app, and they ask about it in two small communities, it would be much better to have the troubleshooting discussion in one place rather than have both communities missing part of the context.
Ultimately in your example, the user can still make both posts, this doesn’t change that. It just directs the comments to one post’s comment section rather than having it spread out.
Still it’s good to think about cases where OP tries to abuse the system. Would a good middle ground just be the first implementation then? For OP to link to the post that they want to be the main discussion thread, but people are free to ignore that if they want.
What we really need are universal post URLs so people can visit posts without leaving their home instance. It’s not a great user experience to find yourself on the wrong instance and unable to respond after clicking the “cross-posted from” link (or when linked elsewhere).
I agree, instance assistant (our extension actually!) handles this, but it would be much better to have it exist natively.
Thanks for your work!
Almost all of the front ends do this already.
I’d rather just have different communities. There are some instances I’d prefer not to have to go to and this proposal would give more controls to the bigger communities.
this proposal would give more controls to the bigger communities
what are the concerns that come to mind?
I’d rather just have different communities
All the individual communities would continue to exist as they do right now. When it makes sense for a post to have a deeper discussion, users can lock and redirect accordingly
I’d rather not have to go to a different community to discuss a post.
that’s fair :)
I don’t think that fragmentation is always a problem. And, even when it is a problem, a lot of times it’ll solve itself - users tend to congregate in larger communities, if everything else is the same. And when a piece of discourse is relevant enough, it tends to appear in all relevant threads.
Regarding the implementations, locking posts (partial or completely) and redirecting users would introduce problems like this:
- You’d create situations where the users can’t discuss the topic, because they’re being directed to an instance that defederated theirs.
- Sometimes userbases simply don’t mix well, like water and oil, and redirecting both to the same threads will end disruptive and annoying for both.
So as silly as the first idea (request) might be, I think that it’s the best of the three.
The problem really is that lemmy doesn’t have the critical mass of users to support many small communities that are all self sustaining. And discoverability is so bad for communities it’s entirely likely that if there are 8 people out there that want to discuss X in the fediverse, 3 are in one community, 2 in another, and 3 in a third, and none of them ever finds the others. The lack of users causes a lack of content and they all the up not engaging at all.
If you have enough users the idea of multiple communities holds water a little better. But I think it’s a significant barrier to actually gaining those users.
The fact that discoverability is so bad only reinforces the tendency to gather on larger comms - because it’ll affect the most the smaller ones. I also believe that the demerits of the idea would outweigh the merits for the comms that already reached a local critical mass, and that’s bad because most interactions happen on them.
IMO @Zaktor@sopuli.xyz’s approach (handle it through the interface) is a better approach. It doesn’t handle the problem of discoverability, but that could be addressed other ways (such as
multiredditsmulticomms).Multi comms are a good idea, agreed.
As for weak discoverability encouraging tendency to gather on larger comms…I agree, but I would just add that it does require motivated and proactive users. This isn’t a given. In my hypothetical, those people started their own communities about something they like, and had a few users but not many. Do they at some point decide to give up and search for another community? Or do they just forget about it because there’s never any activity and they don’t go there? How many searches should they do without finding anything?
As a real life example of my own, I’m a Green Bay Packers fan. I wanted to find a place to take part in active discussions about the team. I joined what seemed to be the biggest community and posted a few things, commented in threads. Most would get one or maybe two replies. Often nothing. A month or two later I searched again and found a few more communities that had popped up. All around the same size and activity level. Joined them, also crickets. The members there didn’t congregate around a larger instance, they created more small instances and then all of them ended up largely abandoned.
I don’t know exactly why that is, but I’ve had this experience with other topics too. Maybe instance tagging with a recommendation algorithm that suggests similar communities in the fediverse based on the community you’re in?
Users congregating in a larger community has its own problems if that is on an instance that, for some reason, ends up being defederated by many others. I wish the communities could exist independent from the instances, a bit like usenet.
I prefer a much simpler solution: the threadiverse remains decentralized, with all that that entails, and all of the people who can’t cope with that leave.
- User makes a post in community A
- User makes crossposts in communities B, C, and D
- Posts in communities B, C, and D are locked, with a link to the post in community A
- If someone wants to make a comment about the content, they can do so in the main post in community A
Doesn’t work because of defederation.
Assume users from instance X can see B, C and D, but not A.
Now all they get is three teaser posts, referring to community A, which is invisible and inaccessible for them.
Because of defederation, each community must be able to work as a standalone.
Yep I think the defederation point is the big one which causes the idea to break down. I’ll edit the post to better reflect my thoughts now
Harder to implement but I’d rather have a feature to mirror a post among different communities (if the specific community opts in to the feature).
I think it would be good to replace the cross posting feature with a feature that proxies/links to the original post. So it’s basically like a symlink. This way, every comment and upvote would be directed to the original post. Not only will it solve that problem in the first image, but also will save storage.
Forcing people on community A to go to community B to discuss a subject of A, when it’s perfectly possible that server B is on the opposite side of the world and provides a far woser UX than server A, or is even possible that server B might have defed’d from server A and thus B can not participate, or where the culture of community B is largely different than that of community A (eg.: B treats subject Z as a game; A treats it as a sport) (see also: beehaw vs everywhere else), is honestly one of the most stupidest ideas I’ve heard on the Fediverse. Yes, “most stupidest”, double superlative. That’s how bad it is.
The internet already routes naturally towards guiding people to where content might be. Users on B might link to content on A, at their leisure, but everyone is not forced to lose everything if server A dies or is beehaw. Ideally community members that take part of both A and B can reference both on webring C, because yes webrings are cool and awesome and they should return and they would solve much of this whole issue by raising awareness that A and B deal in subject Z, for the people who care.
And, ultimately, giving the ability to server A to essentially delete communities in server B feels ripe for abouse, and would lead towards a centralization of the Fediverse (exatly what we want to avoid!) simply because sheer statistics means server A sees more use and thus covers more domain space to start new conversations about subject Z, thus pre-emptively deleting them and coopting user activity from B.
Look, honestly: if you want Facebook ot Twitter, go back to them.
Look, honestly: if you want Facebook ot Twitter, go back to them.
This post was to talk about the merits/drawbacks of a potential change, and the constructive comments on the post have been helpful for that. Some of the other ‘solutions’ that have been posted here feel even more antithetical to the idea of decentralization (ex. redirecting upvotes, having communities follow other communities) so I was looking for a compromise that would address some of the annoyances without making the site another centralized platform. The intent was to allow users to choose how they want to link cross posts together, rather than having the community (or an app/frontend) make the decision for them. We’ve also been seeing users naturally gravitate to a few instances/communities, so I was looking for ways to redirect some of that traffic back to lesser known spaces.
Regardless, I appreciate the comment. Reading the perspectives on this post helped me see how locking the post completely would cause more issues and annoyances than it would help with. A simple “we are discussing X over on this post, feel free to join” seems like the better compromise.
