Metaverse map

Via IPSME it is possible to query the eco-system. Interesting information to query for could include what Metaverse experiences exist, metrics about the experience (user count, etc), what protocols it supports, etc. This guide aims to show you how to setup an IPSME participant so that a Metaverse experience can be discovered. The information being discovered can be offered by each Metaverse experience or crowd-sourced through the user choosing (read: Empowering the User) to add support for experiences to their local IPSME environement.

Terminology

Eco-system: the collection of all participants that can communicate via IPSME.
Metaverse experience: some subverse, world or virtual environment to be added to the Metaverse.
Participant: a running process tha that communicates via IPSME and/or possibly a Metaverse experience.
Local: Directly communicating via IPSME without the need for the user to actively start reflectors that network beyond the local machine.
Remote: IPSME communication is over reflectors which communicate with participants over the network beyond the local machine.

Being a Discovered

There are basically two scenarios for how a Metaverse experience can be discovered via IPSME, a local participant or remote participant. In each of those scenarios, we have two cases: where the Metaverse experience has an existing API and where it does not.

Lots of Metaverse experiences exist that either don’t report information about their service or already have an existing — but non-standard — API through which they report information about their service. Note, there is currently no standard for querying information from an experience. An API could be a web page that has data posted or perhaps a REST interface that can be called to query information.

Local Participant

No API — If no API is available for a particular experience a local translator can be made to reply directly on behalf of the experience; in other words, an IPSME participant is added to the local ME which replies to queries about a particular experience. Through IPSME anyone can make a local translator for a particular service, provided the they know the API. It is the user’s choice as to whether install such a translator, but care must be taken that only reputable translations are installed to avoid spoofing.

The trivial-discovered::index.adoc repository contains an example of a translator that accepts messages via IPSME and responds to the Discovery Protocol. When a Discovery message is validated and accepted, then the example can just publish the appropriate response message on behalf of the service to be discovered. In this particular example, the translator is implemented in c++ and uses the sdbus implementation of IPSME for Linux. If trivial-discovered::index.adoc is to be run locally on, for example macOS, then it could be implemented in Swift/Objective-C and make use of the NSDNC implementation of IPSME; conceptually it stays the same.

Summary

Change trivial-discovered to respond to the local IPSME.
Change trivial-discovered to directly respond to the Discovery protocol with information about the experience.
Run the subverse-map and the experience should appear on the map.

Existing API — In the trivial-discovered::index.adoc example, the code does not actually immediately respond with informationa about an experience, but instead makes a call to a GraphQL server. This call can be replaced with a call to any existing API a Metaverse experience might have e.g., REST, web page, etc. The response needs to be translated from the native API format to the appropriate Discovery protocol response format and published via IPSME.

Summary

Change trivial-discovered to respond to the local IPSME.
Change trivial-discovered to call the experience’s API; translate the API response to the Discovery protocol and respond.
Run the subverse-map and the experience should appear on the map.

Remote Participant

No API — With local translators, a user is empowered to select the integrations they want. However, owners of each Metaverse experience can decide to make it easier for users by supporting IPSME and the Discovery protocol(s) themselves. In the case where the Metaverse experience doesn’t already have an API, a participant in the remote ME can respond natively to the Discovery protocol. This means running something similar to trivial-discovered::index.adoc next to the Metaverse experience, which responds to discovery. What is required additionally is then a way for the IPSME environment local to the users to find each Metaverse experience; this can be achieved through a discovery service. The example code registers itself with a discovery service on start and again towards the end of the registration expiration period.

Summary

Change trivial-discovered to respond to the remote IPSME; remote to the user, but local to the Metaverse experience.
Change trivial-discovered to directly respond to the Discovery protocol with information about the experience.
trivial-discovered should register itself with the discovery service.
Run a remote reflector server connected to and reflecting messages to the remote ME.
Run the appropriate reflector local to the user, that can connect to the remote reflector server.
(optionally) publish messages to the local ME and see if they are reflected to the remote ME.
Run the subverse-map and the experience should appear on the map.

Existing API — If the Metaverse experience does have an existing API, an owner can run something similar to trivial-discovered::index.adoc, where the service responds to discovery by first querying the API and then translating the results into the format understood by the Discovery protocol. Using IPSME, translators are external to the systems being intergrating allowing for translators to be added and updated dynamically. Also in this case, a discovery service is required so that the local IPSME environment of the user can find the remote IPSME environment of the Metaverse experience.

Summary

Change trivial-discovered to respond to the remote IPSME; remote to the user, but local to the Metaverse experience.
Change trivial-discovered to call the experience’s API; translate the API response to the Discovery protocol and respond.
trivial-discovered should register itself with the discovery service.
Run a remote reflector server connected to and reflecting messages to the remote ME.
Run the appropriate reflector local to the user, that can connect to the remote reflector server.
(optionally) publish messages to the local ME and see if they are reflected to the remote ME.
Run the subverse-map and the experience should appear on the map.

Discovery

Discovery Protocol

IPSME doesn’t require standardized protocols and so the Discovery Protocol is a non-standard protocol to discovery Metaverse services. It is designed to support participant announcements and the subverse map. The protocol is very basic at this point, but can be expanded on as more information about each Metaverse experience becomes relevant.

Discovery Service

For this project, I have implemented a basic discovery-svc::index.adoc. In no way does this keep other discovery services from being used. Anyone can start a discovery service and each service could be provided to user, so that they can choose between them. It is also possible for a meta discovery service to aggregate services.

Reflectors

IPSME stipulates that two different messaging environments are to be connected via reflectors. This means that once a site is discovered via a discovery service, a reflector connection must be made from the local ME to the remote ME.

Local

To increase compatibility with other platforms, a user can choose to install reflectors that support these other platforms. One such reflector currently available is reflector-NSDNC-tcp::index.adoc for macOS, which reflects messages over tcp.

Remote

For the remote reflector server, a list of reflector server implementations can be found on the IPSME website https://ipsme.dev/ipsme/0.1/repos.html#_reflectors. If the desired OS and/or programming language is not listed, then a project can be ported.

Subverse-map

Anyone can create a map of the Metaverse using the information in the IPSME eco-system; in other words, once an experience reports information via IPSME it is available to all that understand the response protocol. A protocol map has been implemented as a demo app, app-subverse-map::index.adoc.