https://movq.de/v/9df0437d27/MVI_8891.MOV.mp4
Now everything looks like it has that silly slogan as a background image:
https://movq.de/v/9df0437d27/smol.jpg
# 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 194817 # self = https://watcher.sour.is?offset=194817 # prev = https://watcher.sour.is?offset=194717
https://andros.dev/texudus.txt
, its url doesn't correspond to the feed either
/^([-_\p{N}\p{L}])+$/iu
because i don't like how english-centric only allowing ascii letters/numbers is though this only applies to local users as of now, currently all nicknames are tolerated when parsing remote feeds and i just do mentions how yarn does (just the feed url)@<nick url>
. If the next token after the @<nick
does not look like a URL, it's not a mention but regular text. This is just wild guessing, though.r'[a-zA-Z0-9]'
from nick names.
nick
s? i remember reading somewhere whitespace should not be allowed, but i don't see it in the spec on twtxt.dev — in fact, are there any other resources on twtxt extensions outside of twtxt.dev?
yarnd
does have a well documented API and two clients (CLI and unmaintained Flutter App)
{
"nick": "Example",
"description": "alice's twtxt instance!",
"host": "twtxt.example.com",
"admin": "alice"
}
nick
to instance_name
or similar? Usually nick
is reserved for users, like here, quark
. Right? Also, is host
the same FQDN to be used while proxying traffic to the application? That is, using the above configuration, it's Caddy configuration would be:
twtxt.example.com {
encode
reverse_proxy :31212
}
grep -v git
at the end, so my repo is still in working order. Phew. I wish find
had grep
-like --exclude-dir
and --exclude
options (or the include variants) instead of its own weird options that I never can remember and combine properly.