Obenauer's projects vs the Object Network
Techie article! Scoring the projects of Obenauer against my architectural vision
Here I’m going to compare Obenauer’s projects against The Inversion - my architectural vision behind the Object Network - so please do read that first. 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.
Obenauer’s projects: Itemized OS, plus Embark and Tana
Alexander Obenauer is a researcher into future operating systems. He explains and illustrates - with a clear, steady writing style - many of the motivations and concepts of the Object Network and OnexOS better than I do! I strongly recommend anyone investigating what I’m doing to also read everything he’s written on ”The Itemized OS“.
Obenauer has also been involved in Ink&Switch’s excellent Embark proof-of-concept (watch the video!), and his name appears on the Tana website - Tana looks like it has a very nice HX.
This comparison takes the Itemized OS ideas as the best idealisation of what various products like Tana are doing in the “PKM” space, including Airtable, Obsidian, Notion, Logseq, etc. So I won’t be comparing any of those in their own articles.
The Itemized OS is a conceptual project that has a strong focus in its description on the user experience, which is of “items” of many different types that can be mashed up in the UI. Items can be linked together with “references”, which seem to be like our links, except bidirectional. A system of creating custom views on related data appears to be a centrally-important part of the vision. There would be default views for each data type allowing interaction, including setting data and linking up by references, but you can then create custom views to suit yourself.
Embark has had some influence from Obenauer, and he was apparently keen to try out something not obviously “itemized”, plus not having the feature of custom views that was so core to the Itemized work. Instead, you sketch your data in an outliner tool and can include free text, locations, dates, numbers, etc (“Mentions” or “data”) as well as “computations” or “formulae” like spreadsheets. There’s a “view” on the right that can plot all locations on a map or all events on a calendar. It has those standard views plus the default UI of the outliner, unlike the emphasis on custom views of Itemized OS. It’s not obvious (to me anyway) how data chunks are ID’d or whether they can cross-link or refer across to each other.
It’s not clear to me where the normal interaction and behaviour of items in Itemized OS “lives”, as much of the interactivity is accomplished in the generic UI. So I don’t think one can say items are in general “internally animated” like in OnexOS, although I’m happy to be corrected on that. A test of this would be the ability to host calendar and event items on a headless server that look and interact identically to local ones, with logic running on the server for handling RSVPs etc. It includes “automations” over items as event-action scripts. It gets a green blob for Declarative because even though the event-action approach is scripted or Imperative once triggered, it still potentially offers the effect of internal animation of individual items, wrapped in an observer pattern.
Embark has more emphasis on the programming model than the Itemized OS - a spreadsheet-like system of inline formulae, which thus reinforces the green blob for Declarative (although it’s unlikely to be a general Turing Complete programming model with circularity). They say “unbundling the app” instead of “turning apps inside out”, but it’s the same idea because their unbundling frees the data and puts the functionality or behaviours of data “behind” each one of them.
It mentions pub-sub in one of Obenauer’s Lab Notes, so can be said to have network sharing in its model, in a somewhat similar way to the Object Network’s ONP, yet not obviously peer-to-peer. I’m giving them some “Decentralised” points for this and plus they mention future plans for using Automerge in Embark. Also, they say “Embark proposes an architectural change for the operating system”, along with “unbundling the app” thus ensuring the “OS” points that the Itemized OS is clearly laying claim to:
|Deconstructed
| |Declarative
| | |Decentralised
| | | |OS
| | | | |3D
|8 |8 |8 |4 |2 |
--+--+--+--+--+--+
IO|🟢|🟢|🟠|🟢|🔴| 24
--+--+--+--+--+--+Differences to the Object Network
To make these two projects more like OnexOS would mean picking items over Embark’s outline structure and its inline data format, but dropping Itemized OS’s custom views in place of Embark’s two-sided views. Custom views will still be possible, but implemented by our much less-used “layout”-typed items.
The basic UI would then comprise default interfaces per type, with the more structured data model of objects linked together. There would be object types for events (including weather events), notes, locations, routes, etc. There will be lists and sub-lists of any of those, which would regain some of the fluidity of the outline structure, plus you could also create your own freely-typed object.
Every object would be viewable in its raw form (like the current LHS) or a more type-aware form (like the current RHS) such as maps and calendars as currently, but also any individual object like a single event, person, location, paragraph, etc., and lists of those.
The challenge is to keep the stronger structure and power of the items or objects but restore the fluidity of Embark with good HX (Human Experience) in the OS interface. Dynamicland has shown that simply adding the third dimension can loosen things up quite a bit. That’s a primary topic of my own research, but not the main purpose of this article. So, subscribe to follow along!
You’d need to have standard internal animation or behaviours within items per item type, for basic CRUD and more complex inter-item interactions - if, as suggested above, they’re not already part of Obenauer’s conception. Items would allow the configuration of these default behaviours through item properties. Instead of event-action scripts, you would get custom behaviours via references from any data item to its governing rule items. These Declarative rule items would describe the dependencies, evolution and interaction between the governed item and other referenced items - including ones referenced and subscribed to over a peer-to-peer network. So similarly, instead of Embark’s inline formulae, there would be those rule objects which work much the same way. Again, of course, lacking the fluidity of the inline/outline structure, but much more flexible and powerful.
The pub-sub of items becomes ONP, and Embark’s proposed Automerge functions would be replaced by object behaviours as the Object Network doesn’t use CRDTs.
Hit the subscribe button to learn more, and feel free to leave a comment or question!