and concise paper...Thank You!
I'm especially interested in this topic, as I've gone through most of the listed aspects while evolving the ibGib framework.
disclaimer: I'm going to talk about ibGib here. I'm not hijacking the thread! It's because ibGib is more of a concept than just a framework, and its aspects are tightly related to all things mentioned in the linked paper!
Each ibGib datum is immutable, has a hash (
gib) maintaining internal integrity of each datum, and each is related to each other via rel8ns that provide not just a "single" DAG of evolving a "single" thing through time but rather create multiple monotonically increasing
rel8ns providing possible n-dimensional DAG projections using the same data construct.
I especially liked his look at Copy On Write (COW) and its relationship with the physical substrates of SSDs and spindle HDDs. Certainly interesting relating these things to immutability via COW, but this is one of the novel things about ibGib which also addresses his naming slippery slope. Much like I've learned recently about IPFS, I designed ibGib to have ib^gib pointers, which are the combination of an
ib "name" and a
gib "hash". Together, they provide a unique URL very similar to the IPFS merkle links. If you change the
ib "name", then you are creating a new ibGib, not mutating the "same" one. This is by definition of what an
ib is. It has an internal
data json construct that is meant for this type of thing.
So if you have a "filename", then this is an aspect that is internal to that "thing", so that is what you are "changing" (by creating a new ibGib and relating it to this previous version). This is an important distinction and it partially comes from the fact that I'm approaching these concepts from the ground up and not using the "file" paradigm like many (most/all?) others. So in ibGib, the "filename" is actually part of the content of the "file". And really, the "file" itself is both a "file" and a "folder" as each ibGib has this internal content as well as rel8ns to other ibGib.
Much of this really brings out the delicacies that abound when thinking of what a "single" thing is across branching timelines, showing that there exist many strategies that could be used to resolve these branches into a single thing. The writer's concept of a "file" (and the file-based implementations of these types of systems) combine this resolving strategy implicitly, whereas ibGib allows for the resolution as a separate step. And any resolution itself can be persisted as another ibGib in the strange and wonderful world of supersymmetrical data constructs.
What an exciting paper! Thanks again