Frontends generate the main feed by querying api/v3/post/list. This doesn't provide any crosspost info - for that you have to go into the post itself by querying api/v3/post. As such, frontends would have to do a fair bit of extra work to wrangle the required information for a main feed that combined crossposts. The only attempt I've seen at doing this was in a dev branch of Tesseract.

I'd argue that you have a problem as soon as you start saying 'frontends need to do some extra work' - it breaks the dynamic between backends and frontends. Backends should be big, complicated things, worked on by people familiar with the project, to provide all the logic, whereas frontends should be light, relatively easy to write, runnable on devices with limited resources, and mostly focused on how the information provided to them should be displayed. They should store the user's preferences, and login details, and that's it - everything else should come from the backend.

As for combining comments, this can lead to fraught situations. This link was posted to both 'cars' and 'fuckcars'. This link was posted to both 'taylorswift' and whatever-the-fuck 'barelower4thwomenmusic' is: so the comments for a music video would be from Taylor Swift fans, as well as from people with a foot fetish. Moreover, if this is the expected behaviour, trolls can use it to get up to no good, and make a bunch of comments appear in a new crosspost to a community subscribed to by people guaranteed to disagree with them.

I think anyone trying to 'fix' this issue will run into the fact that certain assumptions have been made in a software's design, and those assumptions determine how database relationships are formed. The real answer may lie in something like 'ClubsAll', rather than an attempt to fundamentally redesign existing platforms.

In the meantime, crossposting is being actively encouraged. Movie news is posted to 5 different communities, open-source news is posted to 8, Taylor Swift music videos are posted to 12. The useful crossposts (one that help you discover a new community) are in the minority - most of it just ends up being annoying. And it's because there this idea, that some time in the future, there'll be a tech solution to make it less annoying, and the suggestion that maybe you should just pick the community you like and post to that, is - to me - surprisingly unpopular. Not only might this solution never come, but anything URL-based can't do anything about the same question being posed to 'nostupidquestions' and both 'asklemmys', or with an image being uploaded and posted to one community, and then re-uploaded to post to another.

This whole thing feels like trying to find a tech solution to what I see as a user problem of mindless posting to as many communities as you can find. To be honest, it's a problem that makes me a bit disillusioned (I saw a post the other day that was posted to both 'interestingasfuck' and 'mildlyinteresting', and thought - if that's the community names we're going with, and this behaviour is apparently okay, then we may as well be on Reddit).

IIRC Thunder has this, it's pretty neat

Edit:

https://lemmy.world/comment/12613445

I love this idea. I feel like it would give Lemmy some of the old forum magic of long historical threads.

Imagine every time a repost happens the comments are additive instead of separate. It would keep posts and conversations alive to have them continue to surface and be upvoted anew.

I really think you’re into something brilliant.

My question is why is this a backend universal question? This should be a per user/instance frontend solution; meaning I would curate my communities into a group on @lemmy.world and it’s unique to me.

Now I should be able to export or share my groupings if I want, and it should be read-only in the sense that if I post, I post to a single community and not the group as a whole. The only thing a backend should do is allow the frontend to retrieve posts from multiple communities in one call.

In other words, keep it simple.