Provide an option to return only unread entries in a timeline

[aaronpk]

By default, a call to retrieve the timeline will still return already-read entries. However, in certain cases, such as if there are lots of unread entries and you start reading them from newest to oldest, or if somehow an entry was added far back in the timeline, you might want to see only the unread items.

This could be accomplished with an additional parameter to the timeline API call.

[EdwardHinkle]

I think this is something I’d like to revive discussion on! I would love to implement this in Indigenous.

I guess the question is, is this as simple as sending something like ?read=false to say not to send posts that are read, or is this a parameter that affects more than just read/unread status, if we need more robust filtering?

[aaronpk]

I'm adding initial support in Aperture for this. I'm taking the easy way right now, which is doing this as a one-off parameter. Since there are already corresponding query parameters for some of the Microsub properties (like paging), I'm adding a new parameter is_read=false to the query string which tells Aperture to only return unread entries. This matches the Microsub property _is_read on entries.

By default, a timeline call will return all entries. If you include is_read=false then only unread entries will be returned.

[sebsel]

Just curious: will is_read=true give you all the read entries? Can't think of a use case right now, but it would be something I expect with a boolean like that.

[aaronpk]

I only implemented is_read=false, any other value or omitting it will include both read and unread. I suppose it could be useful to see only the read entries if you come back to a channel that has a ton of stuff added and you want to find something you saw before but don't want to scroll thru all the new stuff yet. Not sure how useful that actually is though, but it would be easy to add to the server.

[EdwardHinkle]

Yeah, I agree. I think searching through the channel would probably be more valueable for that use case

[jackjamieson2]

I just implemented this in Yarns following the same pattern as Aaron described above. I similarly did not implement anything for is_read=true

[swentel]

I've been thinking about this a bit too a bit the last few days. I don't see /that/ much value in passing a parameter per timeline. If you click on the timeline, new ones usually are on top.

Another option I'd like to experiment with (which I've seen in a couple of other readers: make the 'start page' the list of unread items. From the perspective of indigenous for android. The 'start' page is currently the list of channels. Instead, I would add an option to make the start page the screen where the unread items are shown across all channels. This could either be a dedicated new action 'unread', or maybe using the same param suggested above with 'timeline', but without an id of the channel. I can live with both tbh.

If no unread items, I would automatically switch to get the list of channels.

Thoughts?

[EdwardHinkle]

Two things: first, an is_read is definitely needed. You don’t know how someone will use their channels. For example I have a “Saved” channel where I use it as a Read it later channel. I do NOT read it chronologically, instead when I get the chance I scroll to a post that interests me and I read it. In those situations you are not promised unread at the top, and you might not want read posts

Second, I do think your “global” unread is an interesting one. Although as I haven’t built a server I’m not sure of the complexity, but there is a precedent to use the term global for this as that’s what is used to mute or block someone across all channels

[EdwardHinkle]

@swentel since the "global unread" is similar but different because an endpoint doesn't exist for that, I've went ahead and moved it into it's own thread: #37

Also, funny thing to note, I am doing a similar homepage refresh for the iOS app (in it's new Remark incarnation) where it shows unread posts on the homepage, but I will also be grouping them underneath their respective channels. So it'll show "Notifications" and the first 5 new notifications, then "IndieWeb" and the first 5 new indieweb posts, etc.

[swentel]

So it'll show "Notifications" and the first 5 new notifications, then "IndieWeb" and the first 5 new indieweb posts, etc.

That would mean potentially a lot of calls. Having one call would be less heavy then for the server, but the microsub item should also contain the channel information then, something which might be interesting for #37

[dshanske]

If I read the code, Indigenous for Android supports this.