You will own everything, and be flashy. “Universal Assets” as a solution to the Metaverse interoperability problem.
When you’re finished here, make sure to check out the rest of the articles from: The Universal Asset Framework Series.
TL;DR
By letting the most important Metaverse assets live and be created outside of any given virtual world, we can make them truly ownable by users of the Metaverse, and universally interoperable in any virtual world or experience. All we need is a guiding framework and a coordinated approach. This should allow us to create new types of interoperable virtual objects, which here we’ll call: Universal Assets (UAs).
Why do we need Universal Assets?
The following framework describes a new type of interoperable virtual object, the Universal Asset (UA). Which boldly seeks to maximize the freedom of users (their owners) to personalize every possible visual aspect of them, while allowing any virtual world to automatically recognize, import, and integrate them.
In essence, to split the “syntactic meaning” (visual rendering) and “semantic meaning” (in-world behavior and properties) design of ownable virtual objects—such as 3D bodies, clothing, armor, weapons, etc.—letting users be fully in charge of the visual rendering aspects of the asset, and world-builders be fully in charge of the in-world behavior and implementation, without the need of any coordination between these two parties (prior to the creation of the UA). This new framework is very different than your typical approach towards interoperability.
The most common approach towards achieving interoperability of any kind, historically, has been to try to impose the adoption of a single, rigid, universal standard — which doesn’t allow individuals to stray from that specification, and therefore can’t adapt to the different necessities of each individual, or allow for innovation/experimentation.
This is the current approach almost all the people working on the problem of Metaverse interoperability are trying. Either by coordinating together many industry actors and companies to agree to a standard, or by a single company and brand hoping to grow and become the number one player in the space — essentially a monopoly — so that eventually people will simply demand all other companies adopt the top-dog’s approach towards world-building, for it being the path of least resistance. This approach reminds me of the Borg:
This usually means any possible customization is at best, choosing between a limited selection of already pre-baked available options. These solutions tend to not be modular or flexible, and more of a take it all or leave solution. It’s a tyranny in disguise, that often squashes agency in the name of universality. While this would indeed give us interoperability, it would be a rigid system where all world-builders and users would have to bow to the standard, leaving little to no room for any personalization or deviation.
Although some virtual worlds might accept this standard, it imposes a heavy cost on variety and creativity. I’d argue most will not tolerate it, and will prefer to create their own bespoke worlds that are unique, at the cost of losing interoperability, which is what we were seeking to avoid in the first place.
However, there is I think an alternative solution, another way to create a universal standard, but one which is flexible, modular, unrigid. One that only seeks to standardize the minimum amount necessary—quite literally — instead of the entirety of a virtual object, and one that describes these parts that must be standardized in a technically agnostic way.
Meaning, we define them in terms of desired properties, number of parameters, scope, size, etc. that must be respected, but we leave out the technical details of how these are achieved. Each world/software creates their own technical implementation, but one that respects a public and global specification.
It’s an optimization process beyond the typical way of creating standards, where we ask ourselves: how much can we let undefined, before the standard breaks and we lose interoperability? This wiggle-room is what users and world-builders can leverage, to accommodate their particular wishes for what these new virtual objects will be, either visually (users) or functionally (world-builders).
This separation, where users can freely choose how an object looks, and world-builders how it behaves in their world, should be possible by implementing a minimum set of restrictions on both parties, that will help us define a new primitive for our new Universal Assets (UAs). These new primitives that we’ll call “Universal Primitives” (UPs) are the minimum that we need to standardize.
Defining Universal Primitives
UAs have the following components: a “Universal Primitive” (UP) or bare-bones structure which is the common standardized part, and at least two customizable components, the “visual rendering” and “In-world behavior” labeled in the above image. The visual rendering part constitutes the syntactic meaning of an asset, while the UP and the “In-world behavior” constitute its semantic meaning.
Since we want to be able to turn any possible interoperable asset into a UA, but giving a bespoke Universal Primitive (UP) to every possible object is probably too unwieldy, we propose instead to divide all types of possible interoperable virtual objects that wish to be compatible with our new standard, into a series of finite categories/boxes, where all the objects inside the same category/box share the same series of properties, and from these categories/boxes construct the UPs we’ll later ascribe to the possible objects that can fit inside them.
We’re in essence defining a series of rules or blueprint for the creation of a public library of possible interoperable assets, where any asset we might imagine creating needs to fit into one of these object categories/boxes. This is mainly a taxonomical endeavor, creating families and subfamilies of types of objects. So belonging to the “virtual sword” family for example, there might be several different categories/boxes, such as: straight swords, greatswords, curved swords, etc. Each one of these belonging to a different category/box, and having a different UP.
When we want to create a new interoperable asset, we must first assign it to one of the available categories/boxes — and therefore a corresponding UP — in this public library. In this sense, the amount of distinct interoperable virtual objects we can have under this standard is proportional to the amount of categories/UPs present in this library. These UPs are not too restrictive though, since different-looking objects often share approximately a lot of similar properties, and therefore it makes sense to group them together in the same category based on these.
In later articles of this series we’ll describe in more detail what UPs will look like, but they’re basically data we attach to these object categories/boxes we’ve created. Mostly a set of restrictions to things like the size and volume of the associated asset, or more abstract technical requirements for interoperability.
Since this framework should allow us to separate the visual representation of an asset from its ultimate functionality, users and world-builders only need to choose a UP as their starting point, configure the parts of the asset they have access to as they wish, and later on we can merge together any two pieces that share the same UP, to create a full UA with all components defined and ready to be used in-world.
This process of building UAs by parts and later merging them together, will probably be facilitated through a “Universal Asset creator” (UAC). This UAC will likely be a program or piece of software with access to our library of UPs, within a world-building engine (something akin to modern game-engines used to create videogames, but with more tools to accommodate the creation of virtual worlds). This UAC would be a standardized way for users to create the visual representation component of a UA.
World-builders would also have access to this same library of UPs, and use them as a starting and reference point when creating and programming objects inside their worlds, that they want to be interoperable. They can define how they behave, and choose a bespoke or generic skin for the object, which later when the world is opened, allows users holding that type of object to change its visual skin for one they created or have in their wallet.
The role of Blockchain and NFTs
So far, the only technology we’ve created capable of giving us truly ownable and scarce digital assets are NFTs (non-fungible tokens), so it makes sense that the end result of using the UAC would be to mint an NFT with the visual representation data of the UA linked to it, and where the resulting token is airdropped into the wallet of the creator of the asset. This is akin to players owning the skin or appearance of an item, in NFT form.
This NFT can later be read from the user’s wallet when they want to import it into a virtual world. The necessary visual information of the asset — textures, 3D meshes, metadata, and other type of digital files — will be linked to the NFT but reside off-chain (outside the blockchain), and will be fetched by the virtual world during import.
The virtual world would recognize the UP used by the asset, and have already pre-programmed by the world-builder a set of in-world properties and behavior for that type of object. World-builders are free to choose what type of UAs they’ll allow to be imported into the game, they’ll code-in properties and behaviors for different universal primitives.
As long as there is a match between the UP read from the UA data, and the UPs the world-builder has coded into their world, the virtual world should be able to automatically merge together the imported visual information with the pre-programmed in-world behavior. Dropping into the virtual world a complete virtual object with all the necessary information specified, so it can interact with all other objects of that world, without causing any issues.
The end result doesn’t necessarily need to be an NFT (although it seems likely this will become a popular choice, and will be the example that we’ll discuss across this series), the UAC creates a data package that is what will be imported into any given world. Whether that data package is linked or not to an NFT doesn’t affect its utility or hurt interoperability.
What would the asset creation process look like?
The way the UAC would work (from the viewpoint of a user creating a new asset) is: they would open the UAC, and start by selecting a UP for that asset. This would give them a 3D volume, inside of which they would drop 3D files, or configure some visual parameters.
The main restriction being, whatever they do has to fit inside the 3D volume provided. Perhaps there could be further restrictions, such as the need to fill a minimum percentage of the provided volume, or have a minimum level of opacity for any textures provided. And that would be pretty much it. The only part we’ve made customizable for the user is the visual appearance of the UA. Afterwards the UAC would handle the rest, minting the asset, potentially as an NFT, and transferring it into the wallet of the creator.
This simple framework should be easy to implement on assets which have a constant size, such as weapons. Avatars (3D bodies), armor, and clothing, might prove more complicated to standardized than weapons, since they can have wild differences in size depending on the particular physique of each virtual character. But this is a general framework that should work for almost any asset imaginable, we only need to find the technical way of achieving it.
What virtual objects should be Universal Assets?
It wouldn’t make sense to make all the objects inside a virtual world interoperable, an NFT, or customizable. In fact the vast majority of them will not be. We only need to apply this UA framework to the type of objects we want to be interoperable.
These will most likely be any asset that pertains to your virtual avatar, such as equipment you can wear, your avatar’s body, perhaps even one day your attacks or magic spells. As we’ll see in later articles of this series, we can expand the concept of UPs to encompass many things beyond virtual objects, including game mechanics. Giving us plug-and-play gameplay components for our virtual worlds.
Putting it all together
What would be possible if all of this became true?:
- Anyone would be able to create, use, and sell a virtual object—the UA — in the form of an NFT for example. Without needing the permission of any given company, or entity behind a specific virtual world.
- Any allowed UA is a first-class citizen in any virtual world, whether it’s created by a big company, or an individual.
- You could make some of your items look however you want, without compromising gameplay.
- There would be a marketplace and secondary market for all of these UAs. World creators would be competing at the same level as independent artists, and other individuals. Many artists might even decide to leave their jobs and go independent, creating characters, weapons, armor, items they can sell. No gatekeepers in sight, a genuine revolution built upon user-generated-content (UGC).
- Each virtual avatar will likely have some sort of digital identity, probably some form of decentralized identifier (DID) or self-sovereign identity (SSI), to which one could link certain UAs (their gear) to that specific avatar.
These are only a few of the possibilities.
A sea of clones
To end, I want to briefly discuss one way we could make these UAs truly unique. The way I’ve laid it down here, it would seem that no single item would be unique, as anyone could clone any item they want if they had the means to recreate their visual data. So why would they hold any possible economic value in the market, or feel special to their owners? Here is where digital identity can help us.
DIDs (decentralized identifiers) could be used to sign any assets created with the UAC, in this way we can distinguish which items were genuinely created by certain independent artists, brands, or random individuals. Copies and fakes are easily spotted. We likely can’t prevent knock-off copies, but we have an easy way to distinguish them from an authentic piece. This DID system we’ve described for signing assets, is also a very convenient tool in helping us avoid users of the Metaverse try to abuse the liberties we grant them when creating UAs.
Each virtual world that handles multiple users, will likely have a series of servers for their worlds, each server representing a different world-instance, potentially with different rules. These instances can impose rules on what UAs users are allowed to import, based on who has signed that specific asset. Some virtual worlds might dictate a subset of their servers to only allow users to import assets that are signed by that particular virtual world (meaning they were created or co-signed by that particular world-creator), a set of publicly trusted entities (such as other world-creators, trusted individuals, etc.). Or even allow any UA to be imported, or ban all UAs all together.
Each virtual world sets the rules of what they allow users to import into their world, but by default, all UAs that can be recognized by the virtual world and have been pre-programmed, are importable.
Final remarks
There’s a lot of careful thinking and design ahead of us, and we must have these discussions. The foundations of the Metaverse are being built today and will affect the future for decades to come. Once a set of standards is adopted, it’s very hard to change them for newer ones in the future.
Due to backwards compatibility and other motivations, we tend to drag old standards, past beyond their ideal life-span. If we adopt now a traditional set of standards that are rigid and convenient for world builders but not users, or useful in the short-term but without thinking of future-proofing them, we could end up with a dystopian or less than ideal Metaverse. Where you own nothing, and told you’ll be happy.
Let’s be responsible, ethical, and smart about this. Let’s lay a solid foundation for the Metaverse, a properly decentralized foundation upon which we can build, all together, maximizing the choices and options for everyone involved, not just a select few.
If you’re interested on learning more about this framework, please check out the remaining articles in this series:
