Community Perspectives: What do game worlds and medicine have in common?

This post shares one member's perspective on how to address challenges in interoperability. If you have a story of your own to tell about your work within the open metaverse, we'd love to hear from you!

Using your same email account on different computers, on your desktop and on your phone, being able to make a call between different brands of phones, between different cellular operators, across countries … these are all examples of things that must operate across boundaries, in other words, that need to be interoperable. The Metaverse supercharges this requirement. As a wild example, imagine taking a character from your favourite movie, and porting them into your favourite game. Imagine seeing a dress your favourite actor is wearing and porting it into your favourite dress-up game, or trying it on in the mirror through your phone. Imagine taking a couch from the shop website and moving it into place in your home with your phone or a virtual reality headset. What about chatting with your favourite character on that couch wearing your beautiful dress, in your favourite game or virtual world, and then having friends from other virtual worlds join you there? And it all happens seamlessly.

This is a challenge for games, virtual worlds and the metaverse - hence the proliferation of metaverse standards groups, but it has been a challenge in many areas for a long time. OMI member Dr Kim Nevelsteen and Martin Wehlou M.D. faced this challenge in 2003 in the medical sector, when trying to achieve interoperability between various health care applications e.g., the hospital patient journal system and the software of specialist doctors.

Initiatives typically try to address the need for interoperability by attempting to force everyone to use the same thing, through a common set of standards, either existing ones or creating new ones. This doesn't work very well, because different implementations have different needs, people have egos, people work in isolation and develop differently, and then it is a huge cost - time, effort, resources, system downtime - to change to a common standard, and then, whose common standard gets chosen anyway? In addition, every time the protocols are updated, this re-engineering cost gets repeated.

Interoperability should not rely on standards

"Do not avoid standards. Avoid the need for standards. As soon as I see a project that says, we first have to decide on a standard … you're doomed"

-- Martin Wehlou, co-author of IPSME

Rather than aiming to create a set of standards for the medical industry, they considered a different approach, which Dr. Nevelsteen has now applied to the challenge of interoperability in the metaverse. An alternative order of events could be:

1. Decide what functionality the systems will share (e.g. for virtual worlds, the authorisation, ability to teleport, the avatar, several assets);
2. Have all participating systems create an API in their native language/system to allow for that functionality (this is the lowest cost option, in contrast to implementing the integration of standard protocol);
3. Decide where inefficiencies are and only then:
4. Decide on standards to take care of those inefficiencies.

This is the approach that Dr Kim Nevelsteen's IPSME specification follows. IPSME, which stands for Idempotent Publish/Subscribe Messaging Environment, states that integrations are external to the systems being integrated, which saves the cost of re-engineering and downtime when a protocol is updated. In other words, if integrations are external, each system must have an API in their native language/system with external translations that are updated when protocols change.

For example, Second Life has an API for login and teleporting in, but they do not have an API for importing an avatar or an asset; it must be done through their UI. The least cost for them would be to build an API (in whatever language) to the existing code base they have for importing an avatar/asset. It costs a lot more if there was a demand to conform to a particular protocol (e.g., requirement to support gLTF or VRM); they would have to build in that integration instead of just exposing an interface to the code they already have.

IPSME is the basis for a concept called the Industry of Integrations (IOI), where, when any two system interfaces (APIs) are known and accessible (via the conventions of IPSME), a translation can be created integrating the two APIs. If desired, that translation can then be monetized. The principle of IOI, underpinned by IPSME, is that creating integrations for the Metaverse could be a grassroots community endeavour, open to everyone in keeping with OMI principles, rather than being dictated by the large corporations.

IPSME has been a volunteer driven project since 2018, with its first scientific publication in July 2021. For the IPSME and the IOI to thrive and grow, it needs to find a host organisation and funding. If this interests you, please get in touch with with Dr Nevelsteen at knev@root-interface.se.

Further reading

IPSME was published to the scientific community in July 2021 and can be found here: https://dl.acm.org/doi/10.1145/3458307.3460966

A website with the conventions has been created and can be found here: https://ipsme.dev

Videos introducing IPSME: https://ipsme.dev/ipsme/0.1/introductions.html
Initial SDKs implementing IPSME on the various platforms can be found here: https://ipsme.dev/ipsme/0.1/repos.html

A YouTube playlist of all IPSME integrations can be found here, which includes the following highlights:

• Building up an IPSME eco-system from scratch
  -- Also warping from Web to native desktop apps:
• Warping from Minecraft to Doom3
• Linking (disparate) Minecraft servers
• Linking system without the need for collaboration
• Warping with Identity via IPSME
• Warping across devices

• Category: Blog