#gitAnnex HTTP API server proxying to other P2P remotes is now mostly working.

Putting this together was like if you spent one month making one jigsaw puzzle and another month making a second one, and then you needed to somehow seamlessly connect the two. Not that it wasn't in mind from the beginning, but how does all this match up?

It makes my head hurt and I've spent several hours struggling with fitting the pieces together so it was a surprise when it just started working.

oh sweet, they transferred ACH details over to this very competant company that will certianly never suffer a data breach

entirely unsusprising that their (mandatory) SMS verification fails to work

dear chatgpt, does this password contain 3 of the 4: An uppercase letter, a lowercase letter, a number, and a special character?

Actually, a password that meets those reqirements was still rejected as not. Not even gonna speculate, I used a cat to generate a password they happen to accept.

looks like if your password doesn't meet their arbitrary and capricious requirements, they silently lock the account, rather than rejecting the form submission

perfect. no notes.

the unasked-for transfer of my account from #Vanguard to Some Company, which I never wanted, is off to a great start with 3 emails purporting to be from Some Company, whose headers suggest 2 other companies sent them, and the one with the login link not even using Some Company's domain.

And then after setting a password, login fails.

Good this this is not important...

#gitAnnex testremote 100% pass on a remote using the new HTTP API!

(There is the small matter of a build warning about "Defined but not used: ‘proof’" so it's not actually done, but it's very close now.)

unexpected development: #gitAnnex is much faster at downloading files using the new HTTP API than using ssh. Like 231 mb/s vs 48 mb/s.

Wow, I didn't realize ssh was still so slow. I know, encryption (and I'm comparing it with HTTP, not HTTPS), but...

Finally gotten #gitAnnex using the HTTP API that I've been developing. A few API endpoints still to wire up, but the end is in sight.

having performed BASIC INTERPERSONAL COMMUNICATION and ROUTINE CLERICAL CHORES, am warming up the TYPE INFERENCE ENGINE of my UNIVERSAL TURNING MACHINE for the descent to the SHEER ROCK FACE where I shall spend my day chipping out BEAUTIFUL IDEAS.

programmed for 15 hours today. eep

omg I have forgotten how to type on my laptop

successful vacation

A week is forever / a week is not enough

Stuck on an island because the ferry BSOD. Sweet

Debian needs to package a privacy respecting Mozilla fork already.

Put my GPS in nautical mode

uspol

Joe Biden on stage with a giant 75 in front of him

type checker just informed me I'd forgotten to include a header in my http response

We’ve been quiet over here on the blog because all of our new content at the moment is showing up in emails instead.

These monthly newsletters are full of timely tips, links to free books, and personal this-and-that. They’re also free, of course. I hope you’ll consider signing up and joining the club!

<p>The post Join our email list! first appeared on WetKnee Books.</p>

is there anything more fun than helping rigid, skolem types escape their scope? #haskell

finally! #gitAnnex

um

after all that, I now have half a dozen pairs of functions like

serveFoo :: [params] -> Handler foo

clientFoo :: [params] -> ClientM foo

Also I've learned that servant-client does not support websockets, which puts a bit of a spanner in the works for one of my API endpoints.

banged out 588 lines of code today which feels like a *lot*

also the code does nothing, it's all just HTTP serialization fluff

111 lines in all to define the data type, not bad

planning to spend 2 hours writing down a single data type #haskell #servant

Had almost escaped playing any more Utopia Must Fall, but then i discovered the commando strategy, so it's shieldless runs from day 1-10, going deeper into this thing.

Best kind of being surprised by the behavior of my own software: Went out to the solar powered fridge freezer conversion and found it still had a bag of ice in it from 2 weeks ago.

Despite working on the temperature control and power allocation for years, and knowing that the thermal mass in the bottom is consistently below -2C overnight, even after a cloudy/rainy day, this is still somehow surprising.

let's leave aside any reaction to djb and/or the part of the netstrings spec where he gives in an example /* >999999999 bytes is bad */

Like, gigabytes do exist, djb.

if you encountered a HTTP API that used netstrings for bodies that contain binary data followed by some JSON, how would you react?

import netstrings library and no problem
implement netstrings in 10 minutes, no problem
ugh, this is not web native

One of my favorite sentences from a rather good manual.

happy 4th of july to everyone in the UK btw

pondering installing a Schuko outlet in my #offgrid house

yes, I'm in the US, lol

Through an unfortunate sequence of events, which includes but is not limited to systemd reaping ssh session processes on connection loss, I am now gonna have to transparently roundtrip per-node monotonic clock values through #gitAnnex clusters. This is gonna be interesting.

"to talk with someone I want to get obscure settings just right in the mixer" said noone ever #pulseaudio

huh.. looks like haskell's http-client does support it. Dunno about server side

I am needing the HTTP server to send the client an indication that it has started processing a request before it receives all of the client's response.

Wondering if HTTP 100 continue is something I should even ponder using, or should I go right to websockets?

What are the chances a given HTTP stack will allow using 100 continue?

picked some blackberries today

well that took 8 hours to finish writing itself.. but it does work!

Time to make #gitAnnex proxy (and cluster) support special remotes. I had not been looking forward to implementing this. And yet, the code... it is writing itself.

never have two vacant podiums looked so appealing

#gitAnnex distributed clusters working!

That was a single upload into the cluster, which streamed it onto 3 local nodes, as well as across "the atlantic" to another cluster gateway, which streamed it out onto 2 more nodes.

charming how #wayland can lose key release events when the system is fully loaded

Yeah, I'm fork bombing myself repeatedly today and my terminal contains stuff like this:

k gitttttttttttttttttttttttttttttttttttttttttt-annex-shell -9

(wayland on gnome if it matters)

tried out mounting a solar panel on my powerracks to get a feel for it, and I'm impressed with this mount's design

the self-inflicted fork bomb... it burns

Still need to add cycle prevention though.. A minor extension to the P2P protocol.

In 6 hours I've extended #gitAnnex to support clusters that are distributed geographically, with gateways in different locations each serving their own set of nodes, and relaying requests between one-another.

it was easy! Helps to already have a fully distributed system when building this kind of thing I suppose.

ordering a 5 tons of gravel and a like amount of firewood, and ... what about sheep?

Finished up #gitAnnex clusters last week, and it was very nice to run `git-annex testremote` against a cluster and have it succeed.

But what about clusters that are themselves geographically distributed? This will mean having multiple gateways that as well as storing data on their nodes, repeat messages to other gateways. It will need a way to prevent cycles, but otherwise I think it will Just Work! Especially nice that a single file upload to a cluster will stream through to all desired nodes.

#caturday rest day