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!

---

Internet 2021: A Metaverse Project on Kickstarter

In the moderation queue for the Metaverse subreddit, I came across a submission that had been withheld by the AutoModerator.

I visited the link and found something very interesting. It was a Metaverse project on Kickstarter. Their apparent crime appeared only to have been in putting too many dashes in the title, so I approved the link submission to /r/metaverse.

I am not involved in this project and I can’t provide a personal endorsement for their effort. Still, I thought it was interesting, and because this is the type of project that readers of Metaversing would tend to be interested in, I wanted to share this with you.

Technically, this isn’t the first Metaverse project to hit Kickstarter. That title probably belongs to either Surreal Adventures, or the VR Sandbox MMO called Voxelnauts. But this appears to be the first one that puts the Metaverse aspect of the project as something that is front and center, and not as an additional consideration to the side.

The traditional sales approach for a Metaverse project would show us a unique virtual world and sell backers on the sizzle of unique avatars, interesting environments, and a massively shared virtual environment. That isn’t what is happening here. They’re attempting to engage us… intellectually. Strange, isn’t it?

They start with their definition of a Metaverse, based upon the pillars of realism, ubiquity, interoperability, and scalability. They identify four major obstacles to include monetization, proprietary elements, lack of critical mass, and a premature focus on realism.

Their primary aim is to overcome the first two obstacles, which again are monetization and a proprietary platform. They propose a three year project for a core development team to work with backers to create a final project that would be released to the subject as open source.

Various levels of participation by the backers would result in increasing levels of influence in the project as well as rewards, such as a five year contract for land in the residential and commercial areas.

I’ve embedded their Kickstarter video below.

The part of their presentation that has generated the most interest begins at the 8:11 mark. They illustrate a live portal inside the world of Minecraft which would allow one to peer live into the world of Doom (and presumably, one in the world of Doom could peer in the reverse direction into the world of Minecraft). One might join their counterpart on the other side as simply as crossing the threshold. That appears to be the level of interoperability that this project hopes to enable.

The project itself is light on details, and it is something that I would like to have seen more of. Part of this may be because the goal of the project is to actually flesh out those details and implement them. Another reason may be the real threat of Brain Rape, a process where a venture capitalist or other developer seeks more disclosure, but only for the purpose of using that knowledge for themselves.

You can find out more about the project by visiting it on Kickstarter, and if you have specific questions for the project’s creator, you can always use the Contact Me link on the project’s main page.

I’m happy to see someone going in a different direction and breaking away the convention of a typical Metaverse project.

Update on the Metaverse Proposal

As of my last article, I had promised to explore the interconnect, and to provide a proposal for a Metaverse implementation that is both practical and specific. I haven’t delivered on that pledge as quickly as I had hoped, but I wanted to provide an update as to the new direction it is taking and how it is progressing.

My goal has switched from writing an article which proposes a Metaverse implementation to actually working with a team of people who are interested in exploring and actually implementing an initial specification. In the past few months, I’ve made some progress towards that.

As part of that, I’ve presented the core of the design to two different technical audiences (both skilled in the area of virtual reality). Both audiences received a full disclosure of the (otherwise unpublished) mechanism for the core Metaverse design. They got the basic Metaverse v0.1a blueprint.

The first audience didn’t have much in the way of background information, so the entirety was presented in a vacuum. They were able to see that it made sense, but other than that, there wasn’t much in the way of real enthusiasm for the project. Looking back, I can’t say that I blame them.

Ahead of the presentation, the second audience actively explored a great deal of background information on the subject. This background information explained the more global issues that Metaverse implementations have faced and some of the larger problems in virtual reality (Most of this, you’ll find in some of the earlier articles here at Metaversing.)

After explaining the core technical design, not only did they quickly understand the proposal, but they actually started selling me on the design and explained how it solved some of the issues that they themselves have run into. It went far beyond anything that I had expected from the experience.

The lesson I learned from this was that providing the technical specifics in a vacuum is a horrible way to onboard people to the project. A certain library of background information is required to help people digest the design and to understand the wide-ranging value which it creates.

At this point, my effort is concentrated on the onboarding process. Primarly, it is the documentation which provides that background information, shares the vision for what we are trying to accomplish, presents the initial design, sets a very specific project as a trial run.

An early first draft was sent out to a private review audience, and based on their feedback, I’m in the process of making revisions. I hope to have a complete and second document set to send out in the next few weeks. I’m hopeful that we’ll be able to zero in on a good set of documents sooner rather than later.

So, that’s where the Metaverse proposal is at. It has taken on a more concrete form, and is inching forward quite a bit slower than I had hoped, but it hasn’t died. Far from it!

My apologies for a lack of updates up until this point, and I hope to have something more substantial to share in the near future. Thanks, everyone, for your patience.

A metaverse subreddit is now available!

I’m happy to announce that /r/metaverse is now a public subreddit which is dedicated to the discussion of metaverse issues. Do you have an article to share? A question to ask? Head on over to /r/metaverse and join the conversation.

On a more personal note, I’ve returned to my writing. I am currently drafting an article which explains Festival Blanket, an application for shared public experiences for a VR audience. Some of our previous conversations about scale and non-euclidean space end up working their way into the solution. Stay tuned!

Defined and Explained: Creating the Metaverse in the Real World

Two years ago, I restarted my effort to make sense of the Metaverse. Today I can confidently tell you that I understand what the Metaverse is in the real world, and how it actually works. You’re about to understand it, too.

• What is the Metaverse?
• What purpose does it serve?
• Where do we begin our efforts to build it?
• What new applications can we make to take advantage of it?

Have we cracked the code? See for yourself if this article delivers those answers in a meaningful way.

What is the Metaverse? The real Metaverse?

No, not the one we’ve seen portrayed in science fiction. Also not the large software project which creates connected spaces for people to design their own worlds in. Not the intellectual notion which claims the sum of all media, yet offers no direction on how to get there.

So many of us say that we want the Metaverse, yet this decades long journey has been so frustrating. For the most part, we’re able to agree on something that is so clearly illustrated, yet we’re unable to say what it really is and how to implement it. Why?

Private Review of an Upcoming Article

As many of you know, I am working to do something more than just analyzing, commenting, and reviewing virtual world and metaverse issues. I am actually proposing a viable metaverse design.

I have an upcoming article, currently titled, “The Metaverse. Actually Explained.” It is the first article that directly advances that effort. It provides a definition of what the Metaverse is, demonstrates a whole new market for applications, illustrates the real-world value the Metaverse provides, and gives us a starting point on how we actually go about implementing it.

I’m making this article available ahead of time to a limited number of people for the purpose of a private peer review. You get an early look at the article and a chance to shape where it is heading. In exchange, you agree to provide your feedback on what you see, and you promise to keep the article confidential until published. Simple as that.

I’m wanting to keep the circle somewhat limited at this time, so I’m going to restrict it to those who have at least had some sort of interaction with me as of yesterday. Twitter follower, online discussions, etc. If you’re interested, send me an email at jmccorm@yahoo.com agreeing to these terms and reminding me how I know you.

I’m looking forward to where this goes.

Systemic Issues in Metaverse Implementations

PREFACE

This article is much longer than I would have liked, yet I wasn’t able to dive into each of the subtopics in as much detail as I would have hoped for. Still, it provides some foundational material for a later examination and proposal for a metaverse implementation. If you are a serious virtual world or metaverse enthusiast, this article is probably for you. The more casual reader may want to skip this article.

If you are involved in a metaverse project, you may find it referenced below. Nothing you read here should be considered a harsh criticism of any one particular approach. In most cases, these implementations are named to illustrate an example or a counter-example. This article doesn’t attempt to perform a complete review of platforms or to call winners.

INTRODUCTION

Previously, we identified seven issues which hold back our current metaverse implementations. Can a metaverse actually break through all of these issues to become a major platform?

What if we build on a distributed services architecture? Should we position the desktop client as a 2D/3D content browser? What if we use open standards, or build upon a proven engine? These and other suggestions may turn out to be very good ideas, but we don’t know. We’re still trying to understand the underlying issues which are holding us back.

Image Source: Intland Software, Using Root Cause Analysis to Drive Process Improvement

SPECIFIC PROBLEMS ILLUSTRATE SYSTEMIC ISSUES

Clearly, there are more problems than the original seven which were provided in the first article, but those seven create a pool from which we can look for more systemic issues.

Experiencing Presence in a Text-Based Virtual World

I’ve been invited to participate in an online panel on MUDs, MMORPGs, and the Metaverse which includes Edward Castronova, a professor of telecommunications at Indiana University. He was heavily involved with the early MUDs and virtual world scene, and has written both papers and books about virtual worlds and their economies.

The DikuMUD Family Tree

As part of my pre-panel research, I brushed up on my own involvement with MUDs during the 1990s. Much of my time was spend in the DikuMUD family tree, and mostly with ROM, the Rivers of Mud variant.

In the early 1990s, it was easy to sum up the MUD experience in just a sentence. You could say, “It is just like Zork, except, multiplayer” and most technical types would nod their head in quiet appreciation. Today, it is much more complicated to explain only because text-based games are unfamiliar to most people.

Book Review: Designing Virtual Worlds

It has been over a year since my last review of a vintage virtual reality book. I’ve recently come across a good one that I’d like to share.

In 1978, Richard Bartle co-authored MUD, the very first virtual world. In 2003, he shared his twenty-five years of virtual world and MMORPG experience in the book Designing Virtual Worlds. Here are some excerpts from the preface:

Too much virtual world design is derivative. Designers take one or more existing systems as foundations on which to build, sparing little thought as to why these earlier worlds were constructed the way they were.

Are designers even aware that there are decisions they can unmake? Although a good deal of design is evolutionary, that does not mean designers can’t be revolutionary, too.

The key is in recognizing the face that what seems eminently logical to you from your usual perspective might turn out to be disastrous when viewed from another angle — and then realizing that the worlds you’re drawing inspiration from almost certainly contain elements designed by people who didn’t recognize that fact until it was too late.

Obviously, the preface resonated with me on the topic of metaverse design.

The book is an incredible seven hundred and fourty-one pages, filled with decades of experiences and observations in virtual worlds. According to Wikipedia, it has been called “the bible of MMORPG design”.

Quantity versus Quality: Fifty Pounds of Innovative Yet Broken Clay Pots

There is a story retold in the virtual reality community which emphasizes reaching perfection through a quantity approach over a quality approach. The text originally came from the book Art and Fear, which is about the process of making art. I like Derek Sivers’ shortened version, so I’ll repeat it here.

The ceramics teacher announced he was dividing his class into two groups. All those on the left side of the studio would be graded solely on the quantity of work they produced, all those on the right graded solely on its quality.

His procedure was simple: on the final day of class he would weigh the work of the “quantity” group: 50 pounds of pots rated an A, 40 pounds a B, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an A.

Well, come grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity!

It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

Sure, you have to question the authenticity of the story, but for most people, the lesson rings true. This is the lesson that we should walk away with, right? Quantity trumps a quality approach when trying to reach perfection?

No. Not at all. It is critical to understand the story in its original context.