# 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 15
# self = https://watcher.sour.is/conv/yjtzdka
@vain mostly because the standard calls for dates and times to be formatted that way so use that as the part of the hash
@vain mostly because the standard calls for dates and times to be formatted that way so use that as the part of the hash
@vain mostly because the standard calls for dates and times to be formatted that way so use that as the part of the hash
@vain @prologic The "+00:00 to Z" thing comes from Go's internal time handling. time.RFC3339 will always produce Z rather than +00:00. I doubt that it is possible to keep the original information in the time.Time object itself, whether +00:00 or Z was parsed from the _twtxt.txt_, so I took the lazy route of just defining Go's behavior in the spec. That's also why UTC must be used, if the original date does not specify a timezone at all. For a quick and easy hash calculation it would be ideal to hash the exact twt line without the twter URL, but that would have been a tiny bit bigger change I didn't have the courage to suggest.
@lyse I see. 🤔 Agreed, just using the original line would have been the easiest thing to do. Well, FWIW, I think including the twter URL is the right thing to do. Otherwise, two “Good morning!” twts sent at the same time get the same ID. That’d be wrong, wouldn’t it?
@lyse I see. 🤔 Agreed, just using the original line would have been the easiest thing to do. Well, FWIW, I think including the twter URL is the right thing to do. Otherwise, two “Good morning!” twts sent at the same time get the same ID. That’d be wrong, wouldn’t it?
@lyse I see. 🤔 Agreed, just using the original line would have been the easiest thing to do. Well, FWIW, I think including the twter URL is the right thing to do. Otherwise, two “Good morning!” twts sent at the same time get the same ID. That’d be wrong, wouldn’t it?
@lyse I see. 🤔 Agreed, just using the original line would have been the easiest thing to do. Well, FWIW, I think including the twter URL is the right thing to do. Otherwise, two “Good morning!” twts sent at the same time get the same ID. That’d be wrong, wouldn’t it?
@vain Agreed. The Twt Hash is like content addressing. It needs to include all the information. Who authored the Twt, When it was written and the content.
@vain Agreed. The Twt Hash is like content addressing. It needs to include all the information. Who authored the Twt, When it was written and the content.
@vain Agreed. The Twt Hash is like content addressing. It needs to include all the information. Who authored the Twt, When it was written and the content.
@vain @prologic Nice "Good morning!" example, I didn't think of that! I always thought that there's a pretty much zero chance of two users creating the same twt at the same second. But your sample is actually quite likely to happen, especially if the twtxt universe grows. So, yeah, there are indeed candidates for potential hash collissions without the author information.