# 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 11
# self = https://watcher.sour.is/conv/4hxolxa
I'm think of adding to it, the current API is yarn specific, so I don't think it should be changed to match the orignal registry API. But the registry format is nice and clean and feels very much like a part of twtxt. I'm suggesting adding the ability to read twts in that format. It doesn't have to be via the API per-say, it could be a stand alone path like /timeline or /all
I'm think of adding to it, the current API is yarn specific, so I don't think it should be changed to match the original registry API. But the registry format is nice and clean and feels very much like a part of twtxt. I'm suggesting adding the ability to read twts in that format. It doesn't have to be via the API per-say, it could be a stand alone path like /timeline or /all
@<~duriny https://envs.net/~duriny/twtxt.txt> You are right about the /api/v1 being "Yarn" specific, specific to clients of the yarnd1 API that is, like yarnc and the Mobile App (_which will be rewritten as a PWA/SPA soonβ’_). So that being said, why won't we add a /registry/v1 dedicated for the purpose you've suggested? Does that make more sense here? π€ The reason I'm thinking about this is that the plain 'ol bare Paths are for the SSR (Server-Side-Rendered) frontend mostly..._
@<~duriny https://envs.net/~duriny/twtxt.txt> You are right about the /api/v1 being "Yarn" specific, specific to clients of the yarnd1 API that is, like yarnc and the Mobile App (_which will be rewritten as a PWA/SPA soonβ’_). So that being said, why won't we add a /registry/v1 dedicated for the purpose you've suggested? Does that make more sense here? π€ The reason I'm thinking about this is that the plain 'ol bare Paths are for the SSR (Server-Side-Rendered) frontend mostly..._
Ah that's good :) to be honest I was hesitant to suggest a whole new api, but that it be really cool to match the "official" registry spec :D
Ah that's good :) to be honest I was hesitent to suggest a whole new api, but that it be really cool to match the "offical" registry spec :D
@<~duriny https://envs.net/~duriny/twtxt.txt> Seems to make a lot of sense to me π The question is whether the Cache has all the data you need to serve up the registry requests π€
@<~duriny https://envs.net/~duriny/twtxt.txt> Seems to make a lot of sense to me π The question is whether the Cache has all the data you need to serve up the registry requests π€