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.
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?
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.
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.
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?
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.