Wrapping Up: A Novel Metaverse Architecture

We’re skipping ahead to the very last chapter in our Metaverse design story: the reveal of a brand new architecture.

By now, it is clear to me (as much as it is to everyone else) that my interests have moved on. So, no fancy pictures this time, and no more groundwork. I’m not going to walk you through how we arrived at this final architecture. If you’ve followed the many articles along the way, it shouldn’t be hard to determine the specific problems we were trying to solve, and to extract the many pieces of unique value which are embedded in the design.

In short, by focusing on the right thing, it isn’t hard at all to initiate a Metaverse. In fact, all things considered, it is shockingly easy. And not just “a” Metaverse but “The” Metaverse. Part of the secret is to give the community an incredibly simple core element, and to allow them to build something that is far greater than any of its individual parts. Let go. Don’t try to control everything. The tighter you try to control The Metaverse, the more you destroy its core value. Stop it!

Another part of it relies on letting go of the science-fiction definition of a Metaverse (and the Second Life defintion of a Metaverse). We have to build The Metaverse using what we already have on hand, and invent as little as possible. We can’t tell everyone that they’re wrong. We have to show them how they’re right!

Guess what? We’ve got a architecture that, among other things, nullifies that pesky issue of critical mass and chicken-or-the-egg. In fact, it tackles a host of other problems that you probably never even knew existed. So how do we get there?

We start by building a minimal Metaverse. What is the most basic element of our real-world Metaverse? Is it identity? Is it an avatar? A massively shared space? No. In fact, it is something much simpler. We define the most fundamental Metaverse (and the value that it provides) based on hyperlinked spaces. We transport the user from one experience to a completely different experience. At its most basic level, The Metaverse should exist to connect and transition users between between experiences, even if they come from completely diverse sources, using completely different programming techniques. The Metaverse links two or more isolated experiences in a way that creates new value.

We could climb the cosmological stack, and perhaps even call it a Hyperverse (a play on “hyperlinked experiences”) or even an Omniverse (the sum of all experiences). Okay, I should stop here because this is quickly becoming pretty abstract… maybe even a bit strange. I’ve got to pull this down to Earth and explain a bit more.

The difference between Metaverse VR applications and today’s VR applications is that in The Metaverse, applications are built for hyperlinking. So, this means two things. First, that from your application, it would be considered completely normal to pass the entire user experience from your application to some specific point in the next application. If you want to be literal about it, okay, we can do that. We could use a door as our metaphor. A user could open up a special door in your application and walk through it. Unimaginative, but fine. They cross the threshold and control is transferred to the outside application. Your application ends.

The other thing is that you should expect that other applications will want to link directly into YOUR application. Your application is called by other applications. Other applications are called by your application. The underlying model is actually somewhat old (in Internet terms) and well proven: the 1990s Internet Suite.

Beyond that, consider that most people don’t just want to link to the front door of your application. They might, but that’s pretty boring. They want to link to deep content inside of your application. As deep as you’ll allow. You should identify specific spaces or experiences which are deep inside of your own application for others to be able to link into, and then to provide an easy method for them to directly get there, such as with some specific command line arguments.

So your application should expect to be launched from any other application, and you should expect that people will want to reach a specific destination inside of your application by using whatever specific command line arguments you are comfortable with. The destination could be derived programmatically (with any necessary safety checks) or they could be hard-coded by you, the designer. The more choice, the better, but as much as you are comfortable with.

Hyperlinked experiences are the real future of VR. They will allow you to create the best possible experiences in virtual reality, blended together, without the restrictions and limitations of language and protocols and engines. You always choose the best engine and the best language and the best middleware for your own application, given the constraints of your project. Give yourself permission to build the best application of its class using the tools you want. As you find opportunities, you’ll hand off the user’s experience to others who have done the same. Or maybe you’re not a programmer, but you just want to design your experience inside of someone else’s application without fear of it being trapped inside of a limited bubble. The Metaverse can help pop those bubbles and open up your content to a larger audience.

Remember that critical mass issue? As long as an experience doesn’t do anything foolish, like start in a 2D window or with a ridiculous splash screen, even if it isn’t Metaverse aware, by default, it is capable as acting as a leaf node in The Metaverse. It may not be able to launch other experiences, but it is able to be launched (and by other applications) from within The Metaverse. “The Metaverse? It’s so easy to join!” Any application. Any media. It is all part of The Metaverse.

Not every corner of the Metaverse needs to be massively multiplayer, or even an online experience. Who knows, one day my bank might want to create a virtual reality or a Metaverse banking application. Do I need to risk sharing my private transaction with millions of other people? Of course not. Each experience retains full control of its own boundaries. If it doesn’t want to be a fully shared space, it doesn’t have to be. If it has intellectual property or sensitive information that it needs to protect, it should be allowed to protect itself as it so chooses.

Some people will specifically create pure leaf nodes for The Metaverse. Build the best-in-class multiplayer “shrine” application and watch people build their shrines within your tool and then link to them from all sorts of other applications. You may be linked into by other applications that you did not know even existed! In the early days of the Internet, everyone started to build an email client into their application. One day, programmers learned to just let the user use their favorite email client, which was far higher quality than anything they could develop on their own. It’ll be the same for VR.

When we have hyperlinked experiences, we allow a whole new class of VR experiences to blossom that we don’t yet see today. Those are the experiences which aggregate people together, and the experiences from which people branch out from once again. A VR experience for, “I’m bored, what is there to do in VR right now?” A VR experience for searching other experiences. A clubhouse for like-minded people. These are the new experiences that will exist between today’s VR experiences. Do you like social spaces? Some might be social spaces. The opportunities are limitless.

The Metaverse isn’t a web. It isn’t a tree. It isn’t a central star configuration with a launcher application in the middle. It is a collection of nodes which can assemble in any which way their designers allow and the users choose. The nodes (the experiences, the applications) must assemble into the shape chosen by the users. Nodes launching other nodes launching other nodes. Nobody is in the center except for the user who acts to glue the Metaverse together, on demand, inside of their own PC, in real-time. The Metaverse is an amorphous blob, given shape by the user.

Once users see this in action, I don’t think they’ll have much trouble wrapping their heads around it. As this approach catches on, it will quickly become clear that some standardization is needed. People might want to use standard URIs which could represent a protocol (at first, they are more likely to represent specific programs). Early on, I had imagined a facility on your local machine that translates URIs such as vr://vrchat/room/900 into specific command line parameters used to launch a specific application (an application which may or may not be Metaverse aware). But still, a piece is missing.

It is easy to tell a programmer that their application might be called by another application. It happens today as a normal part of being available in SteamVR or Oculus Home, for example. It is another thing, however, to tell an application that they must call other applications. Now you have a whole new set of problems to juggle. Let’s avoid that. The same component that does the translation from URI to binaries with command line arguments will also serve another purpose: to be the parent process which launches, monitors, and kills VR applications. It is called The Matrix. (Don’t laugh! It actually manages to work out pretty well.)

The Matrix inherits its name from the fact that it manages the transition between two programs (from an application perspective as well as from a user’s VR perspective) by negotiating a match in the matrix of potential transition capabilities. Depending on what features the current experience and the new experience support (if any), the Matrix negotiates an appropriate application transition and visual transition between two applications.

A round photosphere that is smashed into the ground? A shared room between them, such as a rigidly defined white hallway or holodeck grid? Or maybe the lights go bright in one experience and then dim down to normal levels in the next experience? From a programming standpoint, the general method will be for the calling program to give the new destination URI to The Matrix, the Matrix to inform the program of which of its pre-approved methods of transition will be used, and then to use that method to transfer control.

Will this be a carefully negotiated shutdown or will it be a cut to black and a hard kill of the calling program? Will there be shared room contents and user positional and orientation data until the exact moment of transition? That is the job of The Matrix to coordinate or, at worst, to directly perform a minimal transition by itself.

The Matrix will be the compatibility layer that needs to be aware of what Metaverse applications are installed on the local platform, and how to launch them. Later down the road, it might be useful to have an installer functionality bundled into it so that it can install new rich applications on demand. But it’s not required.

There we have it. A new Metaverse architecture that is engineered to be simple yet packed with value. Any number of applications can launch and be launched with minimal effort. A simple hard-wired (“baked”) proof-of-concept would take minimal resources to create. A fully functioning system will take more.

Along this early road, there will be some wrinkles. For example, in the world of 2D applications, World of Warcraft doesn’t have the same display and control schema as Team Fortress 2, or as another title like FTL. This is by design, and users accept this. They realize that there is value in letting each experience have its own unique set of controls and its own unique way of displaying things. Will this be the same in The Metaverse? Maybe application designers will arrive at a commmon control schema? Or they might decide that inheriting a set of common controls is a feature that The Metaverse should provide for them.

Users also understand that they can’t bring their FTL starship into Azeroth, which is the intellectual property of Blizzard, or take their toon back into FTL. Hopefully they will find the same level of understanding when it comes to The Metaverse.

Once you have a very loose structure where VR experiences which can be linked together, we start to create a shared community of users, programmers, and experience builders. As the value of a Metaverse experience starts to prove itself, the participants begin to take their seat at the table. They see that it demonstrates real and unique value. It begs for enhancement. Above all, the ability of a minimal Metaverse to bring the interested parties together may be the most understated value of the entire design.

That community may decide that they want an even richer experience with more features. A single identity? A shared avatar? Services that persist through multiple services? On top of the thread that connects applications, they might look to build a rich new thread that runs between and through applications. One we bring all parties to the table based on the value of hyperlinked experiences, this and so much more is possible.

The first step in building The Metaverse isn’t to build something complex and crazy. It is to start with a minimal Metaverse experience based upon the value of hyperlinked experiences. Start the Metaverse by linking together diverse virtual reality experiences, demonstrate the value of connected content, and the rest unfolds from there.

---

As mentioned at the top of the article, I am moving on to other personal interests. If you have any questions, you may click on the title of this article and use the Reply feature at the bottom of the page. You may also email me privately at my Yahoo! account with a username of jmccorm and a subject of Metaversing. For a limited time, I’ll be happy to answer your questions, clarify or defend any aspect of this unique Metaverse architecture, or just bat around some ideas.

To my loyal readers over the years: thank you!

---