Initial Manifesto for VRWorlds

Welcome to my VR-Worlds Architecture Discussion

This is a rambling discussion of architecture decisions and other stream-of-consciousness maunderings as I pursue this project.   I started doing this as a series of markdown files, and discovered that it was rather too stream-of-consciousness to make a good file or FAQ (my brain bounces around too much).

VRWorlds (A poor placeholder name) is an architecture for a sandboxed browser for a federated virtual reality environment, which utilizes a similar paradigm as the modern web does for VR.  The idea is that worlds, avatars and the things which exist inside of worlds (entities) are provided by servers out in the web --and utilizes modern web service calls to implement them. 

It's almost a VR operating system, but it's federated like the current web.  It's the absolute opposite of a walled garden.   It's not designed for gaming (though there's no reason it can't be a fine gaming platform).  I want a place for my stuff, and I want to be able to work there (cover every surface with monitors and have working keyboards).  Anybody that wants to deploy servers can supply entities or avatars, or indeed make their own worlds.   And these can interoperate without whatever rules the creators want to implement.  There's no overarching policy to constrain it beyond the security considerations built into the browser.

The system is wrapped with a very modern security layer (all communications must be ssl/https, utilizing certificates on both the client and server side).

I do have some rather unique opinions about privacy and CA verification.   There is no external bureaucracy.   Each security server is the top of it's own tree--self-signed and free (of cost).  It can verify that it owns it's own public key (by signing something for you).  Bob's server will always be Bob's server, and thus has a reputational value.  It's not anonymous---it has a perpetual handle.  You don't have to have a certificate chain above it to tie Bob to the real world, though it's acceptable to do that if you like by doing your certificate through a more conventional provider.

There are 4 service layers to provide content, and these can be woven together in whatever complexity is required.

• World Server - provide location, layout (levels/rooms, etc) and some of the physics for a world.   Worlds can be inside other worlds (imagine a Tardis sitting on a starship--The starship is a world, and inside the Tardis is another, though the outside of the tardis is an Entity).  
• Avatar Server - The body and movement of the first person.   This also presents your third person to someone else in a scene in a world with you.  Avatars can contain other entities.  You might even have a tardis in your pocket.
• Entity Server - Objects inside a world.  Entities are made of a prototype, and an instance.  The prototype contains the generic functionality of the Entity, and an instance customizes it, at least to the extent that it has a real location in a world.  (A third person Avatar acts as an Entity, as would an AI or NPC).   Entities can contain other entities, and be moved from world to world (depending on the rules of the entity or world).   Entities can also be owned by Avatars.  As above, entities can be nested.  This technicality is important, because some entities sort of leave the world when this occurs.
• Kudo Server - The security layer that wraps all of the other services.  It's called this because my original idea was around reputational credits (a bit like a type of coin, though these were not tradable), a Kudo - an award granted by some authority, like Sarah's Virtual Flying School, might grant a Level 2 Flying Certificate.   In any case, this idea expanded to a full-on security layer, which includes things like a CA, and possibly LDAP and OAUTH2 authentication (with two-factor).   In this I am trying to utilize as many conventional open-source libraries as possible.  It's a fool's game to think you can invent your own security apparatus, and not end up with a giant bag of fail which can be exploited a million ways.  I'm not sure this isn't inevitable even using known libraries and tools--but as least there's action when the latest openssl exploit lands and I could update.  If it was in my code, I'd likely never know.

There's no real constraint on what platforms or languages the server layers may utilize.  I'm so far, thinking of doing c# core microservices.  

And then there is the browser itself:

The initial version will be written in C# in Unity.  It is intended that this be an actual VR application (I have a Vive), in SteamVR, but I want people to be able to run this in a regular display with a game controller in hand.   On the Vive I want fully articulated Avatars which can use traditional controllers or the new hand tracking technology (I have a Leap Motion).

So, the secret sauce to all this, is how I intend to make the browser work.  I can't afford to make it so that random foreign programs run inside the Unity APIs.   So, instead the browser will support a series of V8 environments running javascript and later (as soon as viable) webassembly code.  I call these codebehind/entitylets, Emissaries.

Emissaries are contained in something like a jar or apk file which contains a signed manifest.  They have a code and a payload component which allows the module to be started inside of V8 and the payload section attaches itself as a read-only filesystem to that code so it can have data payloads.   Emissaries communicate with a corresponding server component in one of the above servers (each entity/world/avatar type has a UUID, as does each instance of one).  The inspiration for this is the pub/sub mini-mongo environment inside of the meteor framework.  The idea is that the emissary basically is the client for a complex 3d object.  Instead of interacting with a DOM, it interacts with something I call a 3DOM, which is mostly an attempt as a secure wrapper for Unity APIs.

Lots of other parts of this, but I think this is a good initial manifesto.