The Inversion (simply)
Saying it in 3 bullet points.
This is an article aimed at techies!
My previous article on The Inversion was setting the foundation for the follow-up articles that scored related projects relative to my own vision.
This article is much the same thing, but describing just The Inversion as simply as possible.
App-free computing
The Inversion could start with the idea of “app-free computing”: operating systems or environments without any apps or application programs (and equally, no back-end servers or services). I wrote my thoughts on that here:
In summary: apps take over and trap our data, splitting it all up into islands controlled by far away techies and Big Tech corporations. This is dis-empowering for all of us and leads to mass surveillance, censorship and manipulation. We don’t truly own our own devices, data or identities.
One of this project’s key drivers is allowing us to escape this “app trap”.
Data-First computing
However, I think we need to describe what we want, not what we don’t want!
And as soon as you dispose of apps, you immediately have no choice but to focus on the data instead. The data has now been freed from the app trap, and now we’ve got to decide what we want to do with it!
The Inversion forces us to focus directly on the presentation and management of our data, instead of making us all run application programs to access it.
The Object Network
For me, The Inversion has three logical steps following the initial step of the dissolution of apps and the freeing of all their data:
Faced with a data soup of freed data of all different shapes that have never seen each other before having been stuck inside their respective apps, we first have to normalise all the types. We start by making all paragraphs look the same, all people, profiles and contacts, all calendar events and task items. Next, we need collections and sequences of those, so we can build documents from sequences of paragraphs, calendars from sequences of events and to-do lists from tasks. Paragraphs, documents, etc. are called “data objects” (or just “objects” - but Inverted Simula/Kay objects, as there are no methods and the state is visible not encapsulated), and every object has an ID. Finally, notice that a collection or sequence is simply a list of the IDs of its contents, so generalise that to allow any object to link to any other simply by including its ID. I call this phase “Deconstructed”, as it also involves breaking down app-based aggregates such as entire documents and proprietary data blobs into their simpler types, then re-linking them back up again into a clean graph of data objects.
So now every app-free OS has its own local graph of data objects (it’s a Local-First OS!). All we need to do now is make IDs more like URLs or UUIDs and we can create a single global data object graph! This is what I’m calling the “Object Network”, or, for non-techies, the “Reality Network”. Others may call theirs “substrates”, “linked data webs”, etc. I call this phase “Decentralised”, as it’s clearly able to work peer-to-peer from day one. It will also include online server hosts, of course, adding their local object graphs to the mix. I call the result after the Deconstructed and Decentralised steps “HyperData”.
The main thing we threw away with apps, of course, is their functions or animations of our data, along with their user interfaces and APIs, including their back-end Web APIs. Now that we can only see data, data has to be our interface! Data objects are “internally-animated” now, and interact through mutual observation, driving their mutual state dependencies. This creates a live space for our interacting data objects. We “users” are just another live animated data object that’s able to interact in this space, like avatars. Now, our peer-to-peer network protocol must support inter-object observation and state updates. I call this phase “Declarative”, since that’s the programming style it supports best, and stands opposite to Imperative APIs and dominating application programs. This is now “Live HyperData”.
I believe that this must all happen as a new, metal-up, app-free operating system; it think it would be ironic for it to all be done as a traditional application program!
I also believe that it should work just as well in 3D or XR. Indeed, the Object Network can be seen as a “single, global scenegraph”! There’s an important sense of creating an interactive space.
The Inversion, simply
So that’s it, bin the apps and follow those steps and you’re fully Inverted!
Get it? Drop your thoughts into the comments below.
Objects are not the most general thing to have at the base here.
A traditional object’s methods are a collection of functions that switch on the first argument’s type (we write the first argument before the function name with a dot in between:
myobject.a_function
We have a collection of versions of a_function that are distinguished by the type of that first argument (i.e. the class they’re defined in).
A more general version is functions that switch on multiple arguments — generally called Multimethods.
More general still, though, is just FP. Multimethods were invented in Common Lisp, and were just implemented in the language.
So, really, we want types on the data. For compound types, this is basically a relation (all the values of that type). And functions that can be applied to those types.
In my Frest project, you can attach triggers to tables, and this is much like having methods on classes.