Incrementally read a post's new / unread comments

[wiki-me]

Is your proposal related to a problem?

It's hard to incrementally read a post, as new comments are added it's hard to find the new comments.

Describe the solution you'd like

Provide an option to only show comments that are "read", these will be comments that were clicked on (RES has this feature)

Also something like this extension , which shows when new comments are added to reddit posts is also nice.

Describe alternatives you've considered

Maybe provide it as default with no option?

Additional context

Dessalines saw this post where i criticised lemmy and he asked i will open issues.

[dessalines]

We could absolutely create a comment_read table, and do some of the same things we've done for post_read.

Some difficulties tho:

• Since these are trees and not flat like posts, it'd be hard to do anything other than highlight the new comments.
• I don't really want to go through the trouble of watching what content the user is actually looking at: IE checking which comments are within the users view screen. That wouldn't work well for other clients either. If I did this, I'd probably do the simple thing and assume that after you've clicked into a post, you've then viewed all the comments for it at that point in time. Its incorrect of course, because you might not have scrolled through everything, but its at least simple.

[ViableSystemModel]

I've thought about the issue of trying to track which comments are read for a while. Some sites will highlight unread comments and unhighlight them in real time as a way to draw attention to what point on the screen a comment needs to reach to gain focus. Alternately, a Twitter-like threading system would be able to handle per-comment reads pretty trivially. It may even be possible on a mobile-only client to have a gesture-based navigation where each gesture moves one comment into the hierarchy or one comment down.

Regardless, I personally would get a lot of use out of marking everything as read automatically until I navigate away. It may even be possible indicate unread comments from within the post feed. Though features like that can lead to engagement for its own sake and be coercive at scale

[dessalines]

Since we have comment trees, highlighting unread comments, and showing a X new comments next to the total comments in the post listing views, is the best we could do.

[wiki-me]

I don't really want to go through the trouble of watching what content the user is actually looking at: IE checking which comments are within the users view screen. That wouldn't work well for other clients either.

I don't use that feature too, i just go with res manual "click to read", i don't know if anyone would want this so i think it is safe to drop.

If I did this, I'd probably do the simple thing and assume that after you've clicked into a post, you've then viewed all the comments for it at that point in time. Its incorrect of course, because you might not have scrolled through everything, but its at least simple.

It's better then the situation now, but if a post has a lot of comments and it is on a subject i would like to try to develop some expertise on i will save the post and incrementally read it as time passes , so i really think "click to read" is a game changer.

Though features like that can lead to engagement for its own sake and be coercive at scale

My attitude is that the usability of the software should not be degraded just so some users will not misuse it (the dream is to have the emacs/vim of social media, powerful and customizable , i am pretty sure lemmy won't go to that direction, if that will happen it will be a new project or maybe a new lemmy frontend). commercial social media provides plenty of restrictive platforms.

[dessalines]

Again I don't know of a solution to this, and think it should probably be closed. Since comments live in trees, there's not a good way to show new things near the top, besides the existing comment hot sort.

[wiki-me]

Since comments live in trees, there's not a good way to show new things near the top, besides the existing comment hot sort.

You could just highlight the comments:

(that's the extension i mentioned in the issue).

RES basically does not show comments you clicked on after applying the "not read" filter (which can be set as the default) and telling him not to mark post you "saw" as read. after that if a comment was read but it's child comment was not it is sort of white and transparent:

I can provide details about how to configure it (you can message me on lemmy).

One of the things social media is accused of is creating shallowness , this could help as it will help you go in depth about certain topics, and it does not have to be on by default and the setting to activate it could link to the docs saying how it works.

[dessalines]

We don't have a comment_read table, and only store unread_comments as an aggregate, not on individual comments. We also have a mark class added to new comments by time, but not specifically unread.

[Nutomic]

There is post_read table which includes a timestamp. It should be easy to highlight all comments which were created after that timestamp.

[dessalines]

Might be doable if we add a last_read_time to this table:

[wiki-me]

I really dislike the whole method of marking only the comments added since last visit (tildes.net uses it), Usually there is some post that ends about getting something like 200-300 comments, if it is a subject where i think it is relatively important to try to develop in depth knowledge i would bookmark it, and over time slowly read comments (somehere around 30-100 comments a session). That won't work with "new comments since last visit" approach but works with "click to mark as read" approach of RES.

If there is concern about this taking too much server space it could be stored in local storage and then backed up to dropbox or google , this is what RES does and you can add backup to nextcloud instead or also.

[dessalines]

@phiresky which do you think would be the better way to go DB-wise:

• adding a comment_read table, or
• using the person_post_aggregates with a timestamp of last_read_time

[phiresky]

I feel like maybe this should be a UI / frontend thing? Same as RES. How to define what is read and what not heavily changes based on the UI of the frontend. Some frontends might want to mark read automatically when scrolling, some might only do it with manual interaction, some might just want to display "new since last visit" as suggested above.

Also, it's not clear to me how this feature would interact with comment trees - the API would still need to send at least some read comments in order to not break the trees but then the UI would have to display those differently? That might need new filters for the fetch queries otherwise people will complain about only getting 0 or 1 comments back from the api when they've already read everything. These new filters would also impact the server performance and need new considerations for indexing and pruning of this data.

In general, I feel like an approach like comment_read would add a lot of complexity to the server for a problem that has multiple different competing solutions where it's really a user preference of what should happen.

Adding a last_read_time might make sense and personally I do use RES and HNES to highlight "new comments since last visit" but it seems like it wouldn't fulfill what wiki-me or ViableSystemModel want.

In my opinion this issue should be moved/recreated on lemmy-ui and be implemented purely client-side. For lemmy-ui it might consist of auto-marking comments read on click, highlighting new comments on reload, and storing a LRU cache of the last 100 {[post_id]: {read_comments: number[]}} in localStorage. On e.g. mobile clients it would look very different anyways. Then you wouldn't have cross-device sync but that doesn't seem too important to me.

[micahmo]

Sorry for digging up an old issue, but I was just looking for a way to highlight unread comments in Thunder and stumbled across this issue. The easiest thing for us would be to have a flag on comment saying whether its read or not. Adding a last read time would require us to remember when the post was read (and anything less than that would be entirely client-specific). I am totally fine with the current approach of marking all comments as read when the post is opened, as was done for the counts in #2134.

[MaximilianKohler]

There's a related lemmy-ui issue that has more info/discussion: LemmyNet/lemmy-ui#2136

Since these are trees and not flat like posts, it'd be hard to do anything other than highlight the new comments.

I don't really want to go through the trouble of watching what content the user is actually looking at: IE checking which comments are within the users view screen. That wouldn't work well for other clients either. If I did this, I'd probably do the simple thing and assume that after you've clicked into a post, you've then viewed all the comments for it at that point in time. Its incorrect of course, because you might not have scrolled through everything, but its at least simple.

There is post_read table which includes a timestamp. It should be easy to highlight all comments which were created after that timestamp.

This works very well. It's not a problem at all. It's vastly better than the current "a comment that's newer than 10 minutes will be highlighted". It appears this issue has been delayed due to "perfect being the enemy of good".

Some frontends might want to mark read automatically when scrolling, some might only do it with manual interaction, some might just want to display "new since last visit" as suggested above

Couldn't they just overrule this feature then? This is at least a very good default/starting point.

For lemmy-ui it might consist of auto-marking comments read on click

I definitely don't want to be manually clicking every comment, so that should not be the default method.

@wiki-me See my comment here: LemmyNet/lemmy-ui#2136 (comment) - implementing that in a 3rd party addon might be the way to go, but might be difficult due to all the different lemmy URLs.

[Nutomic]

So it looks like we already store the last read time in post_read.published. But that still needs to be exposed in the api (as part of PostView).

[wiki-me]

I definitely don't want to be manually clicking every comment, so that should not be the default method.

Thats a subjective preference, at least there should be some survey about this i think. gmail (probably the most popular email client in the world) and every other email client that i think of uses click to mark as read (and even with an option to mark as unread). piefed also uses CTMAR when subscribing to new comments.

What might be prolematic with highlighting comments from last visit is that it might create psychological pressure to read all the comments (something like FOMO). because if you won't read all the comments you miss some out on your next visit. i get that feeling when using tildes.net. It might make lemmy more addictive which might be problematic for younger users which might not have well developed self control.