I feel like there’s an easy win to keep up with the fragmentation of discussions without waiting for some implementation of this feature request.

All a frontend needs to do is group all posts with the same URL together and display all their comments in the as one unified comment section. If you reply to the OP, you can either choose which community the comment goes to, and maybe set a default as well.

This functionality should be an extra switch for the frontend, so that the user can disable it and see individual posts.

This also nicely avoids not knowing how to deal with moderation, as each community moderator still maintains control.

Comments from blocked communities would not appear ofc.

This would both prevent seeing the same post multiple times on your feed, but also drive view to smaller communities where comment in their sections are ignored.

  • db0@lemmy.dbzer0.comOPEnglish
    1·
    2 months ago

    […]Looping through the list you’ve been given, and making extra queries adds complexity and delay, when the expectation from the user is that this list should appear pretty quickly.[…]

    While you’re correct about this, this could be handled dynamically. Simply fetch the list of posts quickly as usual, and then start polling for crossposts in the background and if any two appear in the current frontpage the user is seeing, merge them.

    My counter to that, would be that if you aren’t using the API in the way the developers expected, your app has ceased to be frontend, and is instead its own program that’s scraping data from it.

    Not at all. That’s not what scraping means.

    I just completely disagree with the idea that a frontend should stick to what the backend design is, especially for a FOSS project.

    • Andrew@piefed.social
      1·
      2 months ago

      We appear to be at an impasse.

      I’ve recently been adding an API to PieFed and forked the Lemmy Thunder app as way to test things. My position on this comes from tinkering with Thunder - I can’t claim to understand it all, but it seems to me that the API and the app are fundamentally interlinked in ways that make being too adventurous with it difficult. For that app, it would break the existing paradigm to do the kinds of things you’re talking about. Thunder uses its own version of an API client (written in Dart), but I’ve assumed that other apps are written in a similar way, and are essentially wrappers around Lemmy’s JavaScript client.

      Hopefully, someone else with more app development experience will contribute to this discussion, and set one of us right (I don’t mind if it’s me that’s wrong).