If you’re an old git like me you’ll remember heading to the newsagent, slapping down some coins, and running home to code a game by hand from the pages of a computer magazine into a Sinclair Spectrum or Amstrad CPC-464 in BASIC or machine code if you were (un)lucky.
(if you’re even older then you’ll remember Assembly and punchcards and god loves you for it)
Invariably it would never work the first time but for many of us, that was the introduction to software engineering or games development we had. It felt like the golden age of computing, the discovery of turning the words of another language into something magical.
Now, frankly, the majority of us are fucking lazy.
We want no-code or low-code platforms to do it for us all, we don’t want to learn the hard stuff anymore, to extract every bit of juice from a processor or memory and get our hands dirty at the lowest levels possible.
And I think to myself ‘maybe that’s why we need an operating system for the metaverse’.
The problem and itch that fails to get scratched are that most metaverse discussions are based on building on existing infrastructure and software principles. We’re creating multiple versions of software stacks based on centralized architectures — everything still sits on Windows for crying out loud.
When you look at the landscape and proposed components of the metaverse and web3 you get stuff like this below — I mean, they even call it an OS but it's just a reworked representation of a tired Matthew Ball blog post using some curvy squares.
Outlier Ventures propose and champion an Open Metaverse OS, a completely decentralized set of tools and technologies rather than proprietary platforms that are designed only to operate through standards and APIs.
We have created a framework to assess and interrogate Metaverses, as well as a toolkit to design alternatives based on principles of user centricity and sovereignty of identity, data and wealth.
That’s nice chaps but it’s not an operating system so quite why you used the term ‘OS’ is beyond me.
The Outlier Ventures Frankenstack
To grow the Metaverse, we will need many new tools and technologies. They will span rendering, compute, XR, payments, tools, projection, volumetric compression, AI, ML, you name it. And the quality and capability of these tools will be key to what’s built and by how many builders. But so too are the rates these tools and technologies require, the extent to which they lock in developers, and ways in which they limit consumer choice and the creation of competing innovations.
As the need for interchange solutions grows, economics tends to generate a solution. For example, Disney’s Pixar open sourced its Universal Scene Description (USD) file format to help developers create interchangeable 3D data. Nvidia’s Omniverse platform then uses USD to coherently bring together assets from Maya, Houdini, Unreal, AutoCAD, and more, into a shared virtual environment. Epic’s Twinmotion platform can also be used to import models from nearly any BIM and CAD program, such as Archicad, Revit, SketchUp Pro, RIKCAD, and Rhino, and will then use machine learning and AI to upgrade and integrate them wherever possible and in a matter of minutes.
Not even Ball wants to get his hands dirty, he’s quite content with throwing as many existing software stacks at the wall and hoping The Force will bind this galaxy of applications together.
If you trawl the web there are echoes of attempts where someone has either created and abandoned a project but nothing so specific exists today or has even been mentioned or championed.
For a start, if you look at the list of existing operating systems, not one fits or has been written specifically for the virtual world or metaverse implementation. Already we’re off to a bad start — we’re solely relying on Microsoft Windows, Apple whatever the name is today OS, Android, or even Linux all of which were not developed for a truly decentralized future or one where we need to write applications in 4 or even 5 dimensions.
(what I mean is, writing an operating system for 3D and the “spatial web” is already limiting the future because you need to account for time and then multidimensional virtual machine states — like the Minecraft within Minecraft example)
Just think of the movie Inception and let the possibilities sink in and the changes in requirements needed to consider interoperability that in an existing virtual world environment, not necessarily connected to.
Will virtual worlds built inside an existing one inherit the properties of the parent for example, like most parent-child relationships in software? Or are there some other 4th dimensional properties that need to be taken into account?
Can economic interoperability — the flow of tokenized assets and monetary economies — exist separately and also interact and influence one another if I build a fully-fledged metaverse within someone else’s existing framework, not alongside it?
At this point, I probably sound very stupid so you’re free to quit here.
NewZoo dumps a bunch of logos into a picture in a pleasing arrangement
What we have today is Epic, Unity, NVIDIA, ARM, Valve, Facebook, Amazon, Microsoft, Apple…and the many other companies they’ll eventually acquire and swallow to create toolsets specifically for designing, building, and operating their versions of the metaverse. They’ll all compete to create a set of seemingly open standards but will not want to relinquish their sense of proprietary ownership.
Building the metaverse has largely depended on game engines such as Unity3D and Unreal Engine but in the coming years, we’ll see more and more venture-funded attempts to wrestle that control away from just the two or three major solutions. This will also mean that the platforms that every version of the metaverse will exist on will also start to diverge — presently they’re interchangeable and accessible cross-platform on PC, mobile, and console but more sophisticated and potentially proprietary worlds will exist that would exclude one or more platforms and restrict access.
Yes, APIs are key to interoperability and the need to use tools across the ecosystem but it won’t be the silver bullet as platforms compete and fragment.
There won’t be one encompassing metaverse to rule them all.
Much the same way there will never be a single Skynet of artificial general intelligence. There will be hundreds of metaverse, spread across a multiverse of genres and types for people to interact, live and conduct business and pleasure in. Not to mention personally owned versions.
But what if, in the future, they all sat on an operating system that was built specifically for the purpose and vision we want to achieve? So what choices do we have available?
Linux was released in 1991, it took Torvalds around a year to develop the Linux Kernel from scratch and then build on it so it’s not like we can’t develop a brand new OS from the ground up.
Croquet OS is a platform and IDE for Metaverse development that extends the Metaverse to the next generation of Web and Mobile. The IDE allows developers to build and deploy “interoperable, [standards-based] Web and Web3 virtual worlds,” the company has said in a statement.
It is a synchronization system for multiuser Metaverse experiences. It allows multiple users to work or play together within a single shared distributed environment, and it guarantees that this distributed environment will remain bit-identical for every user.
“Croquet has taken a fundamentally novel approach that makes this as easy as writing local code or no code at all. It has the potential to provide an open, standards-based way forward that leverages the power of the web to create truly independent, interoperable Metaverse worlds”
Is it an operating system though? No by the sounds of it. It’s another platform with a few bits tagged on. And it’s probably sitting on one of the common OS platforms already.
Things get slightly more interesting with the Open Source Metaverse Project. The Open Source Metaverse Project (OSMP) was a multi-participant shared virtual world online platform. This platform was free and open-source software co-founded in 2004 by Hugh Perkins and Jorge Lima.
OSMP was loosely modeled on the World Wide Web borrowing ideas from existing worlds such as Second Life, Active Worlds, and There. The project aimed to produce an open-source engine for the creation of streamed 3D worlds, also making it possible to interconnect existing worlds into a single open, standards-based Metaverse.
The OpenSource Metaverse Project was created because a strong demand exists, and large developer following, for virtual worlds that allow customization by the player and creation of one’s own worlds. Closed source virtual worlds exist already but we needed a metaverse engine that is flexible, scalable and that we can customize to an extent not possible within individual proprietary worlds.
If you’re hearing about this for the first time you won’t be alone, because it’s pretty much gone nowhere much like other previous attempts at building open and interoperable platforms.
Interoperability, for example, doesn’t come from building bridges between platforms, it comes from being there at the root level, deep within an operating system itself.
Solipsis — not an OS but it did have something interesting
The central objective of Solipsis was to create a virtual world that is as independent as possible from the influence of private interests, such as server ownership. In order to achieve this, it is based on a peer-to-peer model rather than the traditional server-client one. Additionally, it aims to give users more flexibility in designing interfaces and content in their individual segments of the virtual world.
Behold, a decentralized metaverse platform!
A centralized architecture cannot lead to a truly self-scalable solution, even with the use of multiple servers. Indeed, client-server architectures lead to prohibitive deployment and maintenance costs when it comes to very large-scale applications with thousands of connected clients.
On the other hand, thanks to their self-adaptation features, P2P network overlays have clearly proved to be an effective alternative to powerful servers.
So Solipsis was starting to shape up like one of the more credible attempts at building a decentralized and open metaverse as far back as 2008 from an infrastructure perspective.
The virtual world is initially empty and is only filled by entities run by end users’ computers. All Solipsis nodes are functionally equal, and no preordained infrastructure is required. This eliminates as far as possible any restrictions on the content or functionality of the world.
As far as metaverse platforms go, this comes close.
It also had a bespoke navigator, or browser, which is something that has been specifically discussed within the walls of Lamina1 — a new metaverse browser built for the immersive web.
It’s still a platform play but as I kept falling down the rabbit hole looking for anything resembling an operating system itself I started to see patterns and threads of what could be built on top of a decentralized OS meant for the next iteration of the web.
A leap of faith into the spatial web
The work presented here is a first step towards a grid operating system which provides extensive, flexible services for grid architectures.
But for all the work done on everything mentioned so far, nothing touches having to build from scratch, building a new kernel for a new operating system.
Look at this, just fucking look at how much work we have yet to begin
I mean, look at this diagram, it’s fucking scary and yet a bloody marvel at the same time — this is exactly the level we should be starting to think about now if we are ever to realize the promise of web3 and the metaverse.
And that scares them because it also means something else.
Which came first — the chicken or the egg?
Or, put simply in another way: which should come first — the operating system or the chip?
People who are really serious about software should make their own hardware.
Alan Kay, 1982
Lamina1 Mission Statement
It speaks volumes that not even Neal Stephenson’s Lamina1 whitepaper mentions anything around a metaverse or web3 operating system — it’s either a massive oversight or I’m just bananas. And of course, who would ever want to go up against the Godfather of the Metaverse? It’s fucking blasphemy!
The way I see it is that most of these new attempts are driven by OGs who were there 20–30 years ago and don’t have the time nor the patience to want to build something as cumbersome as a new OS, champion it, wait for adoption, build a new industry from it.
We’re cutting corners and already this latest iteration of the metaverse feels like the one we had 20 years ago with Second Life. It doesn’t matter if blockchain adds a little extra spice to the infrastructure, or that Fortnite makes everyone wet with anticipation, it’s not enough to save it.
Think about it long enough and it starts to manifest an issue.
We’re writing software based on the silicon architectures that are available to us right now. This creates bottlenecks that the software has to continually work around because the chips were never meant for a decentralized future.
To all intents and purposes, CPU might as well mean “centralized processing unit” where we actually need a DCU — “decentralized processing unit”.
But what if we need something different on all fronts to create the metaverse we really want, or free Web3 and build it the way it was meant to be built?
New hardware for new software.
There’s still money in creating new types of chips — take Graphcore for example, architecting a new type of silicon specifically to accelerate machine learning and AI. What if in order to create a truly open, distributed, and interoperable metaverse we needed Web3 to be sitting on a new type of hardware foundation too?
CPUs or GPUs that were built purely for distributed systems or a decentralized web?
Grid-processors are different from GPUs for example. Where a multi-core GPU gets its strength from being able to compute lots of data in parallel (SIMD data-parallellism), a grid-processors is able to have each core do something differently (MIMD, task-based parallelism). You could say that a grid-processor is a multi-core CPU.
Memory that is architectured purely for grid-based in-memory configuration. Hazelcast, for example, has software something along these lines but what if we gave them a bit of a nudge in a new direction and developed new types of RAM to go with it?
An IMDG is an in-memory version of a data grid, except that all nodes of the cluster are typically run in the same data center. This local configuration is done to maintain the expected high performance of in-memory technologies, as coordination of data structures over geographically remote computers can be a bottleneck.
Do we then wait for someone to build the chips before we write the software to support them, or write the software and wait for the silicon to be developed to take advantage of it?
I mean, I find it funny as fuck that Lego has a bloody embedded operating system for its robotic Mindstorms line of advanced toys but we don’t have one or are even thinking of one for something that’s expected to have a profound impact on the future of the web itself.
I’m quite sure that they will say so.
But if you see what I see, if you feel as I feel, and if you would seek as I seek…very poetic Mr. V, but in all seriousness, if you’re a software engineer and this sparks a fire inside then get in touch. And if you’re an investor who sees the long game and believes in Web3 and the metaverse the way it’s meant to be, then you know how to find me.
Because believe me, in either this current generation or the next, there will be someone who is sitting bored in their bedroom after experiencing the latest ̶b̶r̶a̶n̶d̶ bland offering in Roblox and that first line of a new operating system for the metaverse will be written that will redefine the future of the web.
And the rest, as they will say, was history.