# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 6
# self = https://watcher.sour.is/conv/opw257a
My thoughts about pagination (paging)
Following the discussion about pagination (paging) I think that's the right thing to do.
Fetching the same content again and again with only a marginal portion of actually new twts is unbearable and does not scale in any way. It's not only a waste of bandwidth but with increasing number of fetchers it will also become a problem for pods to serve all requests.
Because it's so easy to implement and simple to understand, splitting twtxt file in parts with next and prev pointers seems a really amazing solution.
As in RFC5005 there should also be a meta header pointing to the main URL, e.g. current or baseurl or something like that. This way hashes can calculated correctly even for archived twts.
Yes, Iโm also pretty confident that this is a good extension. If I have the time and energy (maybe I wonโt), Iโll open a PR with a formal draft for this on the weekend. ๐
Yes, Iโm also pretty confident that this is a good extension. If I have the time and energy (maybe I wonโt), Iโll open a PR with a formal draft for this on the weekend. ๐
Yes, Iโm also pretty confident that this is a good extension. If I have the time and energy (maybe I wonโt), Iโll open a PR with a formal draft for this on the weekend. ๐