https://movq.de/v/a1c4a819e6/vid.mp4
(It runs smoothly. My computer just isn’t fast enough for a smooth X11 screengrab at that resolution.)
# 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 235518 # self = https://watcher.sour.is?offset=235518 # prev = https://watcher.sour.is?offset=235418
00:30
(_midnight_) for a P2 incident that is now resolved at 02:10
🤯 Obviously I'm not going to work tomorrow (_I mean today lol 😂_) at the usual start time 🤦♂️_
git pull
on one of my repos – once every two minutes. This is a very pointless endeavour. I push new code a couple of times *per month*.yarnd
very soon™ for this change, with a if the date is >= 2025-07-01 then compute_new_hashes else compute_old_hashes
tt2
from @lyse and Twtxtory from @javivf?
7
to 12
and use the first 12
characters of the base32 encoded blake2b hash. This will solve two problems, the fact that all hashes today either end in q
or a
(_oops_) 😅 And increasing the Twt Hash size will ensure that we never run into the chance of collision for ions to come. Chances of a 50% collision with 64 bits / 12 characters is roughly ~12.44B Twts. That _ought_ to be enough! -- I also propose that we modify all our clients and make this change from the 1st July 2025, which will be Yarn.social's 5th birthday and 5 years since I started this whole project and endeavour! 😱 #Twtxt #Update~
twtxt.txt
feeds. Instead, we use modern Twtxt clients that conform to the specifications at Twtxt.dev for a seamless, automated experience. #Twtxt #Twt #UserExperience
yarnd
now "sees" both every single time, where-as before it would just obliterate the old Twt, but remain in archive. Now you get to see both 😅 Not sure if that's a good thing or not, but it certainly makes it much clearer how to write "code logic" for detecting edits and doing something more UX(y) about 'em 🤔
yarnd
powering this pod twtxt.net 🧐
begin
and end
blocks for if
s or loops. For example I always thought that I needed to have a button somewhere, even if hidden. That gave me a handler procedure where I could put code and somehow call it. Two or three years later, a new mate from the parallel class finally told me that this wasn't necessary and how to do thing better.
Message
├╴Reply 1
│ └╴Subreply
└╴Reply 2
A
to reply to the parent should have picked "Message". However, a reply to "Reply 2" was composed instead. The reason was a precausiously introduced safety guard to abort the parent search which stopped at "Subreply", because its subject didn't match "Reply 2"'s. It was originally intended to abort on a completely different message conversation root. Just in case. Turns out that this thoght was flawed.# type = bot
and optionally # retention = N
so that feeds like @tiktok work like they did before, and... Updated some internal metrics in yarnd
to be IMO "better", with queue depth, queue time and last processing time for feeds.
#!/bin/sh
# Position the pointer at the center of the dot, then run this script.
sleep 1
start=$(xdotool getmouselocation --shell)
eval $start
r=400
steps=100
down=0
for step in $(seq $((steps + 1)) )
do
# pi = 4 * atan(1)
new_x=$(printf '%s + %s * c(%s / %s * 2 * (4 * a(1)))\n' $X $r $step $steps | bc -l)
new_y=$(printf '%s + %s * s(%s / %s * 2 * (4 * a(1)))\n' $Y $r $step $steps | bc -l)
xte "mousemove ${new_x%%.*} ${new_y%%.*}"
if ! (( down ))
then
xte 'mousedown 1'
down=1
fi
done
xte 'mouseup 1'
xte "mousemove $X $Y"