Warning: Some posts on this platform may contain adult material intended for mature audiences only. Viewer discretion is advised. By clicking ‘Continue’, you confirm that you are 18 years or older and consent to viewing explicit content.
It’s a hard problem though - those are three different communities on tree different instances after all. The topic is “valid” for each of them and the local population of the instance, so it’s not like the servers can refuse the submission.
Doing filtering on the client would maybe be an option, but how would the client know which one of those three communities is the “main” and which other two should be filtered away.
The easiest would be to unsubscribe from two of them. Or even better, if people could stop cross-posting.
But we know people aren’t going to stop.
would the client know which one of those three communities is the “main” and which other two should be filtered away.
Imho, it should not “filter away” any of the entries. But rather merge all in the same “meta-post” (or whichever term is chosen). Show those posts a bit differently by aggregating the authors (with a clickable “…” ellipsis if the list is too long but that allows to show them if wanted), and when viewing the content either aggregate the comment threads or maybe add tabs to alternate between instances.
The easiest would be to unsubscribe from two of them. Or even better, if people could stop cross-posting.
Except cross-posting has a purpose. In that example, one of the posts was to beehaw while another was to lemmy.world. Beehaw defederated from lemmy.world so users on beehaw are only going to potentially see two of the three cross-posted posts. If they also defederate from lemmy.ml, those users would only see one.
So yeah, the solution is to unsubscribe from two of those communities because they’re essentially 3 completely different groups that just happen to have the same name and general focus. Either that or just get used to it.
Maybe instead of filtering the client could do a merge and list the comment trees under one header grouped by the community/magazine they are posted to?
It’s a hard problem though - those are three different communities on tree different instances after all. The topic is “valid” for each of them and the local population of the instance, so it’s not like the servers can refuse the submission.
Doing filtering on the client would maybe be an option, but how would the client know which one of those three communities is the “main” and which other two should be filtered away.
The easiest would be to unsubscribe from two of them. Or even better, if people could stop cross-posting.
But we know people aren’t going to stop.
Imho, it should not “filter away” any of the entries. But rather merge all in the same “meta-post” (or whichever term is chosen). Show those posts a bit differently by aggregating the authors (with a clickable “…” ellipsis if the list is too long but that allows to show them if wanted), and when viewing the content either aggregate the comment threads or maybe add tabs to alternate between instances.
I think this is kind of unfair.
Probably the local-most iteration followed by the time of posting/federating.
OP asked a question:
Answer: unsubscribe from 2 of the >3 substantially similar communities.
OP is that every bakery is selling bread.
Except cross-posting has a purpose. In that example, one of the posts was to beehaw while another was to lemmy.world. Beehaw defederated from lemmy.world so users on beehaw are only going to potentially see two of the three cross-posted posts. If they also defederate from lemmy.ml, those users would only see one.
So yeah, the solution is to unsubscribe from two of those communities because they’re essentially 3 completely different groups that just happen to have the same name and general focus. Either that or just get used to it.
Maybe instead of filtering the client could do a merge and list the comment trees under one header grouped by the community/magazine they are posted to?