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