Pagination controls aren't particularly useful for position-remembering clients.

[apiarian]

I'm trying to update Amaroq to remember timeline position between restarts or view refreshes. As such, I was hoping to be able to use the max_id and since_id parameters to control which toots we get back from the API.

However, these parameters don't seem to to work quite the way I expected. They are effectively unusable for this "remember timeline position" use case and we would have to resort to a sequential spam of the timeline API to get enough toots to get us down to the remembered one.

Take a peek at the head of the timeline.

http 'https://toot.cafe/api/v1/timelines/home?limit=10' 'Authorization: Bearer foobar' | jq '.[] | .id'
"99067141923265252" # will get this in the second request
"99067078945904879"
"99067065159308178"
"99067009582024915"
"99066983051474906"
"99066982760931898"
"99066949753677356" # will be asking for max_id this in the first request
"99066901008261781" # will get this in the first request; will be asking for since_id this in the second request
"99066834960670058"
"99066422645335901"

Pretend like we're starting up and we remember having seen 99066949753677356 at the top of our timeline:

http 'https://toot.cafe/api/v1/timelines/home?limit=3&max_id=99066949753677356' 'Authorization: Bearer foobar' | jq '.[] | .id'
"99066901008261781"
"99066834960670058"
"99066422645335901"

Issue 1 note that the max_Id isn't actually in the list of returned statuses. So if we wanted to show a view of all the things that the user was looking at before and we stored the id of the topmost toot, we would somehow still need to get one more toot from the timeline to restore the previous state.

Now lets say we want a page of toots since the topmost one we're currently seeing:

http 'https://toot.cafe/api/v1/timelines/home?limit=3&since_id=99066901008261781' 'Authorization: Bearer foobar' | jq '.[] | .id'
"99067141923265252"
"99067078945904879"
"99067065159308178"

Issue 2: instead of getting the next three messages after the one we asked for, we get three messages that are after the one we asked for, starting with the head of the timeline. So to get the actual "previous" page, we'd have to page through a bunch of requests.

I guess what would be nice is a new pair of parameters like

• up_to_id=[id] which returns a page of results with the first one having id [id]
• after_id=[id] which returns a page of results with the last one being the exact next toot after (newer than) [id].

---

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

[unarist]

Yeah, after_id or something will also be useful for #3473 (same as @Gargron's suggestion on there?)