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, and ultimately peer-to-peer.
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 programming has “behaviour is first class and data is under its control”.
Declarative programming 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 global 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.
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, 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 the apps of the “app trap” are turned inside out: your once-imprisoned data are now freed - into an interactive 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 or “avatar” 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, that was motivated by the desire to free our data and regain sovereignty over it, can also carry through to networking in the OS, as the flip from a centralised (client-server, silo’d) to a Decentralised (federated, distributed, p2p) architecture.
This can start with the concept of “Local-first”, where your objects are stored locally rather than in the cloud. From that point, the next step is to push our stuff to servers we run or trust, then finally to share objects and their updates directly, peer-to-peer, between local datastores.
This will extend 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 (appears as Data-first currently in the comparison articles here) is the key motivating half of the full Declarative Inversion: freeing our data and standardising its object types, then linking it all back up with global IDs.
Declarative completes the Declarative Inversion, giving objects their “internal animation”: their dynamic and interactive behaviours and mutual dependencies.
Decentralised - starting with these free, local-first, sovereign objects, then sharing them and their updates via their links through trusted federated servers or peer-to-peer from device to device.
The end result is a seamless global graph of little, live data objects. Of course, any part of that graph can be made private to one or more other data owners. This graph will be manifest by “Inverted operating systems” that have no apps.
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 actually dis-aggregated (although best not to go down to the level of fine detail in spreadsheet cells!).
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, or if it’s “partially-Inverted” with event-action triggered scripts.
Then, does the technology use a Decentralised architecture, at least as far as the Web, with hosts owned by multiple parties.
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!