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

Fri May 23 08:01:28 UTC 2008

This is one of my personal pet subjects and my opinions do not necessarily reflect the general opinion of the realXtend team, so take this with a grain of salt. Except please don't excessive use of salt isn't good for your health.

I agree with you completely on the DRM stuff. I'm personally against most DRM c**p imposed upon us law abiding customers by software and media producers. Gone are the days when you would get an inferior product if you used pirate copies, thanks to the useless DRM schemes of today it's actually vice versa. There's also a problem or perhaps actually two to be solved that require some sort of DRM in the interoperable virtual worlds. First of all, selling virtual goods is alreay something of a notable business and we'd like it to stay that way and even grow, because it's in everyone's interest to see a constant flow of quality goods to the virtual market and the people creating them deserve and need to get paid. The other issue is content management for teen worlds; teens and kids are a huge user group for virtual worlds right now and in the future.

The one advantage we have that gives us a chance of creating a functional scheme is the network connection every user has. We don't have to try to prevent users from doing whatever they want offline (or rather it may not be as vital an issue as with music etc., but we may have to think about this as well at some point). This gives us opportunities for checking out the content on the server side as well as the client side and preventing the use of stuff the user doesn't have the rights for. Not to get into technical details at the moment (this is an interesting discussion, but at this level my expertise starts to run out), but for example content hashes and metadata could prove useful.

The other issue is content suitable for kids and teens. Virtual worlds are already getting bad press about this and it's a bit of a problem considering the potential user base. Making kid friendly areas would probably require globallly stored lists of stuff suitable for different uses (or rather a complex metadata system for objects that would have multiple uses) and some kind of systems for preventing unappropriate content from appearing on servers. Clients could of course have a parental lock as well.

I could go into details, but I'm not sure if this is a subject suitable for this mailing list so I tried to keep this short. Again, contact me if you're interested in further discussions or if you wish to continue here, it's fine by me. Personally I feel that this is a very interesting and important subject and also a pretty challenging one. In other words, irresistible.

Antti Ilomäki
antti.ilomaki at adminotech.com

________________________________________
Lähettäjä: opensim-dev-bounces at lists.berlios.de [opensim-dev-bounces at lists.berlios.de] käyttäjän Kyle Hamilton [aerowolf at gmail.com] puolesta
Lähetetty: 22. toukokuuta 2008 19:34
Vastaanottaja: opensim-dev at lists.berlios.de
Aihe: [Opensim-dev] Interrelated difficult problems related to asset    portability

There are a set of difficult (though I can't call them 'hard')
problems related to asset portability that need to be addressed.  Some
are explicitly technical, some are explicitly social, and some are in
between.

First, the problem of asset location.  If the UUID (LLUUID or
whatever) is going to remain the predominant asset identification
mechanism, and if UUID-identified assets can be located on different
machines, then there needs to be some means of locating the assets
identified.  I would look at a distributed hash table, with all the
asset servers participating.  I would not, however, simply allow for
any asset server to request any asset from any other asset server.

It's possible to design with the concept of 'assets are owned'.  See,
in any foreign-grid asset request, there are really two entities
represented by the one request.  First is the entity which has
authority to grant access (the user who owns the assets on their local
assetserver), second is the foreign assetserver (which manages the
assets for the foreign grid that it's connected to).  This leads me to
a question: why can't the foreign grid have its own OpenID?  If it
does, then it becomes a standard "trust delegation" issue -- "if you
log into this grid, you will give this grid access to your inventory.
(cancel) (cannot modify inventory) (can only add to inventory) (can
fully control inventory)".  That can be implemented on the asset
server as the basic SQL-like privileges -- Select, Insert,
Update/Delete.  (I like the 'can only add to inventory' concept for
being able to purchase stuff on a foreign grid.)

Then, the ID granted permission is stored in the local assetserver.
(Since the permission would (in this idea) be per-grid-per-user, the
foreign assetserver's OpenID could occur multiple times in the local
assetserver's foreign-permission table.)

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 for something that doesn't require any kind of secret to
be kept, doesn't require the computer to try to mediate access
decisions based on evidence of ownership or license to use, which
expects malice and can work even when all but one instance of one
component on the entire network is malicious, which provides much more
content protection within the classic contours of copyright law
(predating the DMCA) than any DRM scheme, and doesn't even need the
application of criminal sanction to punish violations.  I'll be
writing another email on this.

Following that, the problem of asset storage-on-creation.  I think the
'default assetserver' idea should be a per-avatar choice, and all
creation done on the default assetserver.  (More specifically, I think
that all regions should cache what they need on their local
assetservers, and the 'original' should be stored on the default
assetserver.  This way, if the avatar deletes the asset from the
region's scene, it can expire gracefully from that region's
assetserver.  If the avatar creates the asset and leaves it in the
region's scene, that region's assetserver will have a copy of it even
if the avatar never logs in again.  This can be implemented by
reference counts, if nothing else.)

Then the problem of asset caching policies.  Having an unreachable
texture just kinda sucks.

-Kyle H
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev