[Opensim-dev] Interrelated difficult problems related to asset portability

Kyle Hamilton aerowolf at gmail.com
Fri May 23 00:39:48 UTC 2008


The idea is basically an outgrowth of the "many eyes make bugs
shallow" concept... since viewers/clients are the ones that actually
get the data to display (assetservers stream to regionservers, which
stream to viewers), the viewers are the ones in the perfect position
to identify infringements.

If the same asset data shows up in two different places under two
different UUIDs, a client that has seen both will know it.  If
metadata is available for those UUIDs (including 'if you see a
duplicate, please send the UUID and the region you're connected to, as
well as the hashes that you know how to generate on the data, to this
URL' squawker addresses), then the client can simply notify all
squawker addresses associated with all the UUIDs and grid/locations of
the duplicate asset data.

Some of this will be licensed use.  Some will not be.  However, it
makes it possible for copyright owners to know where things are, and
determine if it's worth sending a C&D or filing a full lawsuit over.
(i.e., it makes it much more possible for the copyright owner to
determine when his/her rights have been infringed, which makes it
possible to use pre-DMCA copyright contours to litigate/enjoin/recover
from.)

It relies on code being put into the viewer.
It relies on code being put into the server.
It relies on additional fields being put into the inventoryserver.
It relies on modification of the asset-retrieval protocol.

It can't really happen without the cooperation of Linden, because
Linden writes and distributes the official viewer.  Most people don't
compile their own viewers, so the 'official' viewer (with the squawker
behavior compiled in) becomes the default, and when someone who uses
the official viewer goes to a private grid where there's a lot of
infringement going on it all comes out.

It also can't detect non-bit-perfect copies.  (unless, say, animation
data was parsed and then deparsed, and the hashing done on the
deparsed rendition of the data.  But that ignores the ideas of the
primitives and the textures involved.)  This is, by the by, why DRM is
very bad for this scheme -- if two people unwrap DRMed data via the
analog hole, it's not going to be a bit-perfect copy.

But regardless, there's additional things that can be done with this
idea -- such as Google or other content indexers, squawking on content
they see multiple times at multiple URIs.

And in any case, it's certainly a lot more than we've got now.

-Kyle H

On Thu, May 22, 2008 at 5:12 PM, dan miller <danbmil99 at yahoo.com> wrote:
>> Next, the problem of asset ownership.  DRM is a long, dark,
>> ugly road
>> to nowhere; however, this does not mean that nothing can be
>> done.  I have an idea
> ...
>> I'll be writing another email on this.
>
> do tell!
>
> -danx0r
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>



More information about the Opensim-dev mailing list