Commerce in High Fidelity

It’s been a while since I last looked at High Fidelity, however, there have been a number of developments on Philip Rosedale’s VR platform over the last several months, specifically related to the last HF subject I blogged about: currency and IP protection.

In August 2017, Rosedale wrote two blog posts on the company’s currency and IP protection roadmap, setting out plans to use a blockchain-based crypto-currency – the High Fidelity Coin (HFC). Since then, they’ve issued a series of blog posts tracking their ideas and developments towards building a blockchain centric currency / IP management capability.

For those unfamiliar with the concept, the attraction of blockchain systems is both their “openness” and their security. In short and simply put, a blockchain can be thought of as a completely decentralised database duplicated across the Internet, with the information held on it both immediately shared and reconciled across all instances of the database after any transaction, anywhere, any time. It is almost entirely self-managed, with nodes on the network of databases acting as “administrators” of the entire system.

All of this makes a blockchain environment transparent and exceptionally difficult to hack; it has no single point of data which can be corrupted, nor is it reliant on a single point of management for its continued existence. Thus, blockchain networks are considered both highly robust and very secure.

Following these initial posts, High Fidelity issued two further blog posts charting their steps towards building a blockchain based commerce system using the HFC as its crypto-currency, and which can provide a means of authenticating and a chain of ownership for valid digital goods (assets) within High Fidelity domains. These were:

  • A First Look at High Fidelity Commerce in Action, published in October 2018, demonstrating how their proposed approach, as a decentralised, independent service, would integrate into the shopping experience for people within High Fidelity domains.

  • An examination of their approach to handling worn assets (clothing / accessories), published at the start of November 2017. This included how worn assets would be technically managed (including allowing in-world / in-store demonstration / trial versions), and how the blockchain mechanism will not only handle the purchase of goods in HFCs, but provide certification of validly purchased goods which can be reviewed by any other user when examining the purchased item itself.

Then, in December 2017, the company launched a closed beta of Avatar Island, a shopping domain offering more than 300 avatar clothing and accessories from designers around the world for High Fidelity users to try in-world and, if they wish, purchase them. first environment within High Fidelity which starts to weave all of the threads from those earlier blog posts together into a whole.

Avatar Island is impressive on a number of levels, including the real-time, interactive ability to try on different items; the ability to resize accessories to fit, to share the shopping experience with a friend, etc. The items offered for sale within it are the first digital goods (assets) certified by HF’s Digital Asset Registry (DAR), a decentralised, publicly auditable blockchain ledger.

The DAR serves a number of functions: it uniquely identifies every digital asset on the system; it enables such goods to be  purchased with the High Fidelity Coin; and it serves as a record of transactions made by High Fidelity users. At its heart is the use of Proof of Provenance (PoP), which documents an asset’s chain of ownership, its characteristics, and its entire history, from certification onward. It’s a record which cannot be altered, deleted or denied, establishing an asset’s chain of ownership — its sale and resale — that sits entirely in the hands of the asset’s owner.

Furthermore, PoP can be used to authenticate digital assets in any High Fidelity domain – and even allow domain owners regulate the objects allowed into their virtual spaces (e.g. a restriction could be placed to only allow items in keeping with the theme of a space into it, or only allow items from approved vendors, etc.). Thus, DAR / PoP is potentially a powerful way of managing asset ownership, identification, purchase and use across High Fidelity’s distributed environment.

Since the start of February 2018, High Fidelity offers a means for users to pay one another in HFCs. Credit: High Fidelity

At the start of February 2018, the company announced they were launching the ability for users to pay one another directly in HFCs (so tips can be given to performers, etc.). To kick-start this, early adopters of High Fidelity (e.g. those who had signed-up and been involved in High Fidelity over the course of the last couple of years) have been awarded a range of HFC grants, made available through a server called the “BankofHighFidelity”.

Together, the HFC, DAR, PoP and the “BankofHighFidelity” provide a solid foundation for commerce within HF domains. Currently, there is no means to cash-out HFCs for fiat money, but given that High Fidelity is well aware of the powerful attraction of being able to do so (and allowing for regulatory adherence), it’s hard to imagine this would not be a part of the company’s plans.

As it is, the company has stated it plans to operate “BankofHighFidelity” as an exchange where HFCs can be exchanged for other crypto-currencies (I assume the likes of Ethereum and Gloebit) – a quite ambitious move in itself.

High Fidelity, approaching the second anniversary of its open beta, had laid down and impressive commerce roadmap for their environment with some impressive technical capabilities for “in-world” transactions and shopping. It’s not entirely clear how this approach might work a supply chain approach to commerce, something Linden Lab is attempting to build into Sansar, or even if High Fidelity is thinking along those lines.

Given these developments within High Fidelity and the fact that linden Lab are hoping to have their own approach to commerce in Sansar more firmly established later in 2018, – and allowing for the key differences between the two environments, it’ll be interesting to compare and contrast how each tackles commerce, digital rights, asset provenance, etc., down the road.

Advertisements

2018 UG updates #7/1: server, viewer

Thor's Land; Inara Pey, January 2018, on Flickr Thor’s Landblog post

Server Deployments

As usual, please refer to the server deployment thread for the latest updates.

  • There was no deployment to the Main (SLS) channel on Tuesday, February 13th, leaving it running on simulator version  18#18.01.17.511913. However, in keeping with the Lab’s policy of running channel restarts every 2 weeks, regardless of whether there was a deployment or not, the channel was restarted.
  • There will be no deployment to the RC channels on Wednesday, February 14th, and no restarts. All three will also remain on simulator version 18#18.01.17.511913.

SL Viewer

The Project Render project viewer was updated to version 5.1.1.512446 on Friday, February 9th, 2018. Otherwise, there have thus far been no changes to the SL viewer pipelines, leaving the current list as follows:

  • Current Release version  5.1.1.512121, dated January 26, promoted February 7 – formerly the Voice Maintenance RC – NEW.
  • Release channel cohorts:
    • Nalewka Maintenance viewer version 5.1.1.512226, January 31, 2018.
    • Media Update RC viewer version 5.1.1.512264,released January 30, 2018.
    • Voice RC viewer, version 5.1.1.512121, January 26
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Other Items

Region Restarts Causing Disconnects?

When a region is being shut-down / restarted, a 5-minute warning is given to encourage people to leave (or they’d be disconnected on shut-down). If everyone leaves ahead of the actual shut-down time, the region will wait for about 15 seconds and then go ahead and restart. However, there has been an issue some have experienced whereby if they are the last to leave a region that is shutting-down, they can teleport away, arrive at another location – but as soon as the original region is shut-down for restart, they are logged off (see BUG-5034). Linden Lab had thought this issue to have been resolved, so a new JIRA has been requested to allow for further investigations.

Region Crossings

Joe Magarac (animats) has been doing his best to investigate some region crossing issues, documenting his work via a forum thread. He’s now produced a basic document on his findings. Most of his work is around “patching” things – using a viewer-based RLV (or a permissioned base) approach to forcing an avatar resit on a vehicle post-crossing, if unseated, for example. The Lab’s view is that they would rather work more comprehensively as improving vehicle-related crossings than trying to patch things. The problem here is that region crossings are something of a 3-corner protocol issue (the viewer, the region an avatar / vehicle is departing, and the region the avatar / vehicle is entering), making improvements more difficult to achieve, as it is likely code on all three will at some point need to be revised.