2025-10-01T05:24:41.371Z
Maybe I'll even start on HTTP/2 once this is over 😐🔫
2025-10-01T22:54:28.485Z
Completely unrelated; Steak and Shake seems to have added auth to their drink fountain now
You get a QR code that corresponds to the size of drink you bought, and you have to scan it to unlock it. Then you can use the fountain. I haven't gone back to see if it lets you go again yet.
I scanned the QR code on my phone and learned that it's just a (presumably) random hex string
Here's mine if you want it: e46ccf53568e472582b0bb60cb708324d2a3d836ba484d0ba23bbd22dcd2c7a91759358783473
2025-10-01T22:57:42.348Z
I'm not sure how I feel about Drink DRM, but I suppose better if I can still get refills
2025-10-01T22:59:10.364Z
I figure this system has to be networked though. I'm certain they phone home to validate this code, and probably check how many refills you've done / if you've filled your drink
But I'm not joking, this would probably be a good use for a JWT in a QR code
2025-10-01T23:02:22.667Z
No more dependency on a network, as long as your scanner has the right key it can validate the token, and you can encode data like drink size (currently pulled from the query) and validity period.
Or you could not DRM your drinks 🙂
2025-10-01T23:07:13.505Z
Opinion dramatically dropped, just did research, they allow one single refill per meal
I can pinky promise that I can do more than one refill and they will still come out ahead. Syrup is insanely cheap
2025-10-01T23:27:49.377Z
Of course the refill is less volume than the first fill
2025-12-26T22:22:40.314Z

2025-12-26T23:14:10.178Z
The doohickey
2025-12-31T05:49:17.207Z
SpruceHTTP had a big change today, it's no longer spawning worker threads for every request. It used to have a pool of workers just waiting so it wasn't too bad, but there was still about 250 ms of time spent getting a worker thread in the worst-case.

Spruce is no longer multithreaded. That sounds like it should be worse, but it's actually not! Node is very efficient with how it handles I/O, so having it on the main thread means I no longer need to transfer a socket through IPC, which apparently takes a bit.
2025-12-31T05:51:43.367Z
Okay, correction, it does have ONE extra thread: a separate thread it spawns off at the beginning before it deescalates so it can read privileged files (like reloading the config later)
But the end result is that individual requests now take only ~10 ms on average!!!
Very good in my opinion
There's also no longer any sort of cap on how many requests can happen concurrently!
Too tired right now to go into the details of exactly what changed and why, but I'll do that later.
But the hope of all this was that it hopefully fixes the weird issue where some connections just time out
2026-01-22T18:03:07.344Z
Relevant to future Spruce development:
I think it's very odd that OpenSSL and other TLS implementations bring their own QUIC implementation
2026-01-22T18:04:51.265Z
In my opinion, this breaks the commonly accepted model of the TCP/IP stack (or OSI if you're old fashioned)
2026-01-22T18:08:29.861Z
I know technically QUIC exists at the session layer because it runs on top of UDP, but it effectively acts like another transport layer
2026-01-22T18:09:33.158Z
Implementing a transport layer is not the job of a TLS implementation
2026-03-09T20:54:32.172Z
I've read too many RFCs for this year's upcoming April 1st, and I blame Bluesky
2026-03-10T04:49:10.221Z
Alright, well I've done all I needed to do with ATProto and Bluesky for now. Thank goodness, talk about making everything harder than it needs to be
Pretty bad when Mastodon is easier to work with, ActivityPub isn't all that great after all
2026-03-10T05:41:34.064Z
Just kidding I still have to find Bluesky's non-existent documentation on how to revoke sessions
Bluesky try to actually document anything related to auth properly challenge: impossible
"Yeah you can revoke refresh tokens with com.atproto.server.deleteSession" okay how?
https://docs.bsky.app/docs/api/com-atproto-server-delete-session this is useless
It doesn't follow the same auth requirements as any other authorized procedure, but those differences are completely undocumented. Thanks.
That's enough for tonight
2026-03-10T05:52:07.413Z
Haha you're supposed to use the refreshJwt you get when you call com.atproto.server.createSession or com.atproto.server.refreshSession, not the refresh token you get during OAuth that's completely incompatible! How was that not immediately clear???
2026-03-10T05:53:31.571Z
Duh, everyone's completely aware of the two entirely distinct and incompatible auth systems that Bluesky implements and makes no considerations or notes of in their documentation!
2026-03-10T05:56:19.022Z
On that note, it's seemingly completely impossible to revoke an OAuth client's refresh token (which can live for up to two years!!!!!!!), because even the client application can't willingly give it up! And Bluesky offers no page to view and revoke your authorized apps! Terrifying!!!
You're literally better off using app passwords that grant total control, but you can revoke them, than OAuth, which you can't take away
How was this deemed ready for production at all???
</rant>
2026-03-10T06:09:03.809Z
Okay, I take ONE thing back. You can revoke OAuth apps as an end user on a Bluesky hosted PDS at https://bsky.social/account , something I had to dig through blog posts to find and is not immediately linked to.
2026-03-10T06:10:17.020Z
And if you operate your own PDS there should be a similar web management page
Still looking for the way a developer is supposed to revoke their own access token though!!!
2026-03-16T20:19:38.215Z

You have got to be kidding me Twitter (now known as X)
Identifying your OWN logged in user costs money now?
Truly degenerate levels of greed
A whopping $0.01 per call too, really? Do you really think your platform is even worth that much?