I’ve been trying to keep an eye on High Fidelity of late, particularly since things like the SVVR meet-up in March and VWBPE 2014 in April, both of which featured presentations / talks by Philip Rosedale. However, I missed a recent blog post on the High Fidelity site, so my thanks to Nalates Urriah for giving a heads-up about it.

One of the things that has caused people some consternation with high Fidelity is that while there have been various demonstrations and some talk about it using distributed computing (a-la Seti@Home) as an operating model, more precise information on the architecture for High Fidelity has been lacking.

The official blog post, dated Thursday April 24th, goes some way towards rectifying this, by providing a high-level system diagram for High Fidelity and providing some additional notes on the various aspects of how it is hoped the system will work.

High Fidelity won’t, as they’ve previously made clear, be providing a virtual word per se. Rather, they are seeking to provide the software and protocols which will allow others to create virtual worlds and connect to one another, and the means for uses to connect to, and move between these worlds as they become available. The idea here is that by providing the means to create fully distributable virtual worlds, harnessing shared computing devices to scale their content and load, thus theoretically making a scalable, global virtual environment with shared resources through which users can travel.

The top section of the diagram denotes those services where High Fidelity hope to generate revenue.

The Nameserver allows virtual world domains to be uniquely identified if the owners wish (think DNS) – so that, as a totally hypothetical example, @secondlife could be registered to allow users to quickly discover and access Second Life. The registration service for virtual worlds is optional, rather than required. This service can also supply authentication mechanisms which can be used to both restrict access to a virtual world or allow users a particular virtual world to securely disclose chosen aspects of their identity.

The Digital Marketplace is fairly self-explanatory, allowing people to buy, sell and transfer digital goods to and from each other, and move these goods among different virtual worlds.

The Currency Server provides the wallet services and other API’s needed to allow people to quickly and easily share their computing devices as well as buy and sell digital goods using a cryptocurrency. Whether the latter will be a recognised cryptocurrency (such as Bitcoin) or something new, remains to be seen.

The Assignment Server, allows people to share their computers with each other to act as servers or as scripted interactive content. It monitors and analyses devices which are made available as servers in order to try to assign them suitable tasks – so that a mobile ‘phone offered as a server might be used to control a scripted agent such as a dog wandering around a virtual world, while a high-end PC might be assigned more intensive tasks. This Assignment Server will also oversee the transfer of cryptocurrency between users, so that those providing their systems to help run a world are compensated by those making use of their computing capabilities to run their world.

Another core aspect of the system, which has been covered in various commentaries on High Fidelity, is the use of voxels, and more particularly, the voxel server, which stores and serves the content that is found inside the virtual world. Voxels can be nested within one another, or averaged together, allowing for significant levels of detail to be achieved over distances than is otherwise possible. The voxel server allows elements within a world to be distributed across multiple servers, so for example, an apartment block in a cityscape could comprise apartments which are each running on their own server.

The Voxel Server, together with the remaining elements of the software (the Domain Server which sits at the heart of any virtual world using the software and protocols, the Audio Mixer, Avatar Mixer, Interactive Client, etc.), are available under the Apache 2.0 open-source licence, Further information on them can be found in the High Fidelity blog post, and they can be downloaded from High Fidelity by those who wish to play with them.

The post has drawn a fair number of comments and questions, and as Nalates points-out, they make further interesting reading – particularly Philip Rosedale’s replies (or where some questions are concerned, lack of a reply).