aguacaterojo

Underpinning my current app is an e2ee local-first sync engine, basically it is a traditional client-server sync (encrypted logs + snapshots sequenced with integers). It sends bundles of Loro CRDT operations. I wrapped the client side in WASM to power the web app and the CLI and have started a swift wrapper to port to native iOS. Bundle size is 3MB/1.2MB g-zipped so pretty happy with it. I've realised that web encryption is kind of bs (at least not as "WE CAN NEVER ACCESS YOUR DATA" as some vendors state) if someone else is distributing the app.

Over the last week I have done a lot of performance work & data remodeling - CRDTs are interesting because you can let data fall through the gaps if you're not careful.

For Spanish for example, compared to spanishdict.com course which is a similar format but has a defined length and doesn't encourage you to continue indefinitely, is much more precise, follows a practical story arc - introducing yourself at school, how did you get to school, going on vacation with family etc etc. It jumps from location to location each unit and explains regional differences in grammar/vocab.

Floating windows are a little pointless but aesthetic choice or a one shot ui. FPS would be nice, also distinction between canvas and void. Video export works great.

Very early days but will keep updating them & adding more.

I've got eg-walker & Diamond Types in my reading/youtube backlog. Diamond Types went further down the backlog because of "wip" on the repo! I will look into Antimatter too.

In general, you don't really get to compact tombstones meaningfully without consensus so you really are pushing at least remnants of the entire log around to each client indefinitely. You also can't easily upgrade your db you're stuck looking after legacy data structures indefinitely - or you have to impose arbitrary cut off points.

List CRDTs - which text CRDTs are built from are probably unavoidable except for really really simple applications. Over the last 15 years they have evolved, roughly: WOOT (paper) -> RGA (paper) -> YATA (paper) / YJS (js + later rust port) -> Peritext (paper) / Automerge (rust/js/swift) -> Loro (Rust/js). Cola (rust) is another recent one. The big libs (yjs, automerge, loro) offer full doc models.

Mostly the later ones improve on space, time & intent capture (not interleaving concurrent requests).

The same few guys (Martin Kleppman, Kevin Jahns, Joseph Gentle, probably others) pop up all over the more recent optimisations.

Wolves scavenge opportunistically, but they are first apex predators. Their primary food drive is to hunt in packs for large game and gorge. Dogs are not so far removed.

You don't need to because you compile it from source yourself

The counter-point is that in the case of a web browser you are studying deeply one of the most impactful technologies to exist, and you will learn 80% of the most important lessons with a minimal working build, maybe 0.1% of the real thing. You may learn and execute much faster too because there is a clear blueprint, and you are likely riding a wave of passion that will carry your mind to places you won't have expected.

The perspective gained puts you in a much better place to identify & execute successfully more impactful work. The work may be the seed of something more important, but unseen or unknown yet.

op worked at us airforce base managing access control to global intel systems. he delegated authorisation check to jr. jr told op they checked out, however, jr had not adhered to latest security protocol that required cross checking request against request database, relying instead only on physical credentials. op granted access however asked that an officer watch the civilians’ access directly.

a week later it turns out the civilians were conducting pen testing for the systems and op had to debrief how they gained access.

I traded ELK for Clickhouse & we use Fluentbit to relay logs, mostly created by our homegrown opentelemetry-like lib. We still use Helm, Quay & Drone.

Software architecture is mostly stateless replicas of ~12x mini services with a primary monolith. DBs etc sit off cluster. Full cluster rebuild and switchover takes about 60min-90min, we do it about 1-2x a year and have 3 developers in a team of 5 that can do it (thanks to good documentation, automation and keeping our use simple).

We have a single cloud dev environment, local dev is just running the parts of the system you need to affect.

Some tradeoffs and yes burned time to get there, but it's great.