FadiShawki
commented
7 months ago Researching (Hypergraphic) Version Control through arbitrary traversal of Rays
In the case of Rays, whether something is a vertex/initial/terminal is only inferred from surrounding context. And these checks only need to happen locally in order to decide how to traverse arbitrary structure (as in - I only need to check the presence of something next to me, not traverse the whole direction recursively in order to decide what to do).
More generally, we cannot actually guarantee consistency of anything. And so the system will just need to be able to deal with that at some level. This project will in its initial implementation probably not attack this directly, but it's just a general thing to keep in mind. And something I'll come back to in the other OrbitMines projects.
In the case of a Version Control System this will require the following things:
- [ ] Arbitrary (partial, ..., incomplete) history of arbitrary functions, rewrites, ..., data types (generalized to some arbitrary Ray).
- [ ] This then includes the automatic inclusion of existing data structures
- [ ] Automatically includes DPO(I), ..., Git histories.
- [ ] Allow for the realization that any arbitrary part of the rays are destroyed (this could include local connectivity).
- [ ] This then includes the automatic inclusion of existing data structures
- [ ] Can have a history, but no current value. No structure, ..., type, permutation information on, ..., between vertices except for that of something we identify as history.
- [ ] Arbitrary initial setup not necessarily optimal version. And through time find more optimal one's given a particular situation. (Hence just apply the same version control system on the version control system itself.)
- [ ] Thus requires the automatic shifting between possible ways of representing histories.
- [ ] This thus includes a way of mapping perceived geodesics.
- [ ] Unrolling of loops, ..., orbits, and setup argument for what kind of information one needs to differentiate between iterations of that loop, and possibly what certain initial places were.
Some existing ideas:
-
- Wolfram Physics I: Basic Formalism, Causal Invariance and Special Relativity (2020) ; Jonathan Gorard
- Causal invariance versus confluence ; Jonathan Gorard, Mark Jeffery
- Lorentz invariance, Poincaré invariance (special relativity), Conformal invariance, Diffeomorphism Invariance, General Covariance (general relativity)
- Causal history as identifier (Interesting way of merging the idea of Confluence/Causal Invariance) - This would in the case of Rays just be generalized to any referencing on the
.selfRay - or a selective part of it to differentiate between structure at the node, history etc... (currently already automatically the case for theis_equivalentfunction)
- Causal is more abstractly just some order / sorting. Where order and sorting can be abstracted away as merely some expected property to hold irrespective of input after those transformations.
- Or basically for Causal Invariance: Irrespective of some order in which something is applied, I can after those things which are applied say: "I can transform all those results in some way where they would be expected to be this thing."
- Or: After some variant application of functions, I apply some transformation which accepts all those superposed possible branches, which will all result in some invariant property (boolean check to whether I deem them as the same, or after some ordering function and some check whether I deem them as the same, ... etc.)
- Or: Variance is handled in such a way that after some function application we are left with something we deem invariant with respect to possible inputs.
- As long as you can recall/.../remember something, in the case of some eventual consistency, you're often going to be causally invariance in some local respect (ignoring some difference).
-
- CRDTs go brrr (2021) ; Seph Gentle
- CRDTs: The Hard Parts (2020) ; Martin Kleppmann
-
-
- Riak Core - An Erlang Distributed Systems Toolkit (2011) ; Andy Gross
- Riak & Dynamo, Five Years Later Presented (2013) ; Andy Gross
-
Some others RxDB, ShareJS, ottypes, Operational transformation, IPFS, IPLD, OrbitDB, Git, Merkle Tree, Vector Clock, Plausible Clock, Chain Clock, Interval Tree Clock, Bloom Clock, Matrix clock,
As part of the requirements for broader OrbitMines projects, this will necessarily include a novel way of dealing with histories of arbitrary structures.
This is also the part of the project I will reapply with to NGI by 2024-02-01 as a possible source of funding. I'll soon post more information here regarding that by then.
Discord equivalent: https://discord.com/channels/1055502602365845534/1200225618164461639