# 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/kop2eva
@abucci I'm open to some feature flagged ideas? 🤔
@abucci I'm open to some feature flagged ideas? 🤔
@abucci I'm open to some feature flagged ideas? 🤔
@abucci I'm open to some feature flagged ideas? 🤔
@prologic I definitely do not think Amazon Mechanical Turk is the solution, that's for sure.
In all seriousness, this would do it for me for now:
- Some kind of slide-to-submit captcha at registration time (which I think can be made accessible if that's a concern),
- A simple interface to delete more than one user at a time and to find inactive users
The 2nd one could be as simple as letting me enter a comma-separated list of usernames into the delete user field. It'd be even better if there were a way to search for users who've registered but never posted (obviously more filters would make it more useful, but that one alone is MVP for me). I have no trouble doing this search with a command-line tool to save the time/effort of making a nice UI for it.
Regarding the 1st one, I don't think the users registering on my pod are bots. There are too few of them, they don't post anything, and there's already a barrier to entry slowing down bots. So I'd down-prioritize that one for the time being, frankly. It's probably something to have in the works in case there ever is a flood of bots, obv.
@abucci Okay 👌 Maybe file a feature request(s) as per above, and we'll try to build this 🤞
@abucci Okay 👌 Maybe file a feature request(s) as per above, and we'll try to build this 🤞
@abucci Okay 👌 Maybe file a feature request(s) as per above, and we'll try to build this 🤞
@abucci Okay 👌 Maybe file a feature request(s) as per above, and we'll try to build this 🤞
@prologic Would it make sense to file two feature requests? One for "deleting multiple users at once", and a second for "find inactive users"? They are different problems, and the 1st is more useful than the 2nd for the time being.
@abucci I _think_ so. The backend already knows how to measure "inactive feeds" so that shouldn't be too hard to build, just have to build an interface around it "somehow" -- I think I recall telling you about a weekly email you'd get, but if you haven't gotten one, then you've been nuking these *zit(s) before that 😅*
@abucci I _think_ so. The backend already knows how to measure "inactive feeds" so that shouldn't be too hard to build, just have to build an interface around it "somehow" -- I think I recall telling you about a weekly email you'd get, but if you haven't gotten one, then you've been nuking these *zit(s) before that 😅*
@abucci I _think_ so. The backend already knows how to measure "inactive feeds" so that shouldn't be too hard to build, just have to build an interface around it "somehow" -- I think I recall telling you about a weekly email you'd get, but if you haven't gotten one, then you've been nuking these *zit(s) before that 😅*
@abucci I _think_ so. The backend already knows how to measure "inactive feeds" so that shouldn't be too hard to build, just have to build an interface around it "somehow" -- I think I recall telling you about a weekly email you'd get, but if you haven't gotten one, then you've been nuking these *zit(s) before that 😅*
@prologic OK, I submitted two feature requests. Do with them what you will!