The Inversion
Techie article! The Inversion is my architectural vision: freeing our data into a virtual world.
I’m about to start publishing over time a series of techie articles comparing my approach to that of a couple of others. Non-techies can stop reading!
The article series is aimed at those fellow techies who are thinking: “OK, but what about Technology X? Technology X has no apps” or “Technology X frees your data”!
It’s true, “Technology X” does indeed free your data.
But I need to explain, for each “X”, why it’s still not aligned to my vision, and what changes would be needed to “X” to make it so.
To do that I need to quickly document the technical architecture of my vision of how things should be, to form the basis of the comparison. I don’t go into lots of detail about my vision or its justification or why it’s better, this is just about how there’s nothing out there that does what *I* want!
The vision manifest in the Object Network and OnexOS is of “The Inversion”. This becomes apparent in a number of ways: an Imperative-to-Declarative flip, and turning apps inside out. It also propagates into the network architecture as the move from client-server to at least federated, then via “Local-First” ultimately to full peer-to-peer. It can also be described as “app-free computing” or a “Data-First” philosophy, in analogy to “Local-First”.
Imperative to Declarative
A primary aspect of The Inversion is the choice point that flips you inside-out from the Imperative to the Declarative programming style:
Imperative style has “behaviour is first class and data is under its control”.
Declarative style has “data is first class and the behaviour is driven by it”.
It is often characterised by the phrase "What not How": you simply declare What are the dependencies and transformations from input state (captured by references and patterns) to output state, and let the “engine” inside work out How to do it.
Examples are CSS, makefiles, SQL, functional and logic programming, and spreadsheet formulae.
In these Declarative systems, the state is first class in the programmer’s mind - in terms of the patterns for matching that state and the transformations of that state that are being created. The “engine” then works “behind the scenes” driven by that state, to evolve it or to manifest new states.
Declarative Inversion part one: the data model
If data is free and first-class, then it can no longer be in ad-hoc, inscrutable and redundant aggregate formats such as Word’s .docx - a format that basically does the same thing as the more open and thus better designed HTML. We can now break all these structures down and harmonise their contents.
In the Object Network, our first-class data is split up into chunks called objects* that are cast in open standard types.
*Note that there are only four words we can use for our data chunks: objects, items, things and entities. I chose the one that I thought would work best for non-technical folk, but it does mean that my objects are inside-out compared to techies’ OO objects. Sorry about that!
These object types are dis-aggregated into elemental types, down to single paragraphs or to-do items. This then allows us maximal freedom to re-assemble and re-link them all back up again in ways that suit us. Which means another core feature is links between these objects as their IDs.
Declarative Inversion part two: internal animation
In their simplest forms, the above examples of Declarative technologies don’t actually deliver Turing Completeness (TC): they are simple transforms from state to state - output dependency on input. TC requires some circularity, normally delivered by iteration, recursion, circular dependencies or feeding output state back into the inputs. TC in my vision is achieved through saving outputs as persistent object state that is used to feed the inputs of the next cycle:
An object's next state is a function of its current state and the state of peer objects it observes through links.
In this way objects can be seen as “internally-animated”, as they manifest their dynamic and interactive behaviours and their mutual dependencies. This creates a live or living space for our little linked-up local data objects - with us “users” as just another live animated data object that’s able to interact there like avatars.
Some object animations, interactions or behaviours will be default and hard-coded, for common types and common behaviour, configured by object property values. Others, probably a lot fewer, will be described by rule objects written in the Onex language, rules that are linked to from any object running them.
FP and state
Interestingly, both OO and FP have hiding and deprecation of state, respectively, at the centre of their philosophies, however they are still Imperative and Declarative respectively, and I believe FP has taken its deprecation of state too broadly.
As everyone knows, OO has Imperatively-invoked external method “APIs” on objects that do physically encapsulate or hide their data.
But FP has external input and output data and the functions lie between them, thus “behind” the output data. One of the key tenets of FP is that “the output result of a function can always replace the same function call with the same input params”. So in this sense the function or “behaviour” of any output data is “internal” and even uncertain whether it was run at all, and you don’t need to know if that data is just a constant or cached value in order to use it. Hence, this external state is actually not deprecated, but primary.
It’s unfortunate that the deprecation of mutable state internally has led to mutable state being seen by many of FP’s evangelisers as “bad” externally too, forcing their model to try and embrace state with in-language bolt-ons like infinite or recursive streams and Monads.
I simply see FP as the glue between successive, first-class, external object states in a broader programming model, where FP doesn’t do everything, not even itself needing to be TC, as mentioned above.
Turning apps inside out
The Inversion is part of the “sales pitch” to non-techies using the Object Network’s “OS without apps” - OnexOS.
Here, the idea being presented is that apps are turned inside out: your data are now freed into an interactive space or virtual world, while in the same step the apps’ functionalities are absorbed into common “internal animation” code for each type of data object, including a user object.
Data is now normalised and dis-aggregated into mashable objects of many standard types, and their behaviours are similarly small and predictable and driven by those types.
Each object has a unique id for sharing and linking all the parts of the world together.
Peers
This Inversion carries through into networking in the OS, where we move from a centralised (client-server, silo’d, service-oriented) architecture, to a decentralised (federated, distributed, p2p, data-oriented) architecture.
This starts with the concept of “Local-first”, where your own data objects are stored locally by your own OS, rather than in the cloud. Having said that, our Inverted server operating systems also work this way, storing their own objects locally to them.
Next, each local link to and between objects, that was used (in “Declarative Inversion part one“ above) to re-aggregate and restructure them, becomes a global link or global ID - like a URL or UUID.
This then creates a single, global, shared data object network (or data web, substrate, graph, fabric: there are many naming options!)
From that point, the next step is to share objects and their updates directly, peer-to-peer, between local datastores, whether “client-side” (our PCs, etc) or “server-side” (online hosts).
As well as proxying, cacheing and routing objects and their updates, online intermediary servers can be used as backups or proxy authorities for our precious local data; we simply push our stuff to servers we run or trust.
This extends the Inversion from single hosts to all and any devices across the planet, with links now pointing between peer objects hosted across the internet.
Summary
So that’s all the core points of my technical vision that I’ll need to compare with others.
There are three broad areas:
Deconstructed is the key motivating half of the full Declarative Inversion: freeing our data and standardising its object types, then linking it all back up into aggregate structures via object IDs carried within other objects.
Declarative completes the Declarative Inversion, giving objects their “internal animation”: their dynamic and interactive behaviours and mutual dependencies. This creates a live or living space for our data objects, with us (“users”) as just another object able to interact there.
Decentralised - starting with these linked-up, Local-First objects, they are given globally unique IDs or links, creating a single, global, shared data object network or web. We can then share them and their updates through trusted federated servers, or peer-to-peer from device to device.
The end result is a seamless global web of little, live data objects.
Of course, any part of that web can be made private to one or more other data owners. This web will be manifest by “Inverted operating systems” that have no apps: “Data-First” operating systems.
Scoring against The Inversion
So here is my corresponding scoring system:
|Deconstructed
| |Declarative
| | |Decentralised
| | | |OS
| | | | |3D
|8 |8 |8 |4 |2 |
--+--+--+--+--+--+
XX|🟢|🟠|🔴|🔴|🔴| 12
--+--+--+--+--+--+Amber gives half points.
We start with Deconstructed - you get an amber blob if your product puts data first but that data isn’t described in standard object types, or isn’t actually dis-aggregated into finely-re-linked objects. Spreadsheet cells would get amber also because the level of fine detail in a grid loses coherent object structure.
Then Declarative, where you get an amber blob if your product is Declarative but not Turing Complete, for example only like a spreadsheet without circularity. Your interfaces (between objects including users) must be explicitly all about data and observation to get green.
Then a green blob if the technology uses a Decentralised architecture, at least as far as the Web, with hosts owned by multiple parties and something like URLs to and between data objects.
Finally, it’s meant to be an “OS with no apps”, and thus must support 3D object types as well as 2D ones.
If you’re a techie then look out for the comparison articles coming very soon. Hit the subscribe button to be notified when they’re online, and/or feel free to leave a comment or question here!