OnexOS: an operating system without apps!

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, dropping the apps in our radical operating system 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 without apps, what would be left; how would you do anything? You'd still have all those widgets for clocks, WiFi and battery status and so-on. You'd presumably still have access to all the other system and machine settings and status.

But, more importantly, you've still got a filesystem full of files. Just no apps to animate or activate them.

On a PC you'd have a desktop covered in files. On mobile you'd just have an empty wallpaper where the apps should be, but that could easily be replaced by a file manager, too, showing all your files instead. You could argue that a file manager or desktop is itself an app, but files are fundamental to any operating system, and they always ship with a file manager that's closely integrated.

So, what then? Well, you can actually do quite a lot around just the files-and-filesystem model.

Firstly, there are 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.

Do you really need a separate gallery app, if the file manager could be used instead? You would probably use the file manager's time-ordering to view the photos in the order they were taken.

Secondly, you can move, rename and delete files, and create folders to organise them. Every app seems to have its own move, rename, delete, group and organise functions. Without apps, you could have just one integrated, universal and frictionless way of doing these functions for all file types.

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.

Instead of having separate notes and document creation and editing apps with their own ways of doing things, we could benefit from having a single uniform way of typing and editing text. 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 via the file manager without 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 photos folder or "gallery" having a big plus "+" button at the top to allow a new photo to be added right there.

So, you go to your notes folder and see the time-ordered collection and quick preview of each. You want to create a new note, so you hit this folder's big plus "+" button and get typing. Now it needs the picture that you just took, that's over in the gallery folder. As you expect, you simply also use the file manager to select the photo to drop in.

But what happened there? What does "drop in" mean? Does the note file now balloon in size because it has a complete copy of the photo? In most apps 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 have a link in the note file to the photo file. 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

But hold on: this is quite a limited approach! We can do better in our operating system. 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.

But what if we see a folder as itself simply a collection of links, to either more folders or to files? Consider a folder with this link:

Containing two photos with these links:

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

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

So now their folder is just a collection of those IDs:

C:\Photos\ = (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:

C:\Photos-Barbados\ = (unique-id-photo-143143 unique-id-photo-002188)

We can go further, and assign a unique ID to folders as well as files:

C:\Photos\          => unique-id-c-photos-3323
C:\Photos-Barbados\ => unique-id-c-photos-barbados-6210

unique-id-c-photos-3323          = (unique-id-photo-143143 unique-id-photo-629319)
unique-id-c-photos-barbados-6210 = (unique-id-photo-143143 unique-id-photo-002188)

Now instead of tree-like filesystem structures, we could create arbitrary webs with circular loops, where folders can end up linking around to themselves:

unique-id-c-photos-3323          = (unique-id-photo-143143
                                    unique-id-c-photos-barbados-6210
                                    unique-id-photo-629319)

unique-id-c-photos-barbados-6210 = (unique-id-c-photos-3323
                                    unique-id-photo-143143
                                    unique-id-photo-002188)

Which is much more powerful and freeing. Our gallery above 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.

In fact, the link is a fundamental, pervasive and powerful concept that emerges from the elimination of apps. 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'd have a single paragraph text file in some folder, and notes and documents that link to it. Now, if you change the paragraph, it updates everywhere it's used!

In the old days of apps, where some apps so jealously guarded their data that their files were in a closed, proprietary format, you wouldn't be able to even think of doing this. But now we've thrown the apps out, we can start to dig in to their files and think about how their structure can be re-structured to suit us.

Notes are also like galleries

So, thinking a bit further here, we have two ways of doing the same thing: we have folders that are just sequences or collections of links, and we have notes or documents which are also sequences of links to paragraph and photo files. Perhaps folders and notes or documents can be made the same - in the same way that we re-purposed folders for our photo gallery. Couldn't we simply use folders for documents too, and drop the idea that a document is a "file"?

A note or document is then just a folder containing a sequence of links to paragraph and photo files. Our operating system or file manager has to spot that a folder is set up like that, and present it to us as a document or note instead of just a simple folder, in the same way it gave special treatment to gallery folders.

Of course you can now drop another note folder link into a note, alongside the paragraphs and photos, to nest them and have notes linking to and from each other. The operating system can show a nested note in a way that it can be either expanded in-place, or jumped into.

In fact, since we're freeing our minds here - why not just drop into your note the link to a whole photo gallery? Again, the operating system rendering your note to the screen would show it in reduced form in-place, and allow you to scroll it or jump into it.

Personal web

So, without any apps, and indeed because we dumped apps, we have now built a personal web of notes and documents made up of shared images and videos, all pointing to and from each other in collections and sequences.

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.

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.

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? When you check the to-do off in the to-do list, it's also shown "done" in the calendar event.

Of course, a folder full of calendar events is rendered as a calendar, without needing a separate calendar app. A folder of contacts is your "contacts app"! A folder of to-dos could render with a count of jobs still left to do.

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, 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 thrown out apps and their control over local data. But what about apps that work online, and their control over our remote, online data? What happens to us when using an operating system without those apps when we follow the links, files and collections model through?

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. Now, without any special app, 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. 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.

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.

Chat without apps

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 without separate apps?

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 file is now basically grabbing a copy of the camera "file" at a point in time. Making a video file 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 that doesn't need any apps to allow us to directly create, view, edit and delete files of various types like text, media, to-dos, events, etc; organise them in collections including galleries, documents and calendars and manage them by their links and share everything across machines, across the network.

So in fact, we already have the pieces in place to implement chat: a chat room or group is a folder, containing text and media messages as files, in the same way that we made our gallery and document examples. We just need to view the folder 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. Why do everything multiple times over, for each app, when the concepts are basically the same? In the same way as galleries and documents, this would clearly require a slick user interface aware of the chat or email folder type, 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, folders, documents, to-do lists and calendars, we have a big plus "+" button to add a new photo, file, paragraph, to-do or event. So it would work the same here, except, who owns the folder representing 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 a folder representing 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 folder 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 folder. The operating system takes care of this for us by shipping her message directly to your device and to the chat folder, which has some internal logic that fires off, allowing the folder to add the link to the incoming message. 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.

Objects

It's time we started to use a more appropriate terminology than "file", "data chunk" and "folder". We've come so far from an actual filesystem at this point, especially now that we've got documents actually being "folders", folders being collections of unique IDs and file paths replaced by those IDs, that it's stretching these terms too far.

From now on, we'll refer to both files, or data chunks, and folders as "objects". 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".

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 files of 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 folder 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 using a chat app? How do we implement that? We've also described the camera "file" or 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 app-free operating system, like a calculator app.

Internal animation

All our objects in this app-free world 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 without apps, 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 first and it's the behaviour that is hidden. Our data, our objects, are internally animated.

Further, without apps to manage the dynamics of our digital lives, we 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 app-free operating system, that isn't good enough. If some object changes, those changes have to be pushed out straight away to everyone that's watching.

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! Yes, 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, would simply be an avatar-like thing.

So, of course, this is starting to look a lot like a 3D virtual world. Just like 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-like person object representing you can itself watch other objects, as they animate. The person 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 operating-system-without-apps would be used.

Firstly, we've hinted above that we're pretty much creating a virtual world with this approach, and so there's no reason not to experiment with 3D as the default user interface to our radical operating system. This expands the "thinking space" concept into quite a novel direction. You could at least imagine 2D panels in a 3D world rendering many of the above object types as a starting point. Then implementing a game without isolated game apps becomes interesting: do you have a space over here reserved for that game? Can items from one game be taken into another?

The Network of Objects is a good match to the "Internet of Things", where each Thing is of course an object. Imagine a light output object with a link to a switch input object, and an internal behaviour that turns it on or off depending on the state of the switch.

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, 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 folder or collection object of objects with GPS coordinates. Just like all other special folder 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 folder or 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 over everything: 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 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 user interface builder, by analogy to HTML forms. Again, that's a topic for another article.

Conclusion

Starting with the radical premise of "an operating system without apps", 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 data fabric - owned by everyone, and by no-one. Such an operating system can restore true ownership of our devices and our precious data right back to us.

These concepts are being explored in the OnexOS operating system. OnexOS is a proof-of-concept of this revolutionary way of rebuilding the tech stack from the ground or from the "metal" up. OnexOS runs 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. The initial primary target is the Raspberry Pi 4 and CM4, as these are very popular, well supported and flexible devices that can behave like, well, tablets, PCs, TV boxes, gaming machines and internet servers...