OnexOS: a 3D virtual world operating system!

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 playing it.

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 camera app.

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, in-line.

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"...

Links

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:

C:\Photos\img-143143.jpg
/Users/frank/Photos/img-143143.jpg

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

smb://franks-server/Photos/img-143143.jpg

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:

http://franks-server.com/Photos/img-143143.jpg

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:

C:\Photos\
/Users/frank/Photos/
smb://franks-server/Photos/
http://franks-server.com/Photos/

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:

C:\Photos\img-143143.jpg
C:\Photos\img-629319.jpg

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 others:

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-photo-629319)

unique-id-gallery-holidays-6210  = (unique-id-gallery-birthdays-3323
                                    unique-id-photo-143143
                                    unique-id-photo-002188)

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.

Structure Links

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.

Personal web

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 Obsidian, Roam, Logseq, Notion, Tana, 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 ics and 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.

Sharing Links

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 multi-user!

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.

Peer-to-peer web

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?

Sovereignty

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.

Internal animation

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 world.

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 animation.

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:

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 weather server.

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.

Conclusion

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", where OnexOS 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.