nice, the “draw from your phone and see it at home” thing is pretty much the same problem I have with a small shared pixel canvas game I run, so on your open questions this is what ended up working for me. I didn’t go websocket, it’s SSE for server to client and a plain POST for every action, the POST response is kind of the “rpc return” and the change goes out to everyone else through the SSE stream. conflicts were a non issue because it’s one node process with the state in memory, two clicks on the same cell just apply in order and last one wins, the only place I needed a real check was undo (it answers 409 if someone touched the cell after you). for reconnects I don’t try to replay what you missed, EventSource reconnects by itself and on reopen the client just fetches the whole canvas again, it’s small enough that it’s cheaper than being clever about it. curious if the phone going to sleep gave you trouble with the websocket

from the agency side, a lot of that 53% is just sites nobody gets paid to touch. clients pay for the new feature or the redesign, not for swapping $() for querySelector on a site that works, and on wordpress some plugin loads it again anyway like OP said. for something new I wouldn’t pick it, but I don’t expect the number to drop fast, it goes down when sites get rebuilt, not when devs stop liking it

i run a small browser game on a hetzner vps and for me the bots were never a load problem, it was the stats. the game shows how many people are online and every crawler that opened the live stream counted as a new player, in early october it was 28 of 61 stream opens. then a headless chromium on residential proxies, different ip every time, made 40 fake players in two days. what caught it was the Sec-CH-UA header, it said chromium 146 while the user agent said chrome 120, real browsers don’t mismatch like that. i don’t block them now, they just stop counting as people, which is kind of depressing too i guess

nice! for anyone with postgres in the mix, what bit me wasn’t the backup itself but the disk. a table in my side project kept one snapshot per minute and never deleted any, the disk hit 100% and postgres went down with a PANIC for like 40 min. now the nightly pg_dump writes to a .tmp, checks it with gzip -t and only then replaces the old file, and the app warns me if the newest dump is older than 26h or suspiciously small. restoring is just loading it into an empty db and starting the app, boring but it’s the part you actually want to know works

one or two services first is the right call, the scope creep is real lol. good luck with the move, and do a full restore of the photos while the box is still at home, that’s the one thing you really don’t want to debug remotely

Plan sounds fine to me, debian + immich in docker + tailscale is pretty much the boring setup and boring is good for a box in a shed. one thing I’d do before carrying it out there, install tailscale and ssh, reboot it a couple of times and make sure it comes back on its own without a screen, because walking to the shed with a monitor gets old fast. also something like uptime kuma on another machine (or your NAS) pinging it, so you know it’s down before you’re on holiday and the photos stop uploading. I run a box at home I only reach over tailscale and that’s the part that saved me most.

good to know about the limit, thanks. for one domain plus DNS-01 that’s all most of us need anyway

yeah that sounds like exactly it, a snap that never worked still sitting there. “snap list” will show it, then sudo snap remove <name> and you’re left with only the docker one, so whatever you open is the right one

spain, so CEST till tomorrow actually, the 13:45 UTC slot is 15:45 for me. 7:45 with people around sounds way nicer than my timer lol

They don’t go away on their own, every installed snap is mounted as its own loop device and snapd keeps an older revision or two so it can roll back, so the number moves around after updates. snap list --all shows which snaps they are, if one says disabled that’s the old revision and you can remove it with sudo snap remove <name> --revision=<rev>. about libation, if it’s installed as a snap itself that could be the actual problem, snaps are confined and can’t read folders outside your home or on other drives unless you connect the removable-media interface, so I’d check that before worrying about the loop devices.

Good to hear it’s been smooth, the caddy plugin was the main reason I looked at it in the first place.

oh, didn’t know that, thanks for the heads up. deSEC still hosts dns for free if you bring your own domain I think, so a cheap one plus deSEC for the acme dns challenge still works, just not the free subdomain part

that’s actually a nice idea, updating with people around makes it way less of a chore, and someone always knows the weird fix. I’d probably steal it if I had more than one box to look after.

same here on the reboots, I never let it reboot on its own either. for me the reboot wasn’t the problem, it was needrestart bouncing nginx and postgres right after the upgrade, which you only notice if something long lived is running at that moment, like a stream lol

Interesting idea, but in my case it would feel worse I think, each paint costs a charge, so undoing both means two people lose a charge and nobody gets the cell. I don’t think it happens much at our size anyway, two people on the exact same cell inside half a second is pretty rare. last write wins is a bit unfair but it’s simple, and since every write is stored you can always see who painted what

512mb and getting killed every morning at the same time sounds like a fun one to track down lol. a fixed weekly slot like your tuesday evening is probably the sanest setup honestly, I just know I’d forget.

yeah exactly, no reboot, it was needrestart restarting nginx and postgres after the systemd update. you’re right that the timer is kind of the blunt fix, the cleaner one is probably telling needrestart to only list instead of restart ($nrconf{restart} = ‘l’ in needrestart.conf), or excluding nginx from it. I went with the timer because I still want things restarted, just not while I’m live

it’s a single cheap VPS that only I look after, so I’d rather get security patches the same day than remember to log in and do it, I guess that’s the tradeoff. and yeah you’re right about scheduling, that was the whole fix, the default timer runs around 6 UTC plus up to an hour of random delay and that happened to land on top of the stream. moved it to the afternoon and it’s been quiet since

nobody said desec.io yet, it’s a non profit from berlin and they give free subdomains under dedyn.io, with a proper API, so you can do the DNS challenge for let’s encrypt (there’s a caddy plugin for it too). I haven’t run a domain there myself so can’t say how it is long term, but for a “try some things” domain it looks like the least shady of the free ones I guess.

Same conclusion here from the other side, I have a small multiplayer browser game where everyone paints cells on one shared grid (node, postgres, SSE), the client applies the paint right away and the server either confirms it or answers with a 409/429 and the client puts the old cell back. the rejection part is the one that took me longest honestly, a mutation that is valid locally but the server says no (out of charges, same color already there, world paused) and you need a different message for each, otherwise people think it’s lag. conflicts are just last write wins per cell, but that works because every write is a row in an append only events table, so nothing is really lost and you can replay or undo. and on reconnect I don’t try to merge anything, the client asks for the whole state again, at that size it’s cheaper than being clever.