-
Notifications
You must be signed in to change notification settings - Fork 0
Home
The idea of the Stellar Mesh started in a Twitter thread from Stella Cannefax. A week later Stella, Robert Long, and Trevor Flowers started a Discord group to dig into the ideas.
Though there are almost infinite aspects to explore, this document is meant to convey the main ideas so that they can more easily be a part of the ongoing conversation about the future of XR, the web, and life in general.
The Stellar Mesh is not meant to replace web browsers. It does give web browsers a break from trying to be everything to everyone, though.
The main idea is to take the concept of dynamically fetched and runnable experiences (like the web's pages) and implement it in an XR-specific way that leverages excellent new technologies like WebXR, WebAudio, WebAssembly, WebGPU, stand-alone VR headsets, and AR glasses.
Like web pages and unlike native apps, Stellar Mesh experiences don't leave behind detritus when you stop using them. You don't "install Stellar Mesh apps", you have Stellar Mesh experiences.
A Stellar Mesh implementation is much less complex than a spatial web browser like Firefox Reality or the Oculus Browser because instead of one huge web engine for everything (wikis, social media, immersive games, video editors, etc) the Stellar Mesh provides sandboxes with basic APIs and then relies on a variety of dynamically fetched engines for different uses.
Small teams can implement a Stellar Mesh application. Engines can evolve separately and quickly without getting the "OK" from hyperorgs that control the One True Engine.
Example engines:
- OpenStreetMaps
- Unity renderer
- Croquet collaboration
- Godot renderer
- Babylon scene graph
- Perhaps even a W3C document engine!
You could give a Stellar Mesh application (your "node") running on your VR headset (your "rig") the URL to an immersive experience (a "runnable") that is a flight simulator. That runnable would declare (in code) that it wants to run with the OpenStreetMap engine. The node would then fetch the bundles for both the engine and the runnable and then load them in a secured sandbox. That sandbox would provide access (with your permission) to basic APIs (GPU, audio, network, etc) instead of high-level document APIs like the DOM.
A Wikipedia runnable could load a document-oriented engine.
A Fortnite runnable could load an Unreal Engine.
A social space runnable could load a Facebook Horizon engine.
If you'd like to read more then your next stop should be Definitions where all of the major moving pieces are named and defined.