DECENTRALIZED VR SPEC

Chris asked me for some feedback on his Sanctuary decentralized VR design concept so I put together a rough outline/spec of one way to implement a decentralized VR world

CONSISTENCY (WORLD IS A GRID OF NAMECOIN ENTRIES STORING MODELS)

Imagine the VR world is on a grid and we give each block of the grid a name composed of a prefix for the world’s name and that grid point’s x and y coordinates e.g. name=”sanctuary”, x=1, y = 2 -> “sanctuary 1,2". When your client appears on the grid, it looks up nearby grid locations on namecoin and fetches the values for them. These containthe models(which could be values or torrent refs, etc) or belonging in those locations along with their position, orientation and scale data. The model data could also contain sets of small named JS programs for interaction — including a timer() for animation/simulation.

If a namecoin address is taken but its value isn’t valid, clients could ask grid neighboring points to vote (via an entry in their grid value) on a valid entry to use for the corrupt location.


RESOURCE MANAGEMENT (NAMECOIN LAND MARKET AND CONSTRAINTS)

Users can purchase and exchange land using existing namecoin markets. The client would ideally integrate a namecoin wallet so the UI can make this easy. We can also restrict the volume, complexity, and client cpu resources of the models in a given grid area to be proportional to the namecoin unspent outputs associated with the address.


LATENCY (CLIENTS SHARE AVATAR UPDATES OFF BLOCKCHAIN)

The large structures in the world can be stored in the namecoin grid entries as they don’t change frequently. You can imagine the structures in a grid location fading in as their confirmations in namecoin increase and their last version fading out like rezing and derezing in TRON.

But for smaller objects like avatars, we need fast updates so we have clients interconnect and share location updates (similar to how bitcoin nodes share transactions or bitmessage nodes share messages) with a policy of only keeping the latest update and removing them after a few minutes. If a grid entry references an authoritative node to talk directly to for fast updates from around it’s region, the client can connect to it for very low latency updates of avatars in that region.

An avatar update would consist of a structure containing:

1. the coordinates, orientation, and other parameters
2. reference to a namecoin entry for the username, the value at this address would contain the user’s avatar info and, to avoid spam, would have to have sufficient namecoin deposit (a proof-of-stake) or a recently done hashcash style proof-of-work.
3. a signed hash of the above data that verifies the owner of the identity published this update


IMPLEMENTATION (BROWSER WEBGL UI + LOCAL NODE.JS NODE)

I’d suggest writing a small node in a scripting language like node.js that would connect to other nodes to share updates and implement a minimal web server that would

1. return a single page webgl app for the VR world when requested by a local browser
2. handle socks connection namecoin requests from the app
3. handle a socks connection to receive and post avator updates
4. namecoin wallet and persistent cache if needed


USES

Content creation, exploration, and community — as it seems to be in minecraft.


ALTCOIN

This could also be implemented as an altcoin. However it’s done, I think it’s important that there be no gatekeepers or centralized authorities.

––
BY STEVE DEKORTE