# 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 5
# self = https://watcher.sour.is/conv/6gfpeea
One of the biggest gripes of the community with the way the threading model _currently_ works with Twtxt v1.2 (https://twtxt.dev) is this notion of:
> What is this hash?
> What does it refer to?
Idea: Why can't we all agree to implement a simple URI scheme where we host our Twtxt feeds?
That is, if you host your feed at https://example.com/twtxt.txt -- Why can't or could you not also host various JSON files (_let's agree on the spec of course_) at https://example.com/twt/<hash> ? 🤔
That way we solve this problem in a truly decentralised way, rather than every relying on yarnd pods alone.
@prologic We can't agree on this idea because that makes things even more complicated than it already is today. The beauty of twtxt is, you put one file on your server, done. One. Not five million. Granted, there might be archive feeds, so it might be already a bit more, but still faaaaaaar less than one file per message.
Also, you would need to host not your own hash files, but everybody else's as well you follow. Otherwise, what is that supposed to achieve? If people are already following my feed, they know what hashes I have, so this is to no use of them (unless they want to look up a message from an archive feed and don't process them). But the far more common scenario is that an unknown hash originates from a feed that they have not subscribed to.
Additionally, yarnd's URL schema would then also break, because https://twtxt.net/twt/<hash> now becomes https://twtxt.net/user/prologic/<hash>, https://twtxt.net/user/bender/<hash> and so on. To me, that looks like you would only get hashes if they belonged to this particular user. Of course, you could define rules that if there is a /user/ part in the path, then use a different URL, but this complicates things even more.
Sorry, I don't like that idea.
@lyse Sorry I didn't mean to upset you or anyone here in the community. I am/was merely trying to solve what I perceive to be a problem and an ask in the community:
> How do I know what a hash refers to?
I believe the reason for this stems from a curiosity of the user of whether they _might_ find that thread interesting or whether there are new interested feeds to follow?
Although my idea increases complexity slightly (_introducing a new concept_) I don't think it's particular hard to understand, reason about or implement (_complicated_). One could even even make the implementation quite simple in fact.
Either way, the idea of a service (_cantralised_) or participating clients/registries (_distributed_) providing reverse hash lookups doesn't sound too bad really.
What do you propose to solve the above problem? 🤔
Why not just use registry? It can be personal or hosted by someone like registry.twtxt.org. Just need to be adapt to support hashes
@doesnm Actually that's a fantastic idea 🙌