The Universal Library. A coordination layer for the Metaverse
Make sure to check out our previous entries in: The Universal Asset framework series.
What are we trying to achieve?
A truly interoperable Metaverse will not be achieved by solely making available to the world a suite of separately created open-source tooling and standards. We also need a high-level coordination layer to pull this off. This is a problem that most builders in the space are not addressing directly, for understandable reasons. Top-down designs are often rigid, too abstract, imposing, controversial. Most would rather build tools that give us tangible incremental improvements today. However, this doesn’t give us control of the direction in which we’re going. Because we don’t know where we’re going, we’re focused on the trees, not the forest. Letting the path build itself organically, from the bottom up.
This is often the preferred path, we’re terrible at predicting the future. Top-down designs tend to lock us into making a series of choices to make the whole design work, that is in most cases suboptimal when the actual future presents itself different than what we thought of, or we didn’t account for something else. However, building with no foresight at all is just as foolish as trying to build the future in a rigid way. There are things we all more or less can agree, on what we want an open Metaverse to have, some minimum requirements. These can give us a set of constraints we can use to build a top-down — yet opt-in — framework for the Metaverse. One that isn’t rigid but flexible, one that favors building virtual worlds in a composable, interoperable, easy, transparent, permissionless way. A framework not only to build a Metaverse with open-source tools, but to build the Metaverse — in the open — together.
The Universal library
This coordination layer could for example, take the form of a special kind of library, let’s call it a universal library, one to which any person can contribute. A public library or repository — not of distinct and specific tools, a collection of unrelated things, like what a museum would be—but a library of standardized blueprints, that define building-blocks (primitives) we can use to build virtual worlds. Since these building-blocks are published in the open, anyone can integrate them inside of their virtual world. The library benefits every world-builder as it grows.
Note that we said a library of building-block blueprints, not a library of building-blocks. These blueprints are meant to be purely informational, this should help with interoperability and future-proofing, as they do not impose any technological choices upon worlds that want to integrate them. We simply need to inject/integrate the information from these blueprints into our virtual worlds. This process of integration would be up to each game/world-engine to implement, and would amount to something like creating a predefined building-block/primitive (these might be virtual objects, game mechanics, etc.), with a set of initial parameters. The number and type of parameters, and their recommended values, are contained in the blueprint, they define the properties of the building-block/primitive we’re creating, that we’ll use as a starting point to build upon further. As long as we do not break any of the specifications detailed in the blueprint (number of parameters, values, etc.), we would gain some sort of interoperability. To see better how interoperability might arise from doing this, we can draw an analogy with topology.
If you like it, put a ring on it
In topology, a coffee mug and a donut are said to share the same topology (they have 1 “hole”). Topology gives us a way to classify any volume, based on how many “holes” it has, regardless of the quirks of its shape. By having a hole, the donut and the coffee mug share a sort of unexpected interoperable functionality, they can for example both be used as a ring (if you were to scale them down enough to fit your finger). Something we can’t do with an object without a hole in it, like a sphere. In this case, topology offers us a way to classify objects, based on a shared property (number of holes), which might or might not prove useful to us. Actual topology however, is not all that useful to us. But we can create “pseudo-topological” systems for our blueprints, based on other properties we do find useful, which gives us a way to classify many types of interoperable building-blocks into families/categories, that share a series of relevant properties. A form of property-based classification.
In the same way two topologically equivalent things can share a property in common, two different building-blocks that were constructed from the same blueprint (and don’t violate its specification) would share some properties in common, these are interoperable properties! Any pair of building blocks sharing the same blueprint would have at least some degree of interoperability in terms of features (those defined by the blueprint). Even if those worlds had never communicated or coordinated with one another before.
Final Remarks
This universal library made of building-block/primitive blueprints for virtual worlds and their assets or mechanics, as we’ve described it here, is quite different then typical software repositories like GitHub. It hosts basic information rather than code, it also doesn’t store actual building-blocks, but blueprints that facilitate their creation, in a standardized way. These blueprints also are not independent of one another, they are part of a more general classification/taxonomy system, and are built to facilitate creating connections or relationships between the properties of one blueprint (like for example a piece of armor) with another blueprint (like a weapon).
These design choices are meant to maximize some of the properties we may all wish for an open Metaverse made out of many different virtual worlds to have: interoperability, transparency, composability, scalability… If these worlds decide of their own volition to start using these blueprints. They may even create a new standard for blueprints, or type of blueprint. Every world-builder picks and chooses what set of blueprints from the library to integrate. This doesn’t gives us ubiquitous interoperability, but it does gives us a slider or knob for interoperability, from 0, if worlds decide to not use any of these blueprints, to the maximum possible if most of their world is built out from these blueprints.
It’s in the hands of the inhabitants of the Metaverse to push these world-builders to increase their interoperability with other worlds, by using a bigger share of blueprints from this public library, and to contribute to it by creating new blueprints. Piece by piece, building components of the Metaverse, in the open.
