a small tiddlypwa continues to work great, even on my mobile device on random networks on the other side of the planet. a far better experience than my big tiddlywiki5 instance.

deno (and node) are both chunkier than i'd like but the utility tiddlypwa provides outweighs that. a problem for later.

try it out! support the author!

setting StateDirectory=foo in a systemd unit makes it create the directory /var/lib/foo and set $STATE_DIRECTORY to that
https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#RuntimeDirectory=

$STATE_DIRECTORY will expand in your Exec= declaration but not in e.g. Environment=

so i can't say

instead i have to
Exec=env DB_FILENAME=${STATE_DIRECTORY}/database.sqlite3 /usr/bin/command

is there a prettier way?

is there a prettier way?

there is!

systemd.unit "specifiers"

setting up xmpp service on an ipv6-only vm with a graciously provided sniproxy to reverse-proxy ipv4 traffic to it

xmpp seems fine. i think my fantastic vps will let me forward those ports but even if not you can make xmpp share http(s) ports with a webserver with some hacks

but if i want to do voice and video, i'll need stun/turn to help ipv4 users

stun seems fine. client connects to it, server says "you appear to me to be (address):(port)," done.

turn however...

turn is for when no clever way can be found to connect clients directly to each other; they both connect to a turn server which just proxies: it shovels data back and forth to each client

even though my host would probably grant a request to proxy traffic through their ip4->ip6 machine to my turn service, which would proxy it again, that seems wasteful and squandering of a currently free community resource. i think i will build this out pretending that i can't do that

i'm not sure if there's any need for stun or turn with ipv6 clients, but otoh ipv6 nats are possible

like when your isp assigns you a /64 but you want to set up several subnets

think i'll rely on the reverse proxy to enable xmpp for ipv4-only users, and just say that voice and video is unavailable to them. the only real users of my xmpp server are my immediate family, and if both happen to be on an ip4-only network and need voice/video, they can get on the vpn

i got a ipv6-only vm from my sweet hosting provider
they gave me a /56 worth of ipv6 address space to play in. woah.
said my vm is currently using only the first /64 of it.
my vm's address is (prefix)::1/64, amazing!
so uh
how do i plug servers and containers into the rest of my available space? do i have to request each address get added to a table somewhere? (no)

(to be continued. but i think i did it, and understand it now!) 🎉

(i might do this as a blog instead)

woo! connected to a test instance of prosody xmpp on port 443 (https) using xmpp's direct-tls protocol

which means

• hopefully, certain employers won't block the traffic anymore
• hopefully, it can pass through sniproxy the same way https traffic does, which will enable ipv4 users to talk to my ipv6 xmpp server

there's still different ways i can think of to wire all this together, wondering if any would be better

other ways i could wire it up:

• instead of using a separate ip address so it and caddy can both listen on port 443, i could have caddy reverse proxy to it

• might need to put it behind a proxy anyway because it might not handle PROXY protocol from sniproxy

• might need to put it behind a proxy anyway so iocaine can slap the llm scrapers that try it

• maybe run it in a container and figure out how to get those their own ip address

wow incus (anti-ubuntu fork of lxd) and its web ui is pretty slick

also libvirt and virt-manager connected to lxc offers the ability to create an application container or an operating system container

(compared to incus which says application containers require docker?)

this feels like a deep rabbit hole, hope i can get grips on it soon

all right incus there you go, a whole-ass lvm volume group all to yourself, let's see what you do with it

also: learning wtf a network bridge is and how to use one 🧑‍🎓📖 instead of the usual winging it with vague guesswork and assumptions from context

is xmpp's direct-tls protocol (usually on port 5223) the same as its unencrypted protocol (usually port 5222) wrapped in tls? same as imaps and pops and https? so could i terminate the tls with haproxy and reverse proxy to an unencrypted xmpp server?

the protocol is all spec'd in RFCs for anybody to look at but they don't wanna get in my brain

also, aw, the wikipedia article for xmpp describes as an example a transport for icq, rip https://en.wikipedia.org/wiki/XMPP

the docs don't reveal the info i want, and i don't want to try reading reams of source code in an unfamiliar language right now, so i'll set up an experiment and see how it behaves i guess

(the only activity that ever feels slightly close to doing science in my field of software-jiggling)

my ipv4-only client
-> ipv4-to-ipv6 sniproxy port 443
-> ipv6-only vm
-> haproxy to conditionally unwrap proxy protocol
-> prosody xmpp server

... experiment is working ✨🤩✨

calling it now: even though haproxy has lots of sharp edges, i like it, or its configuration mechanism, way more than caddy's

• i seem to be able to make stuff work in haproxy that takes struggle and uncertainty in caddy
• caddy's magical get-your-free-ssl-cert-automatically is nice when you want to stand up an experiment but i like cronned certbot for "prod"
• otoh caddy has a nice builtin static webserver 🤷

i think i'm going to be stuck using both for a while

migrating xmpp services from my old vps to my colocataires vm is the last thing remaining to do before i'm able to delete the old account (and stop paying for it)

(dreamcompute hasn't been bad, but i like colocataires way better)

now that i've proven to myself that it can work over port 443 and ipv6-only, it's time to configure it properly

next: see if i can move the service over without xmpp clients complaining

but first, sleep 😴

all the clients we usually use on android and linux are now connecting to my new xmpp server at colocataires, with no settings changes, on the https port so it looks like website traffic 😮

i don't have stun/turn turned back on yet, so voice and video calls probably won't work just yet

i don't have the conversations.js web client set back up yet but that's mostly for emergency use

this may be success enough to decommission the old servers! 🎉

https://conversejs.org/ is back up on my domain and working just fine 🎉

old dreamcompute vps is turned off, sitting there just in case for a bit, then i can delete my account 🎉

(i don't hate dreamcompute but i like https://colocataires.dev way better)

think i'm just gonna leave stun/turn not running for now. if both parties are on ipv6-capable networks, calls should work. let's see how often that's an issue

if i want to set up stun/turn, i should abandon my somewhat irrational ipv6-purist intentions and pay the loonie for an ipv4 address

if i'm gonna do that then maybe i can keep almost all of my vm ipv6-only, except for one container that runs coturn?

if i'm gonna do that then maybe i can figure out how to make that container, that only does whatismyipaddress and proxy video calls, shareable with my datacenter neighbors 

my prosody xmpp setup in its new server mostly works great (assuming ipv6 capable network) but somewhere i've introduced a timeout that closes the connection after a uniform number of seconds

pretty sure it has something to do with haproxy, though from a skim of the docs these timeouts are supposed to apply to the initial connection setup, not inactivity

also after a chat with someone more knowledgeable i think i'm resigned to eventually acquire that ipv4 address

i think i might have fixed haproxy closing the socket on my long-lived idle xmpp connections by setting timeout tunnel 1h

i'll check again in several hours to be sure

wish i knew more precisely why this fixes the issue. are clients and/or the server sending keepalive messages more often than 1h but less often than 10m? is the tcp keepalive stuff not being used? someday perhaps but more likely i'll leave it unexamined as long as it works

recent impulses have been like

"this is too long for toots i should blog about it"
"but i don't want to put anything new or deploy a new website until i have something installed to block the scrapers like iocaine"
"so let's install it"
"ehh not enough brain rn, maybe next time"

so i set up some rules to block a good portion of bots (until they smarten up)

which frees me up to actually post some blog 👍

i'll install iocaine properly after that

i want to set up a photo storage server

photoprism seems like a good browsing interface but what i'm more concerned about rn is the upload

so a client on each android phone that backs up photos to the server

but i want to be able to turn the server off for a while, as a normal/expected thing one does, and not have the clients moan about it. they should just retry occasionally until the server comes back online

anybody have a setup like this running already?

musing about how to do high(ish)-availability systems on the cheap, goblin style

• i got this sweet vm on a friend's server
• someday i wanna convince employers they're better off in there, than on aws
• if the host, or the whole datacenter, or the hose from the internet to that datacenter get orbital-lasered to slag in the middle of the business day, how to automatically shunt traffic to backup systems?
• dns records are too cached, too slow to flip

...

• also don't want to send all traffic through a load balancing proxy, expensive and another single point of failure

but wait i have some tradeoffs that might enable some tricks:

• i want high availability for existing users but new users can wait for dns to propagate
• the site can be a "progressive web app" that gets mostly cached in the browser

so in this specific case i think i could do client-side js failover. maybe even a service worker?

wait, how often does the whole region disappear anyway?

that was never a concern multiple employers ago when i got to help out at the datacenter

they did redundant everything inside the rack, regular cable-yank failover tests and everything, but no geographical redundancy iirc

maybe i'll inquire about a vm on another host within the same rack when i get closer to dragging clients on board and just forget about higher availability than that for now

embarrassed to admit that i've today taken one halfhearted step toward learning wtf snmp is by way of (re)reading the rrdtool tutorial

no, not smtp the email sending thing. snmp the monitoring of hardware status thing

all because i want to put up some pretty charts of computer doing inscrutable computer thing

(accuracy? that's like number seven or twelve down the list of nice-to-haves)

well, actually,
my ipv4-only client
-> colocataires' ipv4-to-ipv6 sniproxy on port 443
-> my ipv6-only vm
-> haproxy to unwrap proxy protocol
-> prosody xmpp server
... experiment is not working ✨😕✨

so:

did it never work and i mistakenly thought that it did?
or
did it work at first but i broke it?

an easy fix would be to get an ipv4 address which obviates the need for sniproxy. but dammit before i do that i want answers: is this setup possible? if so, what'd i mess up?

(maniacal cackling)

i have finally got iocaine installed. wasn't even hard, just needed to sit down and do the steps and brain is real good at not that sometimes

hooked it up to the apt-installable anarchism faq for its markov corpus and the biggest canadian flavored apt-installable wordlist i could get

feels good. like the invulnerability you get from your favorite winter gloves and jacket before going out to play in the blizzard

now it's safe to blog again 🎉

i um only just now noticed that the apt-installable anarchism faq, in uncompressed markdown format, which i fed to iocaine for its markov corpus,

is twelve megabytes. of text.

almost 1.9 million words.

iocaine seems to be doing just fine so far

accidentally set caddy to syslog every request sent to iocaine 3 and oh gosh my website is pumping so much poison markov trash into chatgpt and claude rn 😍 💕

and it's using less cpu and memory than systemd-journald to do so

might need to look into setting bandwidth limiters on this thing

i'm still casting around for anti-cloud(flare) mechanisms of regional failover. like if the cable to the datacenter i use gets cut, or there's political upheaval, how to automatically shunt traffic to a different datacenter faster than a dns update would propagate through caches

i'm vaguely aware of this technology called anycast but i don't know much

https://grebedoc.dev/ uses https://rage4.com/ to do it

https://en.wikipedia.org/wiki/Anycast

yeah eat it, ai scraper assholes

(gradually improving my monitoring, iocaine stats newly added to my collectd/rrdtool dashboard)

tiddlywiki doesn't come with a basic to-do feature, to make checkboxes and tick them off without having to tediously edit the page and type some [x]s

but it does have a plugin mechanism. found two plugins (both by the same author) that do checklists: Kara and Todolist

installation instructions made me nervous though, since i'm using tiddlyPWA that is rather different on the backend...

turns out though, Todolist is super easy to install on a self-hosted TiddlyPWA! drag and drop, click the button to reupload the wiki file to the server, and done.

entirely through the browser, way easier than messing around with directories. woah tiddlypwa is easier than stock tiddlywiki!?

i haven't put any rate limiters on here yet (i definitely will), but seems like claude and chatgpt limit themselves to 25 requests per second to my websites. i wonder how they picked that number, and if they'll ramp it up. and if i ratelimit, will they send more requests from other ip addresses. etc.

feels so good to know these assholes' language models are chugging down low-effort ungrammatical poison after ignoring my robots.txt

should i do traffic shaping using tc, haproxy, or shove yet another plugin into caddy?

should i slow the response down to a trickle for all the llm scrapers, or randomly drop their connections? 😈