Sandboxing Metaview Applications

Foreign code execution

A part of the design of metaview is the ability to execute foreign code. This will enable developers to create interactive experiences within metaview. Essentially, developers need to be able to access APIs to interact with the instance the user is currently in, eg. spawning new models, handling player interaction, communicating with other users within the instance.

One must keep in mind, though, that executing arbitrary code is very dangerous from a security standpoint, unless done correctly. The World Wide Web browsers face the same problem -- creating a platform for interactivity while perserving its security.

The Web platform provides two solutions; JavaScript and WebAssembly. WebAssembly (WASM) seems like the perfect candidate for metaview, there are many obvious advantages of using WASM over JavaScript, including its efficiency and speed, which is a requirement for VR/AR environments, where a low response time is a necessity. The main advantage of using WebAssembly is its focus on safety. The language is, by design, built to be easily run in a sandboxed environment, efficiently.

The API

WASM does not necessarily have to run in a web-based environment in conjuction with JavaScript and there are efforts to make WASM work with different APIs. Where a Web-based API would, for example, provide ways to interact with the DOM of a website, as well as access to networking utilities, the metaview API would have to facilitate the following:

I suspect the APIs would in the end not be too dissimilar, but there are some specifics that need to be addressed when working with decentralized networks and VR/AR 3D rendering, as opposed to 2D web pages.

It would be preferrable to separate most functionality of the API (like cryptography) into a shared WASM library, if possible. That way, the API surface could be minimized, reducing the maintenance cost and the potential for security vulnerabilities.

Additionally, it would be desirable if applications could utilize concurrency, so it could, for example, run one thread to handle physics interactions of entities and another thread to handle hardware events like button presses. Unfortunately, the standardization of multithreading in WASM is still underway.