brush rendering is now completely client-side.
the server only receives edits the client would like to do, in the form of PNG images of chunks, that are then composited onto the wall
known issue: it is possible to brush up against the current 256 chunk edit limit pretty easily.
I'm not sure it can be solved very easily though. the perfect solution would involve splitting up the interaction into multiple edits, and I tried to do that, but there's a noticable stutter for some reason that I haven't managed to track down yet.
so it'll be kinda crap for the time being.
the goal is to rewrite haku completely, starting with the VM---because it was the most obvious point of improvement
the reason is because Rust is kinda too verbose for low level stuff like this. compare the line numbers between haku1 and haku2's VM and how verbose those lines are, and it's kind of an insane difference
it also feels like Zig's compilation model can work better for small wasm binary sizes
and of course, I also just wanted an excuse to try out Zig :3
for faster load times, and seamless updates.
because for some reason ServeDir can't do it correctly, and it tells the client "yeah hey nothing changed" even if something changed
it's probably okay, but it's incredibly easy to read localStorage from the frontend and get a hold of the secret
would be nice (would it?) to have more proper session tokens I guess but we're not doing that right now
I'm not entirely sure if generating the password on the server is legit like this, but it leads to an incredibly frictionless experience and I'd like to keep it. if possible.
I don't really see a difference compared to password managers generating passwords for you and showing them in plaintext
obviously actual passwords are stored within the manager which requires a master password, but like. do we really need that. the secret isn't shown to the user and it's very long.
too bad the browser secure storage API or whatever isn't ready yet
