# 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 7
# self = https://watcher.sour.is/conv/hfzpnma
@movq @prologic Another option would be: when you edit a twt, prefix the new one with (#[old hash]) and some indication that it's an edited version of the original tweet with that hash. E.g. if the hash used to be abcd123, the new version should start "(#abcd123) (redit)".
What I like about this is that clients that don't know this convention will still stick it in the same thread. And I feel it's in the spirit of the old pre-hash (subject) convention, though that's before my time.
I guess it may not work when the edited twt itself is a reply, and there are replies to it. Maybe that could be solved by letting twts have more than one (subject) prefix.
> But the great thing about the current system is that nobody can spoof message IDs.
I don't think twtxt hashes are long enough to prevent spoofing.
@falsifian Yes;
> I don’t think twtxt hashes are long enough to prevent spoofing.
The current spec needs to be updated to expand the hash length to 11 characters to avoid hash collisions (_which will happen at some point with 7, if not already_).
The issue isn't dealing with "spoofing", it's about solving how clients in a decentralised model agree on the threading model and identity of a thread. Message ID(s) suffer from the fact that as @movq points out, clients have to "obey" this unwritten rule, but they're otherwise just arbitrary. Whereas Twt Hashes (_I didn't come up with the idea originally, some smart fellow in cryptography did_) are content addressable, meaning that clients don't have to agree on anything, they can trust that the hash is a cryptographic representing of the thread they're replying to, no matter what.
@falsifian Yes;
> I don’t think twtxt hashes are long enough to prevent spoofing.
The current spec needs to be updated to expand the hash length to 11 characters to avoid hash collisions (_which will happen at some point with 7, if not already_).
The issue isn't dealing with "spoofing", it's about solving how clients in a decentralised model agree on the threading model and identity of a thread. Message ID(s) suffer from the fact that as @movq points out, clients have to "obey" this unwritten rule, but they're otherwise just arbitrary. Whereas Twt Hashes (_I didn't come up with the idea originally, some smart fellow in cryptography did_) are content addressable, meaning that clients don't have to agree on anything, they can trust that the hash is a cryptographic representing of the thread they're replying to, no matter what.
@prologic you wrote:
> “[…] they can trust that the hash is a cryptographic representing of the thread they’re replying to, no matter what.”
It isn’t about trust, is it? There has to be some kind of check to verify the hash is valid, no?
@prologic you wrote:
> “\n they can trust that the hash is a cryptographic representing of the thread they’re replying to, no matter what.”
It isn’t about trust, is it? There has to be some kind of check to verify the hash is valid, no?
@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 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.