Continuum's backbone structure is at final development stages tomorrow session will revolve around reducing redundant writes back story: -Project Definition Continuum is a browser environment ordered-array-virtualizer, you store an array on the disk then Continuum single job is to retrieve only consumed items without having to load the whole array into memory The Current Drama: -IndexedDB can't do Positional Access the classic b-tree structure powering IndexedDB can only do O(m*k) positional access, like linked-list but worst, so in order to access arr[50] where arr.length is 100 we can only start at either arr[0] or arr[100] then do a O(50*k) to reach arr[50], otherwise, we must keep an in-memory array of all addresses (b-tree keys) in-memory beforehand to achieve O(1) which defeats the propose, also the newer and 10x faster OPFS api doesn't have a native b-tree, its a pure file system so we would need to DIY our own b-tree on top to use it. -Evidently, Continuum needed a DIY Positional Access structure (better known as fancy-ranked-something-something-fancy-trie) by which we solve the downfall of IndexedDB b-tree and also enable us to power the Continuum with the faster OPFS api by that we can have Continuum backbone as an independent core and treat the underlying storage api's (OPFS or IndexedDB) as plug-ins