lab notes
Alright, party people. This week I went back to reimplementing Prolly Trees. I wanted to finish out the Lattice Merkle Tree. But given that my goals aren't to just fiddle around in applied research and Prolly Trees already work, I reimplemented Prolly Trees from scratch. I was delighted
lab notes
This past week, I'd been working on exploring a new construction for a unicit B+tree. I wanted to know if the mechanisms for uncoordinated synchronization of CRDT could be applied here. Given the research nature of the task, I indulged myself with a limited timebox to the
lab notes
In Lab note #029 [https://interjectedfuture.com/lab-notes/lab-notes-029-balancing-nodes-in-a-unicit-tree/] , I was thinking about a different way to construct a unicit tree. Can we create both a description of the splits in a tree and a comparator that would make it a partially ordered set? And with that partially ordered set
lab notes
In my previous lab note #028 [https://interjectedfuture.com/lab-notes/lab-note-028-consistent-splitting-for-node-sizes/] , I was worried that Prolly trees [https://github.com/attic-labs/noms/blob/master/doc/intro.md#prolly-trees-probabilistic-b-trees] were not unicit. When I inserted keys in different orders, there was a small chance that splits would propagate to the end
lab notes
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?
lab notes
👉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#
lab notes
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/
lab notes
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
lab notes
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
lab notes
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
lab notes
I been reading various papers on CRDTs to deepen my understanding of them. That's when I happened upon a paper that constructed Merkle-CRDTs from Merkle-DAGs [https://arxiv.org/pdf/2004.00107.pdf]. > Surprisingly, the internal merkle data structure of Git is like a vector clock. It establishes
lab notes
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