# 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 60515 # self = https://watcher.sour.is?uri=https://twtxt.net/user/prologic/twtxt.txt&offset=57115 # next = https://watcher.sour.is?uri=https://twtxt.net/user/prologic/twtxt.txt&offset=57215 # prev = https://watcher.sour.is?uri=https://twtxt.net/user/prologic/twtxt.txt&offset=57015
7 to 11.# url = comment to their feed to indicate the new location and thus change the "Hashing URI" used for Twts from _that_ point onward.# direction = [append|prepend]
7 to 11.# url = comment to their feed to indicate the new location and thus change the "Hashing URI" used for Twts from _that_ point onward.# direction = [append|prepend]
yarnd to see how many things would break and how many assumptions there are around the idea of "Content Addressing"; here's where I'm at so far:yarnd here.
yarnd to see how many things would break and how many assumptions there are around the idea of "Content Addressing"; here's where I'm at so far:yarnd here.
(replyto:…) proposal (_location addressing vs. content addressing_) is that you just introduce a similar problem down the track, albeit rarer where if a feed changes its location, your thread's "identifiers" are no longer valid, unless those feed authors maintain strict URL redirects, etc. This potentially has the long-term effect of being rather fragile, as opposed to what we have now where an Edit just really causes a natural fork in the thread, which is how "forking" works in the first place.(replyto:…) proposal (_location addressing vs. content addressing_) is that you just introduce a similar problem down the track, albeit rarer where if a feed changes its location, your thread's "identifiers" are no longer valid, unless those feed authors maintain strict URL redirects, etc. This potentially has the long-term effect of being rather fragile, as opposed to what we have now where an Edit just really causes a natural fork in the thread, which is how "forking" works in the first place.yarnd has a couple of settings with some sensible/sane defaults:
$ ./yarnd --help 2>&1 | grep max-cache
--max-cache-fetchers int set maximum numnber of fetchers to use for feed cache updates (default 10)
-I, --max-cache-items int maximum cache items (per feed source) of cached twts in memory (default 150)
-C, --max-cache-ttl duration maximum cache ttl (time-to-live) of cached twts in memory (default 336h0m0s)
yarnd pods by default are designed to only keep Twts around publicly visible on either the anonymous Frontpage or Discover View or your Timeline or the feed's Timeline for up to 2 weeks with a maximum of 150 items, whichever get exceeded first. Any Twts over this are considered "old" and drop off the active cache.yarnd's design (_nothing particularly to do with Twtxt per se_) that I've to this day stuck by -- Even though there are _some_ 😉 that have different views on this 🤣
yarnd has a couple of settings with some sensible/sane defaults:
$ ./yarnd --help 2>&1 | grep max-cache
--max-cache-fetchers int set maximum numnber of fetchers to use for feed cache updates (default 10)
-I, --max-cache-items int maximum cache items (per feed source) of cached twts in memory (default 150)
-C, --max-cache-ttl duration maximum cache ttl (time-to-live) of cached twts in memory (default 336h0m0s)
yarnd pods by default are designed to only keep Twts around publicly visible on either the anonymous Frontpage or Discover View or your Timeline or the feed's Timeline for up to 2 weeks with a maximum of 150 items, whichever get exceeded first. Any Twts over this are considered "old" and drop off the active cache.yarnd's design (_nothing particularly to do with Twtxt per se_) that I've to this day stuck by -- Even though there are _some_ 😉 that have different views on this 🤣
$ yarnc debug https://twtxt.net/user/prologic/twtxt.txt | grep -E '^pqst4ea' | tee | wc -l
0
$ yarnc debug https://twtxt.net/user/prologic/twtxt.txt | grep -E '^pqst4ea' | tee | wc -l
0
jenny does things with storing every Twt in a Maildir I suppose? 🤔
jenny does things with storing every Twt in a Maildir I suppose? 🤔
yarnd because of the way it permanently stores and archives Twts, so even if you decide you changed your mind, or deleted that line out of your feed, if my pod or @xuu or @abucci or @eldersnake (_or any other handful of pods still around?_) saw the Twt, it'd be permanently archived._
yarnd because of the way it permanently stores and archives Twts, so even if you decide you changed your mind, or deleted that line out of your feed, if my pod or @xuu or @abucci or @eldersnake (_or any other handful of pods still around?_) saw the Twt, it'd be permanently archived._
~
~
yarnd would have to be maliciously fabricating a Twt with the Hash D.
yarnd would have to be maliciously fabricating a Twt with the Hash D.
delete btw, Or at least not making it mandatory, as-in "clients should" rather than "clients must". But yes I agree, let's explore all the possible ways this can be exploited (_if at all_).
delete btw, Or at least not making it mandatory, as-in "clients should" rather than "clients must". But yes I agree, let's explore all the possible ways this can be exploited (_if at all_).
yarnd works and I'm sure jenny can make similar assertions too.
yarnd works and I'm sure jenny can make similar assertions too.
yarns (_not to be confused with yarnd_) are always welcome 🤗 -- I don't have as much "spare time" as I used to due to the nature of my job (_Staff Engineer_); but I try to make improvements every now and again 💪
yarns (_not to be confused with yarnd_) are always welcome 🤗 -- I don't have as much "spare time" as I used to due to the nature of my job (_Staff Engineer_); but I try to make improvements every now and again 💪
yarnd had a few implementation security bugs, but I'm not sure this is actually possible, unless I'm missing something? 🤔
yarnd had a few implementation security bugs, but I'm not sure this is actually possible, unless I'm missing something? 🤔