# 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/z2wiqfq
Btw, @prologic, I reckon the yarnd generated archive feed URLs are not stable and thus kind of contradict the Archive Feeds Extension, which states:
> Once they are made public, [archive feeds] are supposed to be left alone and wonβt receive further updates. Deletion or editing is still allowed, but feed authors should not expect clients to retrieve archived feeds on a regular basis (or at all).
Looking at your main feed URL https://twtxt.net/user/prologic/twtxt.txt, the prev points to https://twtxt.net/user/prologic/twtxt.txt/1 and that in turn links to https://twtxt.net/user/prologic/twtxt.txt/2. Here the chain ends. That means whenever a new archive feed is generated, the URLs change. Or viewed differently, the URL suddenly provides a differnt content. That probably causes clients to not update their caches properly, because they always see the same β¦/twtxt.txt/1 in the main feed's prev and think that nothing changed, which contradicts the promise of the spec.
@lyse Yeah as we discussed in the call, I _think_ I might switch this to use a UNIX timestamp instead with seconds precision. Because the feeds' metadata are dynamically generated I have to do handle feed rotation and linking with the prev field more programatically I guess π
@lyse Yeah as we discussed in the call, I _think_ I might switch this to use a UNIX timestamp instead with seconds precision. Because the feeds' metadata are dynamically generated I have to do handle feed rotation and linking with the prev field more programatically I guess π
@lyse Yeah as we discussed in the call, I _think_ I might switch this to use a UNIX timestamp instead with seconds precision. Because the feeds' metadata are dynamically generated I have to do handle feed rotation and linking with the prev field more programatically I guess π
@lyse Yeah as we discussed in the call, I _think_ I might switch this to use a UNIX timestamp instead with seconds precision. Because the feeds' metadata are dynamically generated I have to do handle feed rotation and linking with the prev field more programatically I guess π