API Layers

Cranking up the old Visio again...

Ogres are like onions, because they have lots of layers...

If you see the crazy number of empty projects I've been checking in, you'll see now what I intended.   This drawing was also to give myself some more clarity of what I was just randomly creating as I saw a need.   Now the thing this doesn't show is what APIs (or parts of APIs) are implemented where.  I will work on this part next, so I can start to get a full skeleton of what the API trees are going to need to contain.

I also saw the need as I was writing for a provisioning API (how many servers are where--mostly interacting with the Data Plane and the Orchestration (though their data is stored in etcd).   Also most of the server types will initially need a conventional web page for signing up and utilizing.  Someday that will all get done in VR.  Ultimately there will be some kind of Dashboard -- again someday visualized in VR.  For now, I'll find some conventional monitoring tool.

I also like that I've have some good structure happening on the browser.  I think that I know how that's supposed to be built.   Also, I've mostly figured out out how its Control/Data Plane is going to work (ProtoBufs over Named Pipes--though I wish I could just use gRPC).   I also had an amusing idea--no real reason Named Pipes wouldn't work across multiple machines if you want to turbo-charge your browser.  Though also should allow conventional sockets so your browser-assist can come from a Linux box.  Also probably should consider building a Unity Linux VR browser, so need to be agnostic on this part of the infrastructure.  I could make co-processor boxes that you attach to your regular machine.

Anyway.  Little steps happening in the background.

Next Steps After Emissary Builder - Microservice Stubs

So, have been proceeding with next steps after the Emissary Builder is prototyped.   I've decided that the server/browser communication will proceed with C# .NET Core MicroServices running GRPC utilizing the Flatbuffers serialization layer.  I've been working on figure out how to do this and how to build using these parts.   I'm assuming that the microservices will be ASP.NET Core, but I'm not entirely sure yet. 

So now, I'm starting to break down the functionality so I can start to get a handle on the MicroService boundaries, and how to create the authentication and eventually build all of the Flatbuffers contracts and RPC calls. 

I will need to start working on the emissaries themselves.  I'm thinking of doing that in TypeScript or possibly in Rust or Go in Webassembly (really, WASI).   I really am not sure about the state of C# webassembly, blazor notwithstanding.

I have to restructure my 3DOM library, which is where all my current active code is.  It needs to be strategically split into pieces, but I'm not sure where the edges are yet.  I'm trying to avoid monoliths.

Here's my brainstorm of the various services I know offhand I might need.  I'm sure there are many more, however, these are the main published services.   Each World, Avatar, and Entity can create its own layer of custom gRPC calls to handle the provisioning and operation of each emissary and they must remain dynamic.

I think--Stage 1 Hello World--will consist of all 4 servers working with their Ping servers.   Though that's not really how the use-case goes. 

Ultimately the completed startup is more like this:

• Browser asks Avatar server where Avatar's Kudo Server is
• Browser logs into Avatar and Aspect
• Avatar's Emissary is Marshaled
• Browser connects to world that Avatar wants to materialize in
• Browser asks world's Kudo server to grant permission (based on Visa or open permission)
• World's Emissary is Marshaled
• World then emits the inventory for the scene
• Entities from everywhere begin to Marshal their Emissaries
• World causes the Avatar to materialize in the designated position in the Scene

But, we have to get there incrementally.  Server skeletons first, then ping.   Enough of a microservice that we can get this running in a Kubernetes Cluster, or at least in Docker on one machine. 

Boy, that was ramble...

Tentative Services

Kudo Server

• Ping
• Locate Worlds
• Locate Avatar Service
• Locate Entity Service
• Vouch Self
• Vouch Service
• Vouch CA
• Validate Login Ticket
• Sign [Developer]
• Login from Server [Server]
• Login from Avatar [Avatar]
• Banking Transactions

Kudos:

• Vouch for Kudo
• Generate Kudo
• Transfer Kudo
• Revoke Kudo
• Manipulate Values in Kudo

Standard Kudos:

• Deed
• Lease
• Visa
• Access Grant
• Ban
• World Level
• World Coin

Avatar Server

• Ping
• Locate Kudo Route
• Vouch Self
• Marshal Avatar (As Primary Avatar)
• Marshal Entity (Avatar as Entity)
• Transform Aspect
• Manage Active Inventory
• Transfer Entities Into/From

World Server

• Ping
• Locate Kudo Route
• Vouch Self
• Log Avatar In
• Marshal World
• Unveil Scene Inventory/State
• Marshal Entity (World as Entity)
• Transfer Entities Into/From

Entity Server

• Ping
• Locate Kudo Route
• Vouch Self
• Marshal Entity
• Transfer Entity
• Transfer Entities Into/From
• Instantiate Entity Into

Client/Server Protocols

I've been thinking for a while about how server/client communication will need to occur in several different directions.

This front-facing use-cases are the APIs to the various servers (Kudo, World, Entity, Avatar), and have thought that these need to be rather high-performance.   I've been looking to newer alternatives to json and xml and all of the old paradigms for web-api serialization, so I've been looking at things like Protocol Buffers, Cap'n Proto, and FlatBuffers.   The first and third are Google supported.  I'm also interested in the meta level of having an RPC layer like gRpc, and this supposedly can use ProtoBuffs and FlatBuffers.  Cap'n Proto also has an RPC functionality (though not that I can see for c#).

Many of the API calling code will be built into the browser and so interfaces would be totally static (though versioned probably).

The other big client-server interaction is between servers and the Emissaries...   Much of the design of this architecture is inspired by the DDP model in the Meteor Framework.   However, I think the kind of information that gets synchronized between the server and the Emissary is a little different.   Simply doing a two way reactive subscription to a chunk of a Mongo collection isn't the best model for the Emissary.   Reactivity: yes, Synchronization: yes, but the data is more specialized. 

And, for the Emissary, most of these protocols have a schema language and generates classes that you use in the tool-chain to build the emissary.  These can't be compiled into the browser, and so have to run in the Emissary code with probably some high level communication -- perhaps passing the websocket handle down to the code.   So, likely there will be some specific hooks in the APIs for this code.

I'm still looking for a sync model I like, though due to the nature of the way the Emissary is setup, you really can roll your own if you like as long as the API is giving you enough rope for you to pull on.  And this is obviously one of those points where security is vital.  I think the idea was that the browser would set up the secured channel, and then the emissary can do what it needs.

I'm getting to the point where I need Hello-World functionality from all of the basic servers, so I need to get the infrastructure ready to go.   I need some very basic functionality from them as well.  I need World to get me an inventory, then I need to marshal all those entities from an entity server.  I can skip some of the security stuff in the Kudo server, but I'd like the Cert Chain for the Emissaries to be checked (right now, it will simply accept the cert I give it -- it has to be signed, but it makes no checks to verify who signer is and that the cert chain goes back to the Manufacturer Guid (and that the signer is authorized to sign for it)).

I'm also thinking I may need a "Server Common" project.   Simple "Common" might include stuff that the browser doesn't really need.

No Inherent Game or Movie Tropes

There are lots of tropes in games and in VR stories/movies that are designed to increase tension or add conflict to the story. 

• Your character can be killed.   Most games after you die you can respawn, with varying levels of penalty.  An extreme version of this is in 'Ready Player One', once you die, your character is dead forever.
• You lose your possessions when you die.  Sometimes they just get dumped there, or they might disappear.
• You have limits on what you can carry.
• You can only be in one game at a time.

It's possible to build games and have worlds where some of these things might happen within the confines of that world.  However, there are some basics which VRWorlds will enforce.

1.  There are two special types of certificates (special kudos), leases and deeds, which either give permanent or time-based access to Entities.   Avatars can only be deeded.   With deeds -- you own them.  Nothing that happens in any world will affect your ownership, or possession, of the object.   All this being said, your Avatar cannot die or be taken from you.   The only thing that can occur is that the original Entity or Avatar creator/provider can withdraw from the universe and take it's servers and your items with you.

2.  The rules about what you can lease or own are between you and the Entity server.  It may be that the Entity server allows you to own anything you pick up.  It may permit you to purchase/lease the item.   It also might be that the server won't let you take anything out of the world, but you will have it in your possession as long as you are in the world.  Items which you have deeds or leases for are yours and they cannot be taken from you, or even hidden from you.  They are in Active Inventory, even if you are not carrying them--you can call them back to you.

3.  There is no real limit on what you can carry of your own items.  A world might enforce carrying limits of world objects, but this cannot affect your objects.

4.  Worlds might not permit some of your objects to be used.  The Fluffy Bunny World might not permit you to use your 100 megaton nuclear hand-grenade, or they might.   Entities and Worlds have to cooperate on this.  There would have to be interlocked kudos to allow gameplay with interworld items.   I don't think third party worlds would want to trust self-declared attributes on a Entity from another service, but the world's physics engine would have to cooperate if an Entity wanted to explode, or shoot projectiles or otherwise be a weapon.  Your Avatar would have to agree to take damage, and there's no reason for it to even have a mechanism to do that, except for the purposes of gameplay.

5. There's no reason why your Avatar, at least notionally, can't be in multiple worlds at a time.  Now practically you can only function in one at time, but consider the analogy of having lots of tabs open in your web browser.   How you switch around, or get informed of interesting things happening in a given world are TBD, as is if your avatar will just stand there, or get ghosted out, or perform some activity via an AI.

6.  Kudo's are awards that are granted by worlds, or external groups (though I guess that can be a group of one Avatar).  They are a type of unreassignable crypto-coin.  Kudo's can be granted to avatars, worlds, entities (either the whole class of an entity, or individual instances), and so are owned by these objects.   Third parties cannot affect them, though the original grantor can revoke them.

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.