# 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/7fsi7yq
I would personally rather see something like this:


2025-09-25T22:41:19+10:00	Hello World
2025-09-25T22:41:19+10:00	(#kexv5vq https://example.com/twtxt.html#:~:text=2025-09-25T22:41:19%2B10:00) Hey!


Preserving both content-based addressing as well as location-based addressing and text fragment linking.
@prologic that's not too bad! 👏🏻👏🏻👏🏻
@bender Really? 🤔
@prologic While it might work if you want to keep both, I think the point was to be able to use one or the other, if we still have to generate the hash anyway it might be pointless to use this format.
@alexonit My problem is I don't see a world where we don't employ some form of cryptography to use as keys for threads in databases and other such things honestly. I'm not going to use url#timestamp as keys.
@prologic Well, personally I would, as I already do for user feeds in my client.

That's why part of my proposal was to allow custom strings and be free from a specific format that need periodical upgrades, but it's not much of a problem in the end.

I'll adapt to what we can get out of this.
@alexonit Well we have to really use the same spec or threading doesn't really work in a truly decentralized manner 😉