# 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 19
# self = https://watcher.sour.is/conv/6cajjya
@prologic Any plans/thoughts on implementing the twtxt registry protocol as part of yarn.social?
Yarn already have most of it :
- Latest tweet : Discovery tab has it (https://twtxt.net/discover)
- Search for tweets : that one is missing
- Mentions : Mentions tab has it (https://twtxt.net/mentions)
- Tag : the search tag bar is there (https://twtxt.net/search?tag=mytag)
- User : you can see a profile (https://twtxt.net/user/brasshopper/)
@tkanos That’s why I was thinking it might be easy to implement. I am looking at implementing my own client/server, and it would be nice to have as few protocols as possible to deal with. Now that I’m saying this, I don’t actually know how many people are using twtxt registries vs yarn.social json protocol.
@tkanos I’d be happy to put in a PR. I wanted to see if this had already been considered and decided against for some reason.
In practise, almost no-one uses a Twtxt registry. I _think_ it got bolted on to the spec as an "afterthought", but required clients to add an implementation and use one or more registries, but which one? 😅 My personal opinion has always been to just rely on a search engine, of which there is one currently (needs some love), but hmmm not sure, this keeps coming up, regitries, but why? 🤔
In practise, almost no-one uses a Twtxt registry. I _think_ it got bolted on to the spec as an "afterthought", but required clients to add an implementation and use one or more registries, but which one? 😅 My personal opinion has always been to just rely on a search engine, of which there is one currently (needs some love), but hmmm not sure, this keeps coming up, regitries, but why? 🤔
@prologic I see registries/search engines as a way of removing the complicated operational piece of twtxt. Just put a static twtxt up on the web and rely on search to notify you of non-follower mentions and to discover others talking about what you care about.
@brasshopper In which case I strongly believe a _really good_ search engine and crawler is more suited to this, as it has the capability of self-discovering other feeds by crawling the entire space.

It works because of the inevitable "network effect", for example: Say you were mentioned by a new person I'm interacting with for some reason or another, but you don't follow them. Because you follow me, you get to know about this because of your connection with me.

A crawler can also discover this as well (and does).

Are you any good at Go btw? We have a search engine, but it needs a bit more work I think.
@brasshopper In which case I strongly believe a _really good_ search engine and crawler is more suited to this, as it has the capability of self-discovering other feeds by crawling the entire space.

It works because of the inevitable "network effect", for example: Say you were mentioned by a new person I'm interacting with for some reason or another, but you don't follow them. Because you follow me, you get to know about this because of your connection with me.

A crawler can also discover this as well (and does).

Are you any good at Go btw? We have a search engine, but it needs a bit more work I think.
@prologic It’s really easy to publish a flat twtxt file from just about any client you can imagine. The hard part is being notified of mentions and discovering new feeds. There is some degree of centralization/always on needed for that piece. By standardizing the hard part to an interchangeable API, it would allow a diversity of clients to be built with little effort. Just plug in your preferred search engine(s) and you’re good to go.
@prologic Now that I see your new comment, it sounds like we’re in strong agreement.
@brasshopper What are we on agreement about exactly? 😅
@brasshopper What are we on agreement about exactly? 😅
@prologic that a twtxt search engine is super important and necessary.
@brasshopper I _think_ so 👌
@brasshopper I _think_ so 👌
@prologic so maybe you’re not so sure about the standardized search API then? Or are you saying something else?
@brasshopper Here's what my thoughts are:

- Someone needs to fiddle with the search engine's codebase and improve it
- Fix some performance issues and correctness
- Add support for indexing mentions and feed authors of twts
- Document how to use the query language really well
- Provide results over both HTML and JSON

I _think_ that would get us in a good place. Keeping the API as simple as hitting the search endpoint with ?q=... would suffice I think? 🤔
@brasshopper Here's what my thoughts are:

- Someone needs to fiddle with the search engine's codebase and improve it
- Fix some performance issues and correctness
- Add support for indexing mentions and feed authors of twts
- Document how to use the query language really well
- Provide results over both HTML and JSON

I _think_ that would get us in a good place. Keeping the API as simple as hitting the search endpoint with ?q=... would suffice I think? 🤔