OnexOS is a proof-of-concept of an operating system that works like a 3D virtual world!
That's quite a dramatic change, so why do that?
As we will demonstrate here, there are correspondingly dramatic benefits to building
this. It can deliver freedom from the "traps" of apps, online services and Big Tech, and
deliver unprecedented empowerment over the devices and data that we're actually supposed
to own ourselves.
In fact, building our radical operating system as a 3D virtual world leads us down a path
where we discover the power of the link, which is central to
re-structuring, re-decentralising and re-activating our shared data...
No apps, just files
Let's go through with a thought experiment. Imagine a PC or mobile running such a 3D
virtual world operating system: how would you get stuff done. Or, to start with, how
would it even look? Starting at the edges, you'll want to keep all those widgets for
clocks, WiFi and battery status and so-on, so they'd be in the same places roughly and
not part of any virtual world. You'd presumably still have access to all the other
system and machine settings and status that way.
So the bulk of the screen is this 3D view. Unlike in a traditional operating system, we
don't have the concept of an "application" or "app", here. We're seeing what happens in
this thought experiment, so don't want to go backwards! However, you do still have a
filesystem full of files, just no apps to animate or activate them.
On a PC you'd have a desktop covered in files, so how about we start there: throw all of
our stuff into the virtual world, so we can see it. On mobile, you could replace the app
home screen with this, too. Files are fundamental to any operating system, and they
always ship with a file manager that's closely integrated. Now, in our radical experiment,
ours is the virtual world itself!
So, what then? Well, you can actually do quite a lot around just the
files-and-filesystem model with a 3D render, starting with the preview options. You've
seen how photos can be shown in a file manager as small versions of themselves, and you
may have seen that feature where if you hover over a video file, it shows a small window
Well, now we can grab our "folder" of photos and pin them to a 3D gallery's wall! You
could imagine a little control panel on the wall to re-sort them in time order or by
some manual arrangement.
You could create an entire house of rooms of different files, to organise them, where
each room would once have been a folder. Imagine having a virtual kitchen with a
calendar and a to-do or shopping list pinned up. You may feel quite free, no longer
having separate gallery, calendar and to-do apps.
You would still be able to move, rename, group, organise and delete files. This gives
you just one integrated, universal and frictionless way of doing these functions for all
file types, as we have no apps to offer us any alternatives.
You just need a way to create and edit these files in the first place!
Let's dig deeper and see how far we can take this, and see what the advantages of this
approach may be...
Creating and editing text and media
A common data or file type we want to create and then edit is text, along with images or
videos. This is what we do in notes and documents apps, as well as when we use the
Without separate notes and document creation and editing apps, with their own ways of
doing things, we will have to be offered a single uniform way of typing and editing text
in this world. This would be similar to the file preview function: if you see a note or
document file, you can simply go in and edit it directly. No waiting for the file's
associated app to fire up!
If you're on a mobile device and want to take a picture, you can imagine your Gallery of
Photos in the world having a big plus "+" button on the wall to allow a new photo to be
added right there.
So, you go to your Thinking Room, which has notes on the walls. You want to create a new
note, so you hit the big plus "+" button on the wall and get typing. Now you need the
picture that you just took, that's over in the Gallery room. As you expect, you simply
go over into the Gallery, select the photo and walk back and pin it up in the Thinking
Room. Now you can drop it into your note so it shows up as a much smaller version,
But what happened there? Did the photo get copied when you pinned it up? What does "drop
in" mean? Does the note file now balloon in size because it has a complete copy of the
photo? In most operating systems that's exactly what happens, because each app thinks it
should control everything about the data or files it is responsible for.
But we don't have apps any more, so don't need to waste this amount of disk space with
redundant copying. We could simply use "links" as our pins to the photo file and in the
note. To see how this would work, we first need to explore the concept of the "link"...
Normally, when we say "link" we mean a web URL, pointing at a page on an online server.
But it can also point to a local file; in Windows you may say "shortcut". And it can
also point to a file on a local file share server.
You should be familiar with the concept of a file's path: it has both a file name and a
containing folder, so you may have a photo who's file path is something like these:
You may also be familiar with file shares, at work or at home: remote files
that look and behave just the same as local ones, on servers or even on another person's
PC. Now our links can point to files and folders on other devices, as network share
paths - links across machines like
You may also have noticed that the Web's URLs often work the same way as file paths, so
you could fetch a photo on the URL:
In all cases these "links" are just a short piece of text pointing to a file. This can be
used to refer to it and fetch it when needed.
Now, in fact, if you take off the file name, you're left with the containing folder name:
These are also a valid "links" - but now they are links to a folder, a sequence or
collection of files.
Using ids for links
Now, in our operating system, we can do better than this. Doing things this way means we
are forced into a "tree" structure where you only have a hierarchy of
folder-folders-folders-files, branching deeper, meaning we'd have a 3D representation
of a rabbit hole! In our free virtual world, we've got more space to play around.
What if we see every object in the world as linkable to any other? The gallery wall is
an array of links to the photos pinned to it. Indeed, why not have the gallery walls,
floor and ceiling pinned together by links as well? The house is a collection of links
to rooms, and so on, all the way up to entire cities!
Consider how you'd do things in a traditional operating system. You may have a folder
with this link:
Containing two photos with these links:
What we now want instead is a Gallery wall object in our virtual world, linking to the
two photos. Why don't we break these photos free of their single containing folder, by
giving them unique IDs instead:
C:\Photos\img-143143.jpg => unique-id-photo-143143
C:\Photos\img-629319.jpg => unique-id-photo-629319
And we can do the same to their folder:
C:\Photos\ => unique-id-gallery-birthdays-3323
Which is now just a collection of those IDs:
unique-id-gallery-birthdays-3323 = (unique-id-photo-143143 unique-id-photo-629319)
This allows us to have another folder that also links to some of the same photos, or
unique-id-gallery-birthdays-3323 = (unique-id-photo-143143 unique-id-photo-629319)
unique-id-gallery-holidays-6210 = (unique-id-photo-143143 unique-id-photo-002188)
Now instead of tree-like rabbit-hole filesystem structures, we could create arbitrary
webs with circular loops, where rooms can end up linking around to themselves:
unique-id-gallery-birthdays-3323 = (unique-id-photo-143143
unique-id-gallery-holidays-6210 = (unique-id-gallery-birthdays-3323
Which is much more powerful and freeing. Our photos folder that was a rigid collection
of photo files can now share photos with other galleries and we can have galleries that
link to and from each other arbitrarily.
Files and folders are both called "objects" in our virtual world operating system. A
folder is just an object with its own ID that's a list of IDs to other objects. All
objects link together into a single global web called "The Object Network".
In fact, the link is a fundamental, pervasive and powerful concept that emerges from
this way of thinking, without apps but just an unlimited space to work in. There are
three pillars building the power into our links: Structure, Sharing and Semantic,
allowing us to respectively re-structure, re-decentralise and re-activate our shared data.
So, back to the situation where we were editing a new note and needed to drop in the photo
we just took: we simply drop one of these links to that photo into our note. It grows in
size a little, but there's no redundant copy of the entire image. Another benefit is
that this can be done many times, in many notes and documents, at near zero cost.
Now, let's take this further: if we look inside the note, how is it structured? It's
basically a sequence of text paragraphs, then the link to the photo, then more paragraphs.
So, why shouldn't those paragraphs also be linked to, in the same way as the photo? That
way, you could share both photos and paragraphs between two notes or documents by
simply dropping their links in. You could even pin single paragraphs of a document to the
walls. You'd have a single paragraph linked to by multiple documents and rooms. Now, if
you change the paragraph, it updates everywhere it's used!
So we have rooms with objects pinned to the walls, that are just arrays or collections
of links to things like paragraphs and photos, and we have whole documents which are
also sequences of links to paragraphs and photos. A document is just an object in the
world that our operating system has to present to us as a 3D document, with the
paragraphs and photos paginated as expected.
Of course you can now drop another document link into a document, alongside the paragraphs
and photos, to nest them and have documents linking to and from each other. The operating
system can show a nested document in a way that it can be either expanded in-place, or
pulled out alongside its host.
In fact, since we're freeing our minds here - why not just drop into your document the
link to your whole photo gallery room? Again, the operating system rendering your
document to the screen would show that room in some reduced form in-place, and then
allow you to teleport right into it from the document.
In the "old days" of apps, where some apps so jealously guarded their data that their
files were in closed and proprietary formats, you wouldn't be able to even think of doing
this. But now we don't have any apps, just a space to play in, we can start to dig in to
their files and think about how their structure can be re-structured to suit us.
So in our 3D virtual world, we have now essentially built a "personal web" of notes made
up of shared paragraphs and images, all pointing to and from each other in collections
and sequences, on the walls and in documents.
We've actually arrived at a model for data that's becoming popular in apps such as
etc. These allow you to wire notes and media into personal planning, thinking and
mind-mapping spaces. But we're making a whole operating system like that, not just a
single app, and we're going for a 3D space, not a 2D one.
So we have a personal web - why not just use the existing Web? The primary difference at
this point (there's more to come!) is that the stuff at the ends of our links isn't
complete web pages or documents, because we've deconstructed documents down to their
basic elements: paragraphs and media. Unlike the Web, we can embed not just images in
our pages, shared with other pages, but individual paragraphs or other text chunks, too.
We can even embed 3D places inside them seamlessly (which the Web can do with "iframes",
but no-one uses them as they're quite clunky).
But there's more. Once we start digging deeper into the files that used to be created
and used by apps and breaking them up into smaller chunks we can find all sorts of
nuggets we can use in our personal webs of data, simply by pointing at them with links,
and taking us even further away from the big-document Web into a web of data chunks.
Diversity of types
For example, a list of notes from a notes app could also be a list of to-dos, if there
were a dash before each item, or could be encoded into a special to-do format from that
same app. There are calendar events or addresses and phone numbers either casually
written into a note, or encoded into
vcf files. Every
photo has "metadata" giving information about the location the photo was taken and about
the camera that took it.
If each of these types of data were extracted into little chunks that we can link to,
then we can re-structure everything to suit ourselves. Why not have a calendar event
pointing at a single relevant to-do? Why not also stick that important to-do up on the
wall of your virtual office or kitchen? When you check the to-do off in the to-do list,
it's also shown "done" in the calendar event and on the wall.
Of course, a list of links to calendar events is rendered as a calendar we can pin to our
wall, without needing a separate calendar app. A box of contact cards is your "contacts
app"! The to-do or shopping list could render with a count of jobs still left to do or
items to fetch.
Without apps, we are free to play with this data in new ways, to combine it all in ways
that no app would previously allow, by simply dropping links between them and collections
of them. We can create a collection of and between one to-do, three notes, five photos
and two calendar events, then pin it to two walls, and no app developer can stop us!
Data is no longer jealously guarded by individual apps and in inscrutable formats. All
our data is out in the open, in open standard formats that all devices running this
operating system can understand on sight. We've broken free of the "app trap" and can
use the power of links to organise our digital lives freely the way we like in our own
personal web of data.
So, we've brought our local PC or mobile data into our 3D virtual world. But what about
our remote, online data?
You'll recall that we mentioned fileshare and URL links above, because files needn't
just be on our local machine - links can point directly at files and folders on other
devices on the network. A file or photo can be local or remote, it looks the same. So
it can look the same in our virtual world. We can open up our virtual world and make it
Now, we get file sharing, including direct, peer-to-peer file sharing. We can directly
share notes, events, media, etc, between our PCs and mobiles and those of our friends,
as long as the links allow us, simply by walking over into someone else's gallery and
grabbing the link to anything we like, then walking home and pinning them up! We can share
notes, documents, todos, events, calendars, galleries, rooms, houses, streets, etc., all
with the simple link. Thus we can extend our personal web to link up with the personal
webs of our friends and family and co-workers.
Obviously, this needs a permissions system. Which, in turn, leads to the need for
encryption - end-to-end-encryption, in fact.
One permission we can give to our content is "everyone can read it". This amounts
to publishing. We can allow anyone access to the document at the end of a link,
from which they will be able to see and use the links inside it, to paragraphs, etc.
If we create a collection of such links to our documents or articles, we've created
a "feed" like a blog or news feed. Whenever we add a new article to the end
(beginning?), everyone will be able to read it.
Again, we are sailing close to the existing Web here. But there's another crucial
difference with this approach: we're not using any central servers, just using links
that point directly between our personal machines, peer-to-peer.
At this point, our operating system is actually our "browser", so that's another app we
no longer need. Our links are the unique IDs described above. We never actually need to
see what these IDs look like, in a way similar to the way current browsers are hiding
URLs. Others have thought about the merge of operating system, file manager and browser,
so this is not a radical concept.
Virtual world chat
What about WhatsApp, Facebook and Twitter? (presumably if you're reading this you're not
young enough for that list to include Snapchat and TikTok ... oh, how this page will
age!!). We don't just use text and media for our personal organising, but also for text
messaging, email, WhatsApp, and so on. These apps exchange text and media with other
people. WhatsApp also lets you make live video calls using the camera, and we've got a
phone app, too, also using the microphone and camera. How can we implement all of this
messaging and video calling functionality in a 3D virtual world?
As for live video calling: what if our cameras had links, too? If you viewed any camera
via its link, your own or someone else's, you'd see what it sees. Taking a photo is now
basically grabbing a copy of the camera's state at a point in time. Making a video is
saving a series of copies between a start and end point in time.
For messaging or chat, let's review what we do have: an operating system where we can
create, view, edit and delete objects of various types like text, media, to-dos, events,
etc; organise them in space including rooms like galleries, or in documents and
calendars, manage them by their links and share everything across machines, across the
network, in a multiuser virtual world.
So in fact, we already have the pieces in place to implement chat: a chat room or group
is an actual virtual room, or a wall there, containing links to text and media messages,
in the same way that we made our gallery room and document. We just need to view the
messages in time order, with latest at the bottom.
Both email and chat apps can work this way: a chat app has a sequence of messages in
time order; an email app has a sequence of emails in the opposite time order. In the
same way as galleries and documents, this would clearly require a slick user interface
aware of the chat or email message types, to allow the viewing and new message creation
to be as smooth as WhatsApp and email clients.
Of course, there's something else to add: how do we post a new message?
For galleries, documents, to-do lists and calendars, we have a big plus "+" button to
add a new photo, paragraph, to-do or event. So it would work the same here, except, who
owns the chat group or room?
The solution delivers one of the key freedoms and empowerments of this app- and
service-free approach using links: sovereignty over our own data.
The way it works is that you create the new chat room, then share its link with some
friends, setting appropriate read permissions. You can obviously post a welcome message
there, too. Both of these, the room and the welcome message, are hosted on your own PC
or mobile, and the links to them that you shared allow your friends to fetch them both
directly over the network from you, peer-to-peer.
Now, one of your friends wants to reply, so hits the plus "+" button. She types in her
message. This message is hosted locally to, and will always be owned by, her. We
now just need to get a link to her message into the chat room. The operating system
takes care of this for us by shipping her message directly to your device and to the
chat room, which has some internal logic that fires off, allowing the room, or its
wall, to add the link to the incoming message to the end of the list. We'll talk more
about this internal logic in the next section.
Data is no longer jealously guarded within separate service apps - the "walled gardens"
of Big Tech, in their remote and private databases. All our data is safe on our own
devices running this operating system sharing directly. We've broken free of the
"service trap" and can use the power of links across our devices to co-create webs of
data without fear of censorship or surveillance.
Semantic ("Spreadsheet") Links
We've come a very long way with just the most simple of building materials: the link
and the collection of links, to our data or objects. But it's still not quite enough.
The final use of links is the one that gives objects more complex behaviours than these,
but still without them being encoded into inscrutable apps.
Earlier, we alluded to the behaviour of a to-do list, keeping a count of jobs still
un-done. We also just described a simple behaviour of a chat room object reacting
to an incoming message object from someone permitted to read and post there, adding a
link to that message at the end of its sequence of links to previous messages.
Where does all this behaviour get built and run, without apps? Also, what about the
"presence" of a person in this virtual world - their avatar? We've also described the
camera object, that is always letting us see what it's pointing at, which seems a little
more "behaviourie" than a simple, usually static, file.
Also we've so far not got around to talking about how we'd implement other more complex
functionality in our operating system, like a calculator app.
Being a virtual world, all our objects are going to have to be "internally animated". An
app normally wraps and traps our data, so any behaviour can only come from the app, and
any data we could have access to is inert until animated by its owning app.
But in a virtual world, we need to turn everything inside-out: instead of seeing the app
first and the data being largely hidden by it, we see our data - our stuff - first and
it's the behaviour that is hidden. Our data, our objects, are internally animated.
Further, as you'd expect in a virtual world (and without apps to manage the dynamics of
our digital lives), we are going to have to see stuff as soon as it changes! This is the
third and final difference to the Web. On the Web, and indeed when fetching files from a
file server over the local network or internet, you have to hit the refresh button to
see if there have been any updates. In this operating system, that isn't how things
work. If some object changes, those changes will be pushed out straight away to everyone
that's watching. This is especially handy for our article feeds described above.
Input and output objects
But who or what is watching? In a world of objects and no apps, everything ends
up being an object, including the operating system's connections to and from the real
In a similar way that the camera we described before is an object that is "live" and can
be viewed as it changes, there's another object we've not yet introduced you to: YOU!
Of course, your "presence" actually has to be another object itself. So, if I have the
link to your "you" object, I can watch you just like I could watch your camera. A person
object, if you had permission to watch it, is simply an avatar.
In a virtual world, the person/avatar is able to go around changing stuff. So as you
type a new message in the chat group, that new message and all its edits - all its
internal animation - is being driven by you.
But the camera isn't something you're driving. In this operating system there's also
going to be a clock object, which just ticks away, setting the current time without you
going in to edit it.
Things like this are representing inputs. In the same way that the user, person or avatar
object represents the actions coming in to the virtual world from the user, a camera or
clock inputs the camera's real-world view and the real-world current time, respectively,
into the virtual world.
There are also outputs. The avatar-person object representing you can itself watch other
objects, as they animate. This object is viewing or present somewhere and sees the
changes of the part of the world it's watching. That's an output, from the virtual world
to the real world. Similarly, there is a vibration motor and an indicator light on your
mobile device that are outputs - there would be a corresponding motor and light object
in the operating system's virtual world driving them.
Like a spreadsheet
So, back to those other internal behaviours outlined above, like the to-do list counter
or the chat group new message function. A calculator exists to save you doing the work,
so its behaviour has to be programmed! When the clock's alarm goes off, or when a
calendar event is due, that object has to trigger some kind of notification. These aren't
driven by input or output, they have to have internal logic to drive their internal
We could just go back to the app-like way of doing things and let some techie write
these behaviours, and that's a genuine option that will be used for common behaviours.
But this operating system is all about empowering the person using it, not the far-away
techie! And the most common way non-techies do programming is the spreadsheet.
You may be familiar with how a spreadsheet has cells whose value can be programmed
with simple formulae to depend on the values of neighbouring cells. In this operating
system, we can do something very similar: we can say that an object's whole state depends
on the state of neighbouring objects. By "neighbouring", we mean "linked to", of course,
since that's how we do things here. So an object links to another object that it depends
on. When that object changes, this one does, too, according to some formula.
To go over all the examples:
The to-do list object links to each to-do it contains. But it can also depend on them so
that it counts up those to-dos still not in a done state, and sets its counter accordingly.
The chat group list also depends on the state of any messages that claim to or want to
be in the chat history, so will add the incoming message link as soon as it becomes
aware of that message's state, pushed to it by the peer operating system.
If you are viewing a calculator object, the operating system can let you create or input
an "expression" object that you want calculated. The operating system then notifies that
calculator of this object. Now the calculator object's state depends on that expression,
triggering its internal logic to in turn set its "result" to the answer, rendered back to
the user. If the user edits the expression, then, as in a spreadsheet, the calculator
object instantly updates its result.
Finally, an alarm object and a calendar event object are basically the same thing,
except the alarm needs a more persistent notification perhaps. These objects clearly
depend on the clock object so have a link to it, and watch it ticking away. Then when
their time is due, set their state to, well, "due", perhaps. Because the user, through
their avatar object, has been viewing them before, their object sees the "due" state
and alerts the actual, physical user on the other side of the input-output interface
that the time is up.
Of course, one great thing about our approach is the way that, unlike in spreadsheets
where everything is local to the current worksheet, we can set up dependencies across
machines anywhere on the Object Network, between distant and disparate parts of our
shared personal object webs.
The details of the programming language are for a more in-depth article than this one,
as a whole new revolutionary programming language for our whole new revolutionary
operating system is quite an undertaking!
Data is no longer jealously wrapped and animated like a puppet by apps written in
obscure programming languages. Like in a spreadsheet, it's out in the open and it's the
internally-animating formulae that are hiding in the back. We've broken free of the
"techie trap" and can use the power of links to set up inter-dependencies between data
in our web of objects.
Some loose ends
So, nearly at the end of this article, and there are some loose ends we should tie up in
thinking about how this 3D operating system would be used.
This 3D virtual world operating system expands the "thinking space" concept into quite an
interesting direction. You would have 2D panels in this 3D world rendering many of the
above object types as a starting point. You could have a thinking room with cards of
notes scattered on the floor and stuff pinned to the walls. We could have shared spaces
to meet or collaborate in. We can create unlimited worlds within worlds together, all
linked up. It's essentially the "Metaverse".
Now, implementing a game in the world without isolated game apps or online services
becomes interesting because there is no separation any more as it's just one operating
system: do you have a space over here reserved for that game? Can items from one game be
taken into another? It's more like real life: you may need specific places like sports
clubs and stadiums to play in!
The Network of Objects is a good match to the "Internet of Things", where each Thing is
of course an object. But we can use Augmented Reality style techniques to create a 3D
rendition of the physical room your devices are in. So pan around your physical room
using a tablet and see the lights and sensors in place. Imagine connecting up a light
output object with a link to a switch input object, and writing an internal behaviour
that turns it on or off depending on the state of the switch. This properly restores
ownership of your most intimate of devices to you, instead of each requiring its own
account, via which remote companies suck up your data and maybe allow surveillance.
Now the switch signal goes directly, encrypted, to the light over the mesh, instead of
via a server in California!
What about media apps like Spotify, Netflix and YouTube? Like all apps, we don't have an
alternative for their offering unless they feel like joining us in the virtual world one
day. But if we want to produce and publish our own music and videos, then of course we
get to ship them out, peer-to-peer, without the pervasive censorship and narrative
alignment enforced by these Big Tech offerings. It's a subject for another article to
discuss people-centric alternatives to "Intellectual Property", but clearly peer-to-peer
networks are generally able to be light on compliance there.
What about maps and navigation? Say you have a collection object of objects with GPS
coordinates. Just like all other special collection types, the operating system
would render that in a special way: in this case as a map with pins on it for each
object in the collection. The map tile layer objects would have to be fetched from
somewhere, of course, for the area being shown. Now, if you had a "route" object with
start and end coordinates, this could be rendered as two pins on the map, then the
internal logic of the route object kicks in with the route details, and the operating
system renders the lines of that route.
In the old app-based approach, you'd have a separate map for every app that wanted one.
Now, we can throw a map together from objects from any source. We could have a collection
of objects including some photos, the current location of the family, and a pub you
were all meeting at. We could watch everyone converge in real time on the pub.
Similarly, we've freed calendars from apps: instead of a calendar locked away in each
app that needs it, we can throw objects with start and optionally end times into a
collection object and view that. The operating system will show this object as a
calendar. So we can make new calendars any way we like for any purpose.
One thing we may throw into a random calendar is the weather: weather forecast objects
could be imported into the Object Network as input objects from an existing internet
Talking of importing, where-ever there's an internet protocol (or "API") available,
that data can be imported into or exported out of our Object Network. So, the web,
email, news feeds, chat systems, and so-on. Even without apps, we can still get the
week's weather and catch up on the news, while communicating with everyone in the
Land of Apps.
One of the top things folk do in the Land of Apps is search. The Object Network can
easily support people building indexes of "crawled" content just like a search
engine does, only now the things being crawled, scanned, indexed and returned to
search queries are objects, not web pages. Of course, since everything is a live object,
your search queries and search results lists are also objects, so you can save them or
watch their results change.
One objection that could be easily be made to this operating system is that it takes
away the owner's choice to install alternative apps that work better for them. You can't
just install another map, calendar, gallery, todo or notes app that you prefer, or
another camera, clock, calculator or phone, you seemingly just get the 3D render and
interaction provided by the operating system.
There are two answers to that. Firstly, few people in reality actually replace the
supplied calendar, map, gallery, camera or phone apps, most use the default stock app
for 90% of their needs. Secondly, the operating system just provides a vanilla
interaction for known object types. But you can extend everything, because one of the
vanilla types is a general purpose object view or render builder. Again, that's a topic
for another article.
Starting with the radical premise of "a 3D virtual world operating system", we've gone
on a journey where we've discovered the power of the humble link to free us from the
three traps of Big Tech: the app trap, the service trap and the techie trap. We've seen
how the pervasive link can empower us to re-structure, re-decentralise and re-animate
our shared data and enable us to create a global virtual world populated by linked
objects in a "data fabric" - owned by everyone, and by no-one. This reimagining of our
internet experience created by this radical "OnexOS" operating system is called The
Object Network. Such an operating system and sovereign space can restore true ownership
of our devices and our precious data right back to us.
These operating system concepts are being tested out in the "Object
Network Exploration Lab"
is being built as a
proof-of-concept of this revolutionary way of rebuilding the tech stack from the ground
or from the "metal" up. It is designed to run on every kind of computer from tiny
wearables and home automation devices up to internet servers, via our mobiles, tablets,
PCs, TVs and games consoles.
To read on, go
for an expanded view of this approach with examples,
to read about the smartwatch version.
There's also a list
of many more, broader and deeper, articles and presentations about the Object Network.
OnexOS is still under
development. If you want to get involved as an early adopter and tester, get in touch!
Duncan Cragg, 2023. Contact me