# 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 5
# self = https://watcher.sour.is/conv/liwqpqq
prologic
twtxt.net
View Thread
@bender Sorry, trust was the wrong word. Trust as in, you do not have to check with anything or anyone that the hash is valid. You can verify the hash is valid by recomputing the hash from the content of what it points to, etc.
prologic
twtxt.net
View Thread
@bender Sorry, trust was the wrong word. Trust as in, you do not have to check with anything or anyone that the hash is valid. You can verify the hash is valid by recomputing the hash from the content of what it points to, etc.
bender
twtxt.net
View Thread
@prologic do the existing major clients today perform that verification, or is it simply β€œhey, there is that thingy let’s use it for reference!”?
prologic
twtxt.net
View Thread
@bender Yes, they do 🀣 Implicitly, or threading would never work at all πŸ˜… Nor lookups 🀣 They are used as keys. Think of them like a primary key in a database or index. I totally get where you're coming from, but there are trade-offs with using Message/Thread Ids as opposed to Content Addressing (_like we do_) and I believe we would just encounter other problems by doing so.

My money is on extending the Twt Subject extension to support more (_optional_) advanced "subjects"; i.e: indicating you edited a Twt you already published in your feed as @falsifian indicated πŸ‘Œ

Then we have a secondary (_bure much rarer_) problem of the "identity" of a feed in the first place. Using the URL you fetch the feed from as @lyse 's client tt seems to do or using the # url = metadata field as every other client does (_according to the spec_) is problematic when you decide to change where you host your feed. In fact the spec says:

> Users are advised to not change the first one of their urls. If they move their feed to a new URL, they should add this new URL as a new url field.

See Choosing the Feed URL -- This is one of our longest debates and challenges, and I _think_ (_I suspect along with @xuu _) that the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes.
prologic
twtxt.net
View Thread
@bender Yes, they do 🀣 Implicitly, or threading would never work at all πŸ˜… Nor lookups 🀣 They are used as keys. Think of them like a primary key in a database or index. I totally get where you're coming from, but there are trade-offs with using Message/Thread Ids as opposed to Content Addressing (_like we do_) and I believe we would just encounter other problems by doing so.

My money is on extending the Twt Subject extension to support more (_optional_) advanced "subjects"; i.e: indicating you edited a Twt you already published in your feed as @falsifian indicated πŸ‘Œ

Then we have a secondary (_bure much rarer_) problem of the "identity" of a feed in the first place. Using the URL you fetch the feed from as @lyse 's client tt seems to do or using the # url = metadata field as every other client does (_according to the spec_) is problematic when you decide to change where you host your feed. In fact the spec says:

> Users are advised to not change the first one of their urls. If they move their feed to a new URL, they should add this new URL as a new url field.

See Choosing the Feed URL -- This is one of our longest debates and challenges, and I _think_ (_I suspect along with @xuu _) that the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes.