# 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 21
# self = https://watcher.sour.is/conv/ybzvcta
This one
This one
@prologic
Thank you, that's the correct one.
Still I have this in my logs (first access of "eleven" by yarnd):
ip.ip.ip.ip - - [21/Oct/2021:20:05:36 +0000] "GET /eleven.txt HTTP/2.0" 200 344 "-" "yarnd/0.2.0@46bea3f (Pod: twtxt.net Support: https://twtxt.net/support)"
ip.ip.ip.ip - - [21/Oct/2021:20:05:36 +0000] "HEAD /avatar.png HTTP/2.0" 200 0 "-" "yarnd/0.2.0@46bea3f (Pod: twtxt.net Support: https://twtxt.net/support)"
And I guess without avatar.png sitting there I would have seen even more requests like /eleven.txt/avatar.png.
I've copied stackeffect.png to avatar.png to make yarnd happy when accessing stackeffect.txt.
So in this setup yarnd fetched eleven.txt along with avatar.png which belongs to another twtxt. This feels buggy.
@prologic \nThank you, that's the correct one.\n\nStill I have this in my logs (first access of "eleven" by yarnd):\n\nip.ip.ip.ip - - [21/Oct/2021:20:05:36 +0000] "GET /eleven.txt HTTP/2.0" 200 344 "-" "yarnd/0.2.0@46bea3f (Pod: twtxt.net Support: https://twtxt.net/support)"\nip.ip.ip.ip - - [21/Oct/2021:20:05:36 +0000] "HEAD /avatar.png HTTP/2.0" 200 0 "-" "yarnd/0.2.0@46bea3f (Pod: twtxt.net Support: https://twtxt.net/support)"\n\nAnd I guess without avatar.png sitting there I would have seen even more requests like /eleven.txt/avatar.png.\n\nI've copied stackeffect.png to avatar.png to make yarnd happy when accessing stackeffect.txt.\n\nSo in this setup yarnd fetched eleven.txt along with avatar.png which belongs to another twtxt. This feels buggy.
@stackeffect Youโre right it does feel buggy now. Given the metadata spec we just recently formalized is it worth dropping avatar discovery altogether?
@stackeffect Youโre right it does feel buggy now. Given the metadata spec we just recently formalized is it worth dropping avatar discovery altogether?
@prologic I reckon the metadata should certainly be honored. Only if that is unsuccessful fall back to the trial and error search. Maybe also limit the attempts to find an avatar to a smaller subset of filenames. Do you have any numbers on (un)successful filename discoveries?
@prologic \n\nNo, it would be sufficient to skip avatar discovery when metadata does contain an avatar.
@prologic
No, it would be sufficient to skip avatar discovery when metadata does contain an avatar.
I think itโs easier if I just drop the fallback. Itโs a chicken/egg type thing anyway ๐
I think itโs easier if I just drop the fallback. Itโs a chicken/egg type thing anyway ๐