# 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 15
# self = https://watcher.sour.is/conv/vx5l2ja
So... my pod twtxt.net now **correctly** uses it's cached avatar to serve avatars. The _only_ problem (_which was always a problem before_) was there has never been a mechanisms to "update the cached copy". For example @adi display as the old auto-generated Avatar that his pod generated some time ago. It's now clearly out-of-date 😂
But I'm pretty happy with the uncommitted changes I have running here live now, so I _might_ cleanup my changes and apply them as nice commits and push them out soon/today...
So... my pod twtxt.net now **correctly** uses it's cached avatar to serve avatars. The _only_ problem (_which was always a problem before_) was there has never been a mechanisms to "update the cached copy". For example @adi display as the old auto-generated Avatar that his pod generated some time ago. It's now clearly out-of-date 😂
But I'm pretty happy with the uncommitted changes I have running here live now, so I _might_ cleanup my changes and apply them as nice commits and push them out soon/today...
@prologic could the mechanism be to just periodically update the avatars, even if just once a day?
@eldersnake Yes it _could_ very well be that simple, but I _think_ we can do one better. We _can _ for instance look at the ETag (_if any_) of the Avatar the pod downloaded and compare it with the one we have stored. The question is where do I store this bit of info. We _could_ also look at the "Cache" headers, but I'd honestly rather avoid that at all. But as I write this I realize, the question still remains, when do we re-check 😂
@eldersnake Yes it _could_ very well be that simple, but I _think_ we can do one better. We _can _ for instance look at the ETag (_if any_) of the Avatar the pod downloaded and compare it with the one we have stored. The question is where do I store this bit of info. We _could_ also look at the "Cache" headers, but I'd honestly rather avoid that at all. But as I write this I realize, the question still remains, when do we re-check 😂
@eldersnake What if I do two things:
- Advertise a user/feed's Avatar as <pod_url>/<user>/avatar#<etag>
- Periodically once per day re-download and compare advertised Avatar(s) on feeds during feed cache cycles
- On _every_ feed cache cycle (_since we already read the fee'd metadata_) check to see if the advertised Avatar has changed
Sound like a plan? 🤔
@eldersnake What if I do two things:
- Advertise a user/feed's Avatar as <pod_url>/<user>/avatar#<etag>
- Periodically once per day re-download and compare advertised Avatar(s) on feeds during feed cache cycles
- On _every_ feed cache cycle (_since we already read the fee'd metadata_) check to see if the advertised Avatar has changed
Sound like a plan? 🤔
@eldersnake What if I do two things:\n\n- Advertise a user/feed's Avatar as <pod_url>/<user>/avatar#<etag>\n- Periodically once per day re-download and compare advertised Avatar(s) on feeds during feed cache cycles\n- On _every_ feed cache cycle (_since we already read the fee'd metadata_) check to see if the advertised Avatar has changed\n\nSound like a plan? 🤔
@eldersnake Actually I think we can do 1 and 3 — This will even work for any other feed not hosted on a yarnd instance 👌
@eldersnake Actually I think we can do 1 and 3 — This will even work for any other feed not hosted on a yarnd instance 👌
@eldersnake Oh gawd 🤦♂️ This is _tricky_ too 😂 Need to _think_ about this some more...
@eldersnake Oh gawd 🤦♂️ This is _tricky_ too 😂 Need to _think_ about this some more...
@prologic Sounds good. I was thinking about the whole comparing thing before, on a feed cache grab as you say, since that _is_ fetched every time, makes sense to use the metadata as a kind of baseline check at least.