An open metaverse is possible by growing the graph of capabilities and connections between systems. The network directly or indirectly enhances the capabilities of the other systems. I also elaborate on how to expand this graph to make it happen.

https://streamable.com/e/xg6tud?display=iframe

In this article I will examine the phenomenon of metaverse transitivity and what it means ,if we are aware of it, for the idea of the open metaverse. The main motivation is that that we don't need all encompassing systems that can load and do everything by themselves. That is uneconomical and utopic. Links between systems can provide inter system paths to achieve things across systems. The graph of connections composes a sustainable and achievable effort.

The video illustrates scene data going through three systems. From the user's perspective a given system can compose with other systems in some way by means of other intermediate systems that have at least unidirectional links. The subjects of this can be complete scenes, models, metadata, messages, video streams, input methods and anything else.

• APIs

• Importers

• Exporters

• Tools

• Common formats

• Culture (shared users)

If any of the first five are missing, the most important aspect is the Culture. Shared users are capable of figuring out ways to recreate data, create bespoke ways to import/export data, create bots, reverse engineer and even make hacks to do what they want. This is not a technical phenomenon, it's a cultural aspect of people being people and reproducing the things they like.

A user wants to make a VR painting like Tiltbrush in Webaverse but there are no built in tools for that. Webaverse can import gltf. There's a web tool called A-Painter that let's the user make a VR painting. Exporting from A-Painter into Webaverse works because there's a shared file format. There's nothing special about this.

Like in the previous case, the user wants to add a VR painting, however A-Painter doesn't support animating an exported model. If a third system would be able to take A-Painter's export, let the user puppeteer or animate in some form the model or scene, and then generate a new GLTF that could be loaded in Hubs, then by transitivity Hubs can do more than before from the point of view of the user.

Loading a VRChat scene in Unity, and then using the JanusXR exporter, by extension JanusXR can run an interpretation of the VRChat scene. Both the exporter and JanusXR might support a subset of VRChat features but the link is there.

If a system A has special cameras with special effects, like 360, stereo, depth, etc., and it can also load a scene from system B which doesn't support such camera, then moving the scene to system A makes sense for such features. System A also benefits from the scene making tools in system B that might be better.

• System X lets users paint on meshes.

• System Y lets users use Stable Diffusion to generate textures.

• System Z has an API that provides metadata about editable zones and their properties.

• System W can let users animate a mesh by puppeteering.

• System Q can turn Z's API to build a scene with placeholders and imported meshes, and export it as a GLTF or a JSON scene.

• Mozilla Hubs can load a GLTF in a scene.

The sum of these systems usually linked by compatible file formats and an instance of an API, is greater than the sum of the parts. The combination can be expressed as a room with portals to each tool as a way of documenting the workflow but it's not necessary.

If System A supports VR but System B doesn't yet, but a scene or elements of it can be loaded on system A, then a part of B becomes capable of VR indirectly. Same can be said of any other specific hardware features like giving ARKit support to a scene in a system for PC, and so on. A capable system can enable capabilities of another.

Smaller sites that can at least compose with another site can form a graph and users can create workflows by walking through this graph. Smaller tools are more economical and can be made for a very specific purpose. Just paint on meshes, just upscale textures, just help with UVs, etc. Micro tools that can connect in some way to another forming a web that supports an open metaverse. Identifying missing links and building micro tools to bridge graphs can expand the potential of each platform.

Forgotten formats can be revived by a single bespoke tool that turns them into something that one of the systems can load and then export or share with other systems. Systems that are powerful but hard to build into can be made easier by loading from a system that makes building enjoyable or familiar. It's about bridging.

Every system will interpret things a bit differently and that's fine. Almost nothing about this idea is about automation or automatic service discovery or any of those software architecture fantasies. This is about people more so than computers talking to each other.

By fostering links between projects (financially or donating time with open source) with importers and exporters, documenting data formats and reverse engineering missing or defunct systems, we can have a truly compatible metaverse with no single point of failure.

Specialization. Offer the things that you can do best. Some platforms will be better at avatars, some will be better at VR, some will excel at tabletop AR, and so on. The open metaverse becomes viable when we have transitivity. When we think about the graphs taking shape and how people are traversing them to make workflows teaches us more about each system. Identifying the weak links and making new microtools to empower the whole graph. Bridging web tools with native tools, bringing in forgotten or hard to deal formats. Avoiding the duplication of effort.

Open formats like GLTF offer primitives to bridge assets. GLTF extensions could prove interesting to preserve metadata and behaviors between systems, including graceful degradation when behaviors are not present.

Users who use more than one system may want to reuse what they build, or share it with people in other systems. They can also take advantage of building tools that one system has that the others don't. From scripting capabilities to graphics and VR, to gameplay features or social interactions. I think of culture as things that people like to repeat. On each repetition things might change and others might stay the same. Portable culture can survive the death of any one system, moving along the open metaverse graph. Even closed systems might die gracefully by allowing users to take their worlds with them to other open systems. The graph is a safety net for cultures that express themselves in these related systems. It's about people building and rebuilding their cultures.

If we are aware of the graph, we can identify where we could have the most impact as developers or supporters. The right weekend project in the right place can make all the difference in the open metaverse. The power to connect communities and succeed is in our hands. If only one system figures out how to load and deal with some type of data, then all the other (culturally more than technically) connected systems can too.

twitter: @Avirtualfuture

farcaster: https://farcaster.xyz/avirtualfuture

I'll write more about these ideas and practical implementations in the future.

Remember to collect this article and subscribe. A series of quality articles is in the pipeline.