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

[Kyle Hamilton]

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