# 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 21
# self = https://watcher.sour.is/conv/rh6gtwq
@lyse This looks like a nice way to do it.
Another thought: if clients can't agree on the url (for example, if we switch to this new way, but some old clients still do it the old way), that could be mitigated by computing many hashes for each twt: one for every url in the feed. So, if a feed has three URLs, every twt is associated with three hashes when it comes time to put threads together.
A client stills need to choose one url to use for the hash when composing a reply, but this might add some breathing room if there's a period when clients are doing different things.
(From what I understand of jenny, this would be difficult to implement there since each pseudo-email can only have one msgid to match to the in-reply-to headers. I don't know about other clients.)
@falsifian Regarding your last paragraph: Back in December 2020, we already once changed the hashing. I think that was my first contribution, breaking everything by switching to RFC 3339 for the timestamp format. ;-) I'm computing two hashes in my client, the old and current one. And then I just select whatever matching parent exists to build the thread tree.
I could do that again in my client, but you're right, it's a different story for jenny. If I'm not mistaken, In-Reply-To could contain several hashes, but the Message-ID header is the issue.
By increasing the hash length for a potential future change, clients could tell, which algorithm to use.
Maybe we could define a magic timestamp in the future that marks the cutoff point. Use the current implementation for messages authored before that magic date or the new algorithm for all messages after that.
But eventually, all clients have to be updated. There's no way around that, I believe. Simplicity is key and my magic time already adds complexity. :-/
@lyse I personally think that we just go with a magic timestamp approach. It's simpler and easier to implement across the major clients that are still actively developed.
The question is how much time do we give ourselves as we're all a bit time poor and I can't imagine we would do this quickly.
@lyse I personally think that we just go with a magic timestamp approach. It's simpler and easier to implement across the major clients that are still actively developed.
The question is how much time do we give ourselves as we're all a bit time poor and I can't imagine we would do this quickly.
@prologic do that mean that for every new post (not replies) the client will have to generate a UUID or similar when posting and add that to to the twt?
@prologic do that mean that for every new post (not replies) the client will have to generate a UUID or similar when posting and add that to to the twt?
@prologic do that mean that for every new post (not replies) the client will have to generate a UUID or similar when posting and add that to to the twt?
@prologic do that mean that every new post (not replies) will have to generate their own UUID or similar when posting?
@prologic do that mean that for every new post (not replies) the client will have to generate a UUID or similar when posting and add that to to the twt?
@sorenpeter No, this is what I want to avoid. For many reasons I stated before, content addressing or hashing is far better here for threading in a decentralized way.
@sorenpeter No, this is what I want to avoid. For many reasons I stated before, content addressing or hashing is far better here for threading in a decentralized way.
IMO we just have to fix the identity problem and figure out how to detect or support edits.
IMO we just have to fix the identity problem and figure out how to detect or support edits.
@prologic can't one just link to a keyoxide profile with a link to their Twtxt feed for identity or something?
@prologic can't one just link to a keyoxide profile with a link to their Twtxt feed for identity or something?
@aelaraji how would that work exactly? Does that mean then that every user is required to have a cox side profile? Who maintains cox site? Is it centralized or decentralized can be relied upon?
@aelaraji how would that work exactly? Does that mean then that every user is required to have a cox side profile? Who maintains cox site? Is it centralized or decentralized can be relied upon?
@prologic you should see This ! The devs were already trying to figure things out for TWTXT and Yarn.social 😃
@prologic you should see This ! The devs were already trying to figure things out for TWTXT and Yarn.social 😃