# 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 3
# self = https://watcher.sour.is/conv/aytfnca
lyse
lyse.isobeef.org
View Thread
Cool, @anth, thanks for the followup! I have to reread the original v2 in order to really follow your explanation, but that document seems to be offline at the moment. I'll try again later. :-)
lyse
lyse.isobeef.org
View Thread
Righto @anth, v2 is up again for me:

> Clients (and human readers) just assume a flat threading
> structure by default, read things in order \n

I might misunderstand this, but I slightly disagree. Personally, I like to look at the tree structure and my client also does present me the conversation tree as an actual tree, not a flat list. Yes, this gets messy when there are a lot of branches and long messages, but I managed to live with that. Doesn't happen very often. Anyway, just a personal preference. Nothing to really worry.

> The v2 spec requires each reply to re-calculate the hash
> of the specific entry I’m replying to \n

Hmmmm, where do you read that the client has to re-calculate the hash on reply? (Sorry, I'm probably just not getting your point here in the entire paragraph.)

> Clients should not be expected to track conversations back
> across forking points \n

I agree. It totally depends on the client.
lyse
lyse.isobeef.org
View Thread
Righto @anth, v2 is up again for me:

> Clients (and human readers) just assume a flat threading
> structure by default, read things in order […]

I might misunderstand this, but I slightly disagree. Personally, I like to look at the tree structure and my client also does present me the conversation tree as an actual tree, not a flat list. Yes, this gets messy when there are a lot of branches and long messages, but I managed to live with that. Doesn't happen very often. Anyway, just a personal preference. Nothing to really worry.

> The v2 spec requires each reply to re-calculate the hash
> of the specific entry I’m replying to […]

Hmmmm, where do you read that the client has to re-calculate the hash on reply? (Sorry, I'm probably just not getting your point here in the entire paragraph.)

> Clients should not be expected to track conversations back
> across forking points […]

I agree. It totally depends on the client.