Interjected Future

Last time [https://interjectedfuture.com/lab-notes/lab-note-028-consistent-splitting-for-node-sizes/] , I found balancing nodes seemed to be in conflict with the property of a unicit tree. A balanced tree is desirable for efficient queries. A unicit tree is desirable for Merkle Trees for fast equality comparisons. Was there a way to get both?

👉See Lab note #30 [https://interjectedfuture.com/lab-notes-030-prolly-trees-are-unicit] for corrections. Prolly Trees are unicit, and don't exhibit the bad behavior I've outlines below.Last week [https://interjectedfuture.com/lab-notes/lab-note-027-breadcrumb-to-prolly-trees/] , I was looking at Prolly Trees [https://github.com/attic-labs/noms/blob/master/doc/intro.md#prolly-trees-probabilistic-b-trees] . A major concern

When I found the splitting of nodes for Merkle Search Trees to be problematic [https://interjectedfuture.com/lab-notes/lab-notes-025-split-condition-for-merkle-search-trees/] , I stumbled upon Prolly Trees [https://github.com/attic-labs/noms/blob/master/doc/intro.md#prolly-trees-probabilistic-b-trees] . They were first described by the Noms, a git for databases [https://github.com/attic-labs/

Most desktop, mobile, and web apps use a form-based metaphor to manipulate the state of the digital objects sitting in the database. This is a little odd when you think about it. Most things in the real-world don't work like this, aside from our complex machines. What would it look

I started outlining how to compose different CRDTs together to make an Immutable Conflict-free Resolution Relations [1] construction, based on the Merkle Search Tree. When designing it, I first tried sketching out the entire construction by drawing, but I was left confused. I wasn't sure if all the pieces actually

A major implication not often included in discussions of local-first software is how to deal with migrations. The degree of the problem depends largely on how you fence the boundaries of your system. If your local-first system allows any number of replicas to come in and out of the network

This week the todo list is coming along. The app works like a regular todo list. There's no server, and yet it persists the data between reloads. I wanted to see how it would feel to have a database as the state management library. Instead of having an app state

I'm making progress with the todo list. While I can only add tasks right now, it persists the data without a server and can sync between different open tabs (within the same browser). I've built my share of web apps before, yet I've never built a local-first app. It does

The couple of months have been full of changes. It was actually a good time to write down the process, but unfortunately, things changed so quickly that I didn't get a chance to process it all in writing. This is an outline from since the last time. A couple of

One major thing I did in the last two weeks was to take a step back and review the current landscape of real-time databases and syncing frameworks. In my last essay [https://interjectedfuture.com/state-management-library-front-ends-are-looking-for-is-a-database/] , I came to the conclusion that for app architectures that want to retain state on

For any endeavor, there are two ends you can work on: deep technical work and finding the market. This past week was mostly spent on the latter. One of my unfair advantages is access to Bookface, where founders detail problems they face. Searching for posts on "no-code" or "internal tools"

This past week was spent researching and reminding myself of the core problems of building interactive apps and addressing state management problems. * React I Love You, but You're Bringing Me Down [https://marmelab.com/blog/2022/09/20/react-i-love-you.html] * Get in Zoomer, We're saving React [https://acko.net/blog/

The persistent data structure in Datomic is used as a live index for querying. However, it's unique in that it saves itself to a storage-backed key/value store in segments–continuous pieces of data akin to the data in the leaf nodes of a trie. By fetching a key/value

Spent the week fixing issues with insertion, mostly with different edge cases. Was able to solve an issue with inserting at the beginning and the end of the trie. The edge case was that take_left and take_right should take into account when we take everything or take nothing.

After the iteration over values was done, it was quick work to write tests for concatenation and make sure that it was working correctly. Then the time thereafter was some cleanup and moving stuff out to their own files. The work this week to implement take_right and take_left,

Most of this week has been spent rewriting `append()`. This stemmed from mostly following the pseudocode from the L'Orange paper [https://hypirion.com/thesis.pdf] too closely. Excited about ChatGPT, I used it to convert the pseudocode to Rust code and tried to go from there. However, in the end,

Took a bit of a break, but have been back at it. The most involved part of implementing the relaxed radix balance trie is the concatenation. I had to consult three [https://hypirion.com/thesis.pdf] different [https://raw.githubusercontent.com/nicolasstucki/scala-rrb-vector/master/documents/Master%20Thesis%20-%20Nicolas%20Stucki%

I'm usually not hung up about the programming language I use, but given Jamie's take [https://www.scattered-thoughts.net/writing/assorted-thoughts-on-zig-and-rust/], I did some deliberation about whether to use Zig or Rust. I ended up going with Rust, because I'm not a seasoned systems programmer, so I figured having the

While moving forward through the implementation, it wasn't clear how the indexing worked in detail. How do you determine what segments were different between the live and storage-backed indices? By definition, aren't all segments in the live index novel? But more worryingly, what is the key used to store the

A good part of the week was spent reading and watching talks on "The  simple essence of automatic differentiation". I got the gist the first go around but much of the details were opaque to me. Reading it this second time around and actually working through the examples helped with

Reading more papers, mostly focused on Relaxed Radix Balanced Trees, since other trees, such as B-trees, Finger Trees, and HAMT trees seem to predate the research on this one. The premise is generally pretty simple, but the devil is in the details. The papers on it are fairly clear. I