# 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 10
# self = https://watcher.sour.is/conv/23w3ova
@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? 🤔
@prologic I would like to see "header" lines in twtxt.txt parsed.\n\nPersonally I started looking at some twtxt files with curl and saw information about avatar images.\n\nI assumed that to be sort of standard and mentioned my avatar image in my stackeffect.txt. But it was not "avatar.png".\n\nLater I saw in logfiles that the info was totally ignored and instead several "avatar.png" locations were tried by the pulling side.\n\nWhen information in "header" of twtxt file were respected one could easily change avatar file to one with a new filename and there would be no caching problem.
@prologic I would like to see "header" lines in twtxt.txt parsed.
Personally I started looking at some twtxt files with curl and saw information about avatar images.
I assumed that to be sort of standard and mentioned my avatar image in my stackeffect.txt. But it was not "avatar.png".
Later I saw in logfiles that the info was totally ignored and instead several "avatar.png" locations were tried by the pulling side.
When information in "header" of twtxt file were respected one could easily change avatar file to one with a new filename and there would be no caching problem.
@stackeffect They _actually_ are parsed by yrand but what happens here that you're observing is:\n\n- When we first fetch a feed we don't know anything about it, so we create a mostly empty Twter{} object\n- We fill that Twter{} object with the "nick" of alias the follower is following you as and it's "url"\n- Next we try to discover an avatar that might be next to the feed, below it or at the domain root, etc\n- Then we parse your feed, read your feed's metdata and all twts\n- If your feed's metadata advertised an avatar = we use that instead
@stackeffect They _actually_ are parsed by yrand but what happens here that you're observing is:
- When we first fetch a feed we don't know anything about it, so we create a mostly empty Twter{} object
- We fill that Twter{} object with the "nick" of alias the follower is following you as and it's "url"
- Next we try to discover an avatar that might be next to the feed, below it or at the domain root, etc
- Then we parse your feed, read your feed's metdata and all twts
- If your feed's metadata advertised an avatar = we use that instead
@stackeffect They _actually_ are parsed by yrand but what happens here that you're observing is:
- When we first fetch a feed we don't know anything about it, so we create a mostly empty Twter{} object
- We fill that Twter{} object with the "nick" of alias the follower is following you as and it's "url"
- Next we try to discover an avatar that might be next to the feed, below it or at the domain root, etc
- Then we parse your feed, read your feed's metdata and all twts
- If your feed's metadata advertised an avatar = we use that instead
@prologic Are you sure? The avatar file announced in my twtxt.txt was never fetched. Only non existing default avatars were fetched.
@stackeffect You are right! 🤦♂️ The logic in GetExternalAvatar() was a bit off. it would use the already cached avatar, previously found from an initial feed cache cycle of a new feed, but then never look at the .Avatar field of the feed's metadata preamble and "override" what it had found before. I've fixed that now 🤞 and rolling out to _at least_ my pod here at twtxt.net so let's see what happens 🤗 Thanks for pointing this out! 🤟
@stackeffect You are right! 🤦♂️ The logic in GetExternalAvatar() was a bit off. it would use the already cached avatar, previously found from an initial feed cache cycle of a new feed, but then never look at the .Avatar field of the feed's metadata preamble and "override" what it had found before. I've fixed that now 🤞 and rolling out to _at least_ my pod here at twtxt.net so let's see what happens 🤗 Thanks for pointing this out! 🤟