# 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/hnnukna
So my thinking so far is:
- We build a /api/v1/admin/delete API endpoint which takes {"hash": <hash>} as JSON input.
- We build a yarnc admin delete <hash> sub-command (start a new sub-command group)
Which would delete a Twt by hash from the Pod's archive and blacklist it (as it could come back from other pods via the Converge logic).
This _would_ require manual operations to be performed by one or more cooperating / participating Pod operators in the network. And I _think_ this would have to end up being a "culture" we build upon where we agree when incidents that require this happen, that we get together in some way to cooperatively agree on a Twt deletion.
A similar set of tools would have to be built for the Twtxt Search engine too, although I would probably do this by hand for now as it does not peer with pods and therefore has no way to bring back Twts from the dead from a convergence logic that yarnd has.
So my thinking so far is:
- We build a /api/v1/admin/delete API endpoint which takes {"hash": <hash>} as JSON input.
- We build a yarnc admin delete <hash> sub-command (start a new sub-command group)
Which would delete a Twt by hash from the Pod's archive and blacklist it (as it could come back from other pods via the Converge logic).
This _would_ require manual operations to be performed by one or more cooperating / participating Pod operators in the network. And I _think_ this would have to end up being a "culture" we build upon where we agree when incidents that require this happen, that we get together in some way to cooperatively agree on a Twt deletion.
A similar set of tools would have to be built for the Twtxt Search engine too, although I would probably do this by hand for now as it does not peer with pods and therefore has no way to bring back Twts from the dead from a convergence logic that yarnd has.
@prologic On a side note, /api/v1/admin/delete with a {"hash": <hash>} body doesn't really feel REST-like to me. Why not DELETE /api/v1/twts/<hash> or whatever resource path?
Anyways, deleting remote twts from the yarnd cache and archive manually is the completely wrong approach in my opinion. It feels like a bandaid. If the twt is gone from the feed it just has to be removed from the cache and archive as well, provided that twt has not been rotated away into an archive feed. Of course this is more work, but it's the right thing to do. Software is there to help humans, not the other way around. :-)
As discussed on IRC just now (g'night @lyse 😴) couple of things we agree on:
- The API was always written like this, so changing it now is "too much work" 😅 so we'll leave it the way it is.
- We don't complete agree on the "automatic deletion" just yet, and there are clear problems with this when pods exchange twts with each other (Convergence)
- We should document a design proposal and discuss
As discussed on IRC just now (g'night @lyse 😴) couple of things we agree on:
- The API was always written like this, so changing it now is "too much work" 😅 so we'll leave it the way it is.
- We don't complete agree on the "automatic deletion" just yet, and there are clear problems with this when pods exchange twts with each other (Convergence)
- We should document a design proposal and discuss