Some thoughts on asset storage, distribution and protection


#1

Content is the lifeblood of a virtual world. As yet, we don’t seem to have any concrete plans for exactly how assets will be stored and distributed whilst maintaining the highest possible levels of IP protection for content creators. I’ve been looking at a possible solution that I’d like to put up for discussion.

Distributed, decentralised storage and the blockchain

I started out looking at the possibility of managing IP rights using a blockchain, as there are a number of commentators (aka blockchainiacs) expounding the possibility of establishing an automated trust mechanism for the transferring of digital asset ownership. In addition, some of these systems are also capable of actually storing and distributing the assets in encrypted form [1].

Blockchain?

The blockchain is at the heart of BitCoin and other cryptocurrency systems. In essence, a blockchain is a public ledger that uses encryption techniques to keep track of who owns what. As far as I understand it, the blockchain system is pretty much incorruptible [2]. Whilst people may have heard about the huge losses by users of the mountGox BitCoin exchange in 2013, it’s very important to realise the fault was not with the underlying blockchain technology, but with security flaws in the mountGox website itself [3].

Decentralised, distributed and encrypted storage solutions like the blockchain would seem to fit the general HiFi model nicely, allowing users to ‘pay’ for services by offering resources (particularly storage) to the network. The scalability advantages of such systems makes them ideal for the task of asset distribution in a burgeoning virtual world - as the network gets larger, the system works more efficiently. This is of course the opposite case to centralised systems (e.g. a regular webserver or SL’s asset server) that have historicaly been shown to not scale well.

What's out there right now?

There are currently a number of decentralised, encrypted distributed storage solutions under development that apply blockchain technologies to applications other than the exchange of cryptocurrency. Whilst there are examples of blockchain based storage solutions (e.g. Storj), that store assets in encrypted form, there does not seem to have much development in the direction of digital rights management. I did find one exception - the BitCloud project [5].

BitCloud

Bitcloud is an open source, decentralized system that is similar in nature to blockchain based solutions. The difference is in the replacement of the blockchain with what’s being called a nodepool. The nodepool is a distributed relational, mutable database not dissimilar in it’s nature to the blockchain. The website lists a broad range of possible applications; Private Cloud Storage, Cryptocurrencies, Messaging Systems, Social Network Applications, Exchange Applications and Digital Content Platforms.

The BitCloud developers are currently in the process of building a proof of concept system on top of BitCloud to rival youtube, storing and distributing movie files in the decentralised database [4]. However, it must be pointed out that Bitcloud is not a mature technology and a lot of work is still needed. That said, I think the project could prove a serious contender for the role of HiFi’s asset storage and IP rights management system.

After end to end asset transfer: Asset baking

Whilst encrypted, decentralised asset databases might offer a secure means of asset storage and distribution, there is always the argument that if an asset can be displayed on a screen or can be heard though a soundcard, it can be replicated.

On reflection though, given the rich, composite nature of assets in HiFi, coupled with the fact that a HiFi avatar is, in one sense, a media broadcaster (please correct me if I have this wrong) it may be possible to obfuscate individual assets by only broadcasting asset composites, thus ‘tainting’ the original before broadcast. For example, a nicely looped dance animation might be tainted with input generated by hardware (Leap, Oculus). A texture on a t-shirt might be tainted because it’s diffuse, opacity and bump maps were pre-baked under the current lighting conditions before broadcast. In scenarios where music is being played, someone trying to record an audio track might find their recording is tainted by background noise - people’s voice chat, crickets in the background or the sound of waves lapping on the shore.

In this way, attempts could be made to ensure that the individual, encrypted assets are never transmitted unencrypted - the owning avatar’s client (i.e. Interface) would download assets in encrypted form, decrypt and then ‘taint’ them before transmitting the result. Whilst a hacked client could still be used to replicate un-tainted assets, tainting would prevent 3rd party avatars copying assets ‘seen’ on another avatar and would present another technical hurdle for any would be infringer.

After end to end asset transfer: Hash values

Finally, when a user uploads an asset, it's possible to generate a hash value / MD5 sum for the asset. This could be used to prevent a third party from uploading an identical copy by simply blocking or rejecting an upload if it's hash value matched that of an existing asset that is marked as 'owned'.

Conclusion

The kind of solutions I’m putting up for discussion here could prove quite effective in terms of decentralising HiFi’s asset storage requirements and providing another avenue for people to capitalise their spare storage / bandwidth whilst going some way towards protecting content creator’s IP rights. Looking at the current HiFi system architecture diagram, I think BitCloud storage and distribution system could be implemented almost entirely within the Contributed Devices block:

Thoughts?

  • davedub

[1] There’s a blockchain for that!
[2] Bitcoin: The security of transaction block chains
[3] The Inside Story of Mt. Gox, Bitcoin’s $460 Million Disaster
[4] Storj and the differences, a call for supporting Bitcloud
[5] The BitCloud Project


#2

I dont understand any of this. @KevinMThomas is working with the theory “who would steal the shit i make?”

I think what ever the security we use should be open source,
and I would like the option to host my creations on my own servers with the same security levels used in the rest of the world.
I noticed that @glenalec has started limiting his liability when he shares his privately hosted assets.
If at some point we have a market place a decentralized storage system makes ensuring an asset remains available a interesting problem


#3

A good protection is essential, but in the end the viewer will have to render assets anyway.

I see more in a protection which somehow protects against people doing copybotting and other bad things, then for the protection of the goods themselves,


#4

Yup, thats the best option.
And i dont understand how you can taint audio without making it hear always. Nothing more easy then plugging the line-out from the soundcard back to line-in So lost with that protection.


#5

Heh, I guess it does protect me from situations like this! :stuck_out_tongue: I was more concerned with protecting users of my free content from my habit of constantly going back and adjusting things (the maintainers of this board know what I am talking about!). If you like a particular version of an object, the vesion in my server may well have been altered away from the particular aspect you like a week later! (though generally the tweaks are around effeciency in textures/meshes as I learn new tricks, who knows what is of use/interest to people).

Back on topic, I agree that the security method should be and should support open-content. But it should also allow for closed-content too. I am not really into monetising my content, though, so don’t delve too deeply into this aspect - my content predominantly, so far at least, fails into categories of ‘generic and public domain’ and ‘too world-specific to be of serious interest to others’. Though a few things, such as my personal avatar appearance and the gross terrain of my world are things I would preferr to remain unique.

For my own use, an in-entity-properties link to a html document containing licencing terms would be sufficient (I would generally link up to the appropriate CreativeCommons licence varient). Maybe a no-copy flag that blocks people negligently walking off with stuff I want to restrict - if they really want it, they can get it, but just stopping people who random-click-and-copy oblivious of even the idea of licencing is useful at my own level.


#6

Avatars need to have top permission protection. Nothing worse then seeing yourself double. Well @chris knows how that feeled in high fidelity :slight_smile:


#7

Yes I have never left my personal domain in anything but the default robotoid head as I feel damned uncomfortable in a body that is distinctly someone else’s. Unless it is explicitly flagged as ‘generic’, like the robotoid or any other community-agreed generic, I feel like an imposter (and not the flat 64x64 pixel type).

(I have now - almost: can’t get the name plate to show up yet - got my own unique robot avatar. Personalising a generic humanoid or two to my own unique tastes is not far down the list.)

Avatars are very personal things for many people. As @Richardus said, reasonable guarentees of personal uniqueness is important in many situations!


#8

Putting link here to other topic where i have add links too other topics

https://alphas.highfidelity.io/t/talk-about-object-permissions/825