Adding fetching of statuses in lexicographycal order (by status ID)

[cage2]

Hi!

Seems to me (correct me if i am wrong) that the timeline rest API just fetches the roots of a tree of statuses (a tree where each not root node is a reply of a parent status). But i think would be just great to be able to fetch the statuses in plain lexicographical order using ID. The API could just use the same parameters of the timeline API (min-id, max-id etc.). This could be very useful the get the non-root status when the root is not available (for example if the user of the client deleted it from their local database of statuses).

Bye!
C.

[ClearlyClaire]

“Seems to me […] that the timeline rest API […]. The API could just use the same parameters of the timeline API […]”

I'm not sure which API you suggest changing?

Also, threads are internally just chains of replies, if one toot is deleted, the chain is broken and cannot really be recovered (this is not entirely true, toots also have a conversation id, but that can change anytime at any participant's will, even if they logically belong to the same thread)

[cage2]

On Thu, May 21, 2020 at 05:03:23AM -0700, ThibG wrote: Hi! Thank you for your reply!

“Seems to me […] that the timeline rest API […]. The API could just use the same parameters of the timeline API […]” I'm not sure which API you suggest changing?

Sorry i was not able to express my proposal very well. :( My question is: seems to me that the GET timeline API https://docs.joinmastodon.org/methods/timelines/ (Public but even the home too, i believe) Returns only the "root" statuses (status with no 'reply-to-id' field) in chronological order (depending of various parameters like min-id or max-id etc). If this (only root messages) is true (and intended) i propose to add an API with the same parameters of the ones above that returns all the statuses in lexicographical order (by Id) regardless if they are root or not.

Also, threads are internally just chains of replies, if one toot is deleted, the chain is broken and cannot really be recovered

This is true but i would be happy just to get the single status that is a reply when i do not know the root. Let' say the server i am connected to have a new root message with id = "1", now i download it on my client and, after read i delete it (locally on my client not on the server) so that the client will never re-download or consider in the future. Now another person post a reply to "1". How can my client get this reply if the root has gone and the timeline API will download only the root messages? Of course i will not download again the message with id 1 because i deleted it (on the client). This is because i propose a new API to get all the status. Thank you again for reply! I hope my question is more clear now! :) Bye! C.

[ClearlyClaire]

Ah, public timelines only include toots which aren't replies and toots that are self-replies, it does not include any other kind of replies. The home timeline includes only toots that aren't replies, or that are replies to someone you follow, it's not a “root toot” thing. Also, toots which are in the Home TL but for which the parent toot gets deleted remain in the Home TL.

[cage2]

Hi ThibG!

Ah, public timelines only include toots which aren't replies and
toots that are self-replies, it does not include any other kind of
replies. The home timeline includes only toots that aren't replies,
or that are replies to someone you follow, it's not a “root toot”
thing. Also, toots which are in the Home TL but for which the parent
toot gets deleted remain in the Home TL.

So it is actually much more complicated than my initial guess! :D

Unfortunately for the client i am writing (in case you are curious:
http://notabug.org/cage/tinmop) this is still not enough :( So i think
my humble proposal still apply (and i also believe could be useful for
other people not just me, i am not so selfish! ;-)):

To summarize, a GET endpoint to fetch all the the public messages and
one to fetch the whole home timeline (toots from people you follow and
all the replies) ordered by id and with the same parameters and
semantics of the timeline endpoints.

Thank you very much for your attention! :)
Bye!
C.

[cage2]

On Thu, May 21, 2020 at 11:04:18AM -0700, cage2 wrote: Hi! I was even thinking that there is no need for a different API; just adding a new parameter to existing timeline endpoints would suffice. Bye! C.