this post was submitted on 23 Oct 2024
50 points (100.0% liked)

Lemmy

12613 readers
3 users here now

Everything about Lemmy; bugs, gripes, praises, and advocacy.

For discussion about the lemmy.ml instance, go to [email protected].

founded 4 years ago
MODERATORS
[email protected]
50
Why don't any frontends add a way to view a united thread for a single url? (lemmy.dbzer0.com)
submitted 2 months ago by [email protected] to c/[email protected]
19 comments fedilink hide all child comments
 

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.

top 19 comments
sorted by: hot top controversial new old
[–] [email protected] 8 points 2 months ago (1 children)

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

[–] [email protected] 3 points 2 months ago (1 children)

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.

Most frontends already display available crossposts so you're not wasting anything more than grabbing all the comment sections as well.

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.

I don't agree at all. There's space for complex frontends which attempt to adjust the feed according to their own logic, as well as minimalistic frontends which follow the backend's design explicitly.

[–] [email protected] 1 points 2 months ago (1 children)

Most frontends already display available crossposts so you're not wasting anything more than grabbing all the comment sections as well.

We're talking about different things. I'm talking about the view you get when you first open an app - the 'home' screen that lists the posts. The API response for api/v3/post/list doesn't indicate whether something has been crossposted. You can see for yourself by getting a list of the 2 oldest posts on lemmy.ml:

curl --request GET --url 'https://lemmy.ml/api/v3/post/list?type_=Local&sort=Old&page=1&limit=2' --header 'accept: application/json' | jq .

For those 2 posts, you can only find out if they have crossposts by individually querying each post using the api/v3/post endpoint - the first one in that list would be:

curl --request GET --url 'https://lemmy.ml/api/v3/post?id=2' --header 'accept: application/json' | jq .

where crossposts would be in the 'cross_posts' array.

So for an app to display whether a posts listed on the main feed have crossposts, they'd have to query post/list, and then for each entry, query /post as well. This isn't the way these things typically work - there's normally a 1-to-1 relationship between an API query, and displaying the results of that query on the page. 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.

What you're talking about, is the view once a user has clicked on a post, not the post list. This provides the crossposts info. It's important to realise though, that the cross_posts array provides everything an app could want to display info about the other posts. It's not like they are pulling the data for one post, and then pulling data for each listed crosspost, so if they were to start getting the comments for each crosspost, that would be an extra effort (and a potential waste).

I don't agree at all. There's space for complex frontends which attempt to adjust the feed according to their own logic, as well as minimalistic frontends which follow the backend's design explicitly.

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. There are already some heavy desktop-orientated frontends, and none of them do what you're proposing. I think that the reason why, is because the proper way to do it is for the Lemmy's backend to be changed to provide the information they need in one go. That's unlikely to happen, but that doesn't mean that hacking away at an improper solution is necessarily the right answer (you just end up supporting a project that isn't supporting you in return).

[–] [email protected] 1 points 2 months ago (1 children)

[...]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.

[–] [email protected] 1 points 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).

[–] [email protected] 6 points 2 months ago* (last edited 2 months ago) (1 children)

IIRC Thunder has this, it's pretty neat

Edit:

https://lemmy.world/comment/12613445

[–] [email protected] 2 points 2 months ago (1 children)

Link plox

[–] [email protected] 3 points 2 months ago (1 children)

Not 100% sure if this is what OP was refuting to, but it is on F-Droid using the IzzyOnDroid repo.

https://f-droid.org/packages/com.hjiangsu.thunder/

[–] [email protected] 2 points 2 months ago* (last edited 2 months ago) (1 children)

That's a 404. Is there a git repo? I could use obtainium

[–] [email protected] 7 points 2 months ago (2 children)

Takes a few seconds to find it: https://github.com/thunder-app

But if I understand OPs point correctly Thunder doesn't seem to do that. As a matter of fact, at least by default, it doesent even compact the same posts.

And yeah, missing out on being able to see comments from multiple threads (hopefully with a noticibly marked community context, so its not lost) is really missing out on the possibilities given by fedi.

[–] [email protected] 2 points 2 months ago

Sorry, then I don't remember correctly. Maybe it's Summit then? I'll have to dig, I'm sure I've seen a client which does that

[–] [email protected] 1 points 2 months ago (1 children)

It seems to indeed be Thunder?

https://lemmy.world/comment/12613445

[–] [email protected] 3 points 2 months ago* (last edited 2 months ago) (1 children)

Does it show all comments in the same place like I suggest, or does one have to click on each crosspost to see them?

[–] [email protected] 1 points 2 months ago (1 children)

I don't have the app myself, hopefully someone can clarify

[–] [email protected] 5 points 2 months ago (1 children)

So I just installed it to check and it doesn't do that. It just makes crossposts a bit more visible.

However it looks like a neat app so I'll take it for a drive for a bit

[–] [email protected] 4 points 2 months ago

I just downloaded it myself to check. Indeed all comments are not there, but you can indeed see at least the number of comments on the crossposts and easily switch.

That's probably the closest we can get at the moment

[–] [email protected] 5 points 2 months ago

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.

[–] [email protected] 1 points 2 months ago* (last edited 2 months ago) (1 children)

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.

[–] [email protected] 1 points 2 months ago

This is what this post is suggesting, yes