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/)
@email@example.com 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.
@firstname.lastname@example.org 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? 🤔
@email@example.com 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.
@firstname.lastname@example.org 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.
@email@example.com 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.
@firstname.lastname@example.org Now that I see your new comment, it sounds like we’re in strong agreement.
@email@example.com What are we on agreement about exactly? 😅
@firstname.lastname@example.org that a twtxt search engine is super important and necessary.
@email@example.com I think so 👌
@firstname.lastname@example.org so maybe you’re not so sure about the standardized search API then? Or are you saying something else?
@email@example.com 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? 🤔