Getting Started

Since the Metaverse is “the interconnection of virtual worlds” and these worlds often use native OS client applications, a key aspect of IPSME to allow for the interoperability and integration of native OS applications.

Native OS (macOS)

IPSME states that a readily available pubsub should be used as messaging environment (ME). On macOS, one candidate for the ME is the NSDistributedNotificationCenter (NSDNC), although Apple has been tightening security around its use. The objc-msgenv-NSDNC repository provides a wrapper for easily subscribing to and publishing messages.

Either start a new project and add the objc-msgenv-NSDNC repository, or possibly use example-objc-CLI-minimum as a boilerplate for a command line tool (don’t forget to init and update submodules).

When subscribing to the pubsub with a handler, messages from the ME will be received in the first parameter called id_msg (the second NSString* is unused). Messages * must * be strictly validated; those failing validation must be dropped.

void ipsme_handler_(id id_msg, NSString*) {
	NSLog(@"ipsme_handler_: [%@]", id_msg);
[IPSME_MsgEnv subscribe:ipsme_handler_];

When a message is published via the IPSME wrapper, it will also be received in the above handler; this is by design.

[IPSME_MsgEnv publish: ... ];

To control if the IPSME is working, the command line tool pub-NSDNC can be installed via the Store-of-stores in $IOI_BIN. Run your new application and instruct pub-NSDNC to publish a "Discovery" message to the local ME via:

$ pub-NSDNC 1 Discovery

The parameter ‘1’ tells pub-NSDNC to listen for messages after publishing the message. You should see the published message being received in your application. If you instruct your application to publish a message, it should be output by pub-NSDNC.

If the Store-of-stores is left open, message from it appear in the IPSME handlers.

It is in these messages that you insert the protocol you want to communicate. IPSME might not support every protocol type equally well (e.g., high performance streaming), but IPSME does not prohibit negotiating with a participant to communicate via other channels as well.

As of this writing, having more than one native OS application communicating via the IPSME library objc-msgenv-NSDNC on macOS is no different than just using NSDNC. NSDNC was designed to separate communication into different channels, where IPSME is designed to bridge communication. When applications speak disparate protocols and that is where IPSME specifies the use of translators.


If two applications are communicating via the same ME, but are speaking different protocols a translator used to bridge communication. Rather than re-engineer either of the two applications, a new service is created that listens to incoming messages of one protocol and pushing translated messages back to the ME.

Web Browser (WebBr)

In the browser (Firefox and Chrome are currently support), a readily available pubsub is that of BroadcastChannel; albeit each site has its own isolated broadcast channel.

Either start a new project and add the npm-msgenv-broadcastchannel library, or possibly use example-js-webbr-minimum as a boilerplate

Similar to macOS, a wrapper has been created around BroadcastChannel to simplify implementation according to IPSME.

function ipsme_handler_(msg) {
	console.log('ipsme_handler_: msg: ', msg);
IPSME_MsgEnv.publish( ... );

When publishing a message, the same message will be ricocheted back to the ipsme_handler_, as by design.

Messages sent to the ME are isolated from other environments, IPSME specifies that a reflector should be used to reflect messages to other MEs. It is entirely possible to reflect messages from the ME (BroadcastChannel) to another ME (perhaps online), but this largely depends on the systems being integrated.

Although it is technically possible to use IPSME between web pages, it isn’t advantageous to do so unless the protocol being communicated doesn’t fit within the already existing standard between web pages i.e., HTML.

BroadcastChannel to NSDNC

In order to integrate the browser environment with macOS applications, messages can be reflected, from the browser ME, to the ME (NSDNC) of the OS. The reflector endpoint for the browser is the SharedWorker npm-reflector-webbr-ws in the example-js-webbr-minimum project above.

sharedworker_reflector.load(window, "./reflector/reflector-bc-ws-client.js", function () {
	// initialization code ...

The other reflector endpoint connected to the macOS ME, is a service called reflector-ws-mac, which can be installed, via the Store-of-stores.

Once installed and configured messages from the web browser should be visible in the macOS applications i.e., with reflector-ws-mac running, the website can publish a message to its local ME (BroadcastChannel); with the message being reflected via reflector-ws to the macOS ME (NSDistributedNotificationCenter) and then to pub-NSDNC and the macOS project above, if running.

Likewise, messages from pub-NSDNC and the native macOS application will be received by the browser project.