# 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 10
# self = https://watcher.sour.is/conv/kn7dzsa
@prologic @ullarah Please remember to check opening links in a new tab via right click. It doesn't work now. Progressive enhancement ftw! 😁
@adi you might have to explain a bit further. I’ve tried with and without link verification in combination of same/new window option. 🤔
@ullarah twtxt
Link verification is disabled now, when it's enabled, it opens the https://twtxt.net/#verifyLink url in a new tab but it doesn't show any verify dialog.
Lol, tested on bad link https://he.net opens https://twtxt.net/#linkVerify?uri=https://he.net in a new tab.
Lol, tested on bad link https://he.net opens https://twtxt.net/#linkVerify?uri=https://he.net in a new tab. On right click -> Open in a new tab! 😁
@adi that’s because link verification is purely client side now. There is an idea floating to override all links in JS but I feel that it’s a slippery slope.

I’m open for any suggestions on alternatives.

Actually thinking about it now I could capture “contextMenu”/“right” clicks and it will open the link up bypassing the link verification window?
I have to admit, I'm totally lost here. @adi if you have a problem with the implementation, please propose a better one. Originally it was done server-side, that naturally upset folks like @mckinley -- rightfully so, we quickly double-backed (the feature is still quite useful) and reimplemented it all client-side in JS so there is never any chance a Pod ever sees the links you _may_ or _may not_ click on.
I have to admit, I'm totally lost here. @adi if you have a problem with the implementation, please propose a better one. Originally it was done server-side, that naturally upset folks like @mckinley -- rightfully so, we quickly double-backed (the feature is still quite useful) and reimplemented it all client-side in JS so there is never any chance a Pod ever sees the links you _may_ or _may not_ click on.
@prologic Didnt' follow the @mckinley conversation on why it was implemented client side only. @ullarah If you think that would work and it works rocks solid, sure.