# 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 42
# self = https://watcher.sour.is/conv/zafd26q
Hello World, long time no seen
Hello World, long time no seen
@prologic Huh. twtxt.net computed the hash zafd26q for melyanna’s original twt. I get kjsxeka. The difference appears to be that my client used the URL https://tilde.club/~melyanna/twtxt.txt, while twtxt.net used just http://. That’s a) a bit of a problem if people provide their feed over multiple protocols (half-baked thought, maybe we should omit the scheme? 🤔), b) might be a bug because twtxt.net’s web interface shows https://. 😯
@prologic Huh. twtxt.net computed the hash zafd26q for melyanna’s original twt. I get kjsxeka. The difference appears to be that my client used the URL https://tilde.club/~melyanna/twtxt.txt, while twtxt.net used just http://. That’s a) a bit of a problem if people provide their feed over multiple protocols (half-baked thought, maybe we should omit the scheme? 🤔), b) might be a bug because twtxt.net’s web interface shows https://. 😯
@prologic Huh. twtxt.net computed the hash zafd26q for melyanna’s original twt. I get kjsxeka. The difference appears to be that my client used the URL https://tilde.club/~melyanna/twtxt.txt, while twtxt.net used just http://. That’s a) a bit of a problem if people provide their feed over multiple protocols (half-baked thought, maybe we should omit the scheme? 🤔), b) might be a bug because twtxt.net’s web interface shows https://. 😯
Can we come up with something that is easier to implement in other clients or can be done by hand than hash? As I read the docs about the original subject is was like email (re: original post) right?! So if instead of the hash we do (re: 2021-02-21T08:42:00Z <@nick URL>) where the datetime is just copied from the .txt with the original post. Then it is also human readable and can be parsed by other clients.
Can we come up with something that is easier to implement in other clients or can be done by hand than hash? As I read the docs about the original subject is was like email (re: original post) right?! So if instead of the hash we do (re: 2021-02-21T08:42:00Z <@nick URL>) where the datetime is just copied from the .txt with the original post. Then it is also human readable and can be parsed by other clients.
... Since this is gonna be a lot longer than the hash, it could added to the end of the line of each reply post instead of in the beginning for human readbility of the raw txt
... Since this is gonna be a lot longer than the hash, it could added to the end of the line of each reply post instead of in the beginning for human readbility of the raw txt
No we should stick to hashes. They have interesting useful properties.
@movq can you file a bug report?
No we should stick to hashes. They have interesting useful properties.
@movq can you file a bug report?
No we should stick to hashes. They have interesting useful properties.\n\n@https://www.uninformativ.de/twtxt.txt> can you file a bug report?
No we should stick to hashes. They have interesting useful properties.\n\n@https://www.uninformativ.de/twtxt.txt> can you file a bug report?
we’ve also changed this once already in the last few months so changing the whole scheme again would not be very great user experience
or compatibility
we’ve also changed this once already in the last few months so changing the whole scheme again would not be very great user experience \nor compatibility
we’ve also changed this once already in the last few months so changing the whole scheme again would not be very great user experience \nor compatibility
we’ve also changed this once already in the last few months so changing the whole scheme again would not be very great user experience
or compatibility
@prologic Hold on, this was a mistake on my part. Your pod really does follow melyanna via http, so the hash is correct. Only your -mention used the https version, which had me confused. 🥴 >
@prologic Hold on, this was a mistake on my part. Your pod really does follow melyanna via http, so the hash is correct. Only your -mention used the https version, which had me confused. 🥴 >
@prologic Hold on, this was a mistake on my part. Your pod really does follow melyanna via http, so the hash is correct. Only your -mention used the https version, which had me confused. 🥴 >
@prologic Can I ask what these "interesting useful properties" are?
Also the rebranding to yarn.social could be a good time to break compatibility.
Or have the options both for (hash) and (re: http://twtxt.net/u/darch 2021-02-21T10:44:10Z )
@prologic Can I ask what these "interesting useful properties" are?\n\nAlso the rebranding to yarn.social could be a good time to break compatibility.\nOr have the options both for (hash) and (re: http://twtxt.net/u/darch 2021-02-21T10:44:10Z )
@prologic Can I ask what these "interesting useful properties" are?\n\nAlso the rebranding to yarn.social could be a good time to break compatibility.\nOr have the options both for (hash) and (re: http://twtxt.net/u/darch 2021-02-21T10:44:10Z )
@prologic Can I ask what these "interesting useful properties" are?\n\nAlso the rebranding to yarn.social could be a good time to break compatibility.\nOr have the options both for (hash) and (re: http://twtxt.net/u/darch 2021-02-21T10:44:10Z ) or (re: 2021-02-21T10:44:10Z)[http://twtxt.net/u/darch]
@movq Yes but let's bring it up in an issue for discussion anyway. I'm sure @xuu has some _thoughts_ around this. I'm not sure we _should_ take thee schema into account when computing the Hash myself as the same "content" could be provided over gopher://, http://, https:// or even ftp:// 🤣 (_but really we only support http/https at this time_)
@movq Yes but let's bring it up in an issue for discussion anyway. I'm sure @xuu has some _thoughts_ around this. I'm not sure we _should_ take thee schema into account when computing the Hash myself as the same "content" could be provided over gopher://, http://, https:// or even ftp:// 🤣 (_but really we only support http/https at this time_)
@movq Yes but let's bring it up in an issue for discussion anyway. I'm sure @xuu has some _thoughts_ around this. I'm not sure we _should_ take thee schema into account when computing the Hash myself as the same "content" could be provided over gopher://, http://, https:// or even ftp:// 🤣 (_but really we only support http/https at this time_)
@darch The interesting properties are that the hashes are content addressable both forwards and backwards. They are effectively "pointers" that can be computed at any time. They serve as a location to a Twt. That becomes very useful for archival, conversation retrieval as well as reconstruction.
@darch The interesting properties are that the hashes are content addressable both forwards and backwards. They are effectively "pointers" that can be computed at any time. They serve as a location to a Twt. That becomes very useful for archival, conversation retrieval as well as reconstruction.
@darch The interesting properties are that the hashes are content addressable both forwards and backwards. They are effectively "pointers" that can be computed at any time. They serve as a location to a Twt. That becomes very useful for archival, conversation retrieval as well as reconstruction.
As well as dee-duplication.
As well as dee-duplication.
As well as dee-duplication.