[Opensim-dev] Global identifiers

Tue Aug 31 14:21:08 UTC 2010

Hi, Malenie, thanks for the reply. I do see some issues being touched on in
1.5 should consider this, namely what external identifiers you are attaching
to content, but understand.

M.

-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie
Sent: Tuesday, August 31, 2010 10:00 AM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Global identifiers

Hi,

at the moment, we're completing HG 1.5. Your concerns are valid and
are part of the discussions I have had with Diva about HG 2.0.

We are aware that HG 1.5 is not content safe. It still requires open
access asset servers and has no access controls whatsoever.

The concerns addressed in this discussion are not relevant to your
points.

Generally, whenever an object is taken across the HG, the asset is
copied. This is required for performance reasons. Content controls
will be limited due to the globally displayable nature of assets.

What HG 2.0 will address is the designation of "trusted" grids you
will allow your content to be taken to, and "grid locked" items
which are never allowed out of the grid they were obtained in.

>From this follows that avatars will have a grid local inventory, a
global inventory, and possibly other inventories.

In HG 2.0, your asset server can be yours and will act as an
upstream, delivering assets to the destinations you control. You
have to ensure, contractually, that those sources copy it only to
the degree it needs to be copied to ensure operation and that they
don't pass it to anyone to copy again.

It is not possible to have your asset pulled from your server for
each use. Although viewers would have that ability in the future,
exposing a free for all asset server is asking for trouble,
therefore DRM'd assets need to be proxied by a grid you trust.

There are complex technical considerations that we are looking at,
as well as the legal implications and the ability to have effective
DRM. This will all happen in HG 2.0.

At this point, HG 1.5 is not, and will not be, fit for commerce.

Melanie

mysticaldemina at xrgrid.com wrote:
> Hi,
> 
> As a content creator this concerns me.  I believe if I license my content
to
> an avatar, and then they go to another grid that any content pulled should
> be from the grid that I have the content loaded into.  I think I should be
> in control of my content.  I also think I should be able to block grids
that
> my content is being accessed from.  If you don't always maintain the
> original content location there will be no control.  If I give someone a
> copy of my content, then that is something else, they are now the owner of
> it and are free to do as they please with it, at least within any license
I
> give them.  But that is a legal stuff not a technically programmed one.
At
> least I don't expect all situations to be programmed.
> 
> Also when asset services start happening this will become more of an
issue.
> I will have XRMarketplace.com live soon and plan to start selling content
> and provide that content as an asset server.  How will I maintain any kind
> of control over the use of my content if people don't have to pull copies
> from me?
> 
> I also think, and haven't seen in the new hypergrid, if someone goes to a
> new grid I may not allow any of my content to go there unless that avatars
> gets an authorization from me which should be attached to his proxy
profile
> for access into my grid/asset server.
> 
> The other thing to think about is how updates or corrections are
propagated.
> SL has a terrible system of only supporting copies so any updates or
copies
> have to be sent to everyone.  Seems content replacement needs to be
> supported and if content is all over the place this will get even crazier.
> Also to support dynamic content there needs to be a ways to refresh or
> update content.  I suggest there needs to be an expiration date on the
> content just like how images and HTML pages on the web work so that cached
> content will know to pull a new copy.  And if the expiration date is 0, at
> the time it was pulled, it will always get refreshed.
> 
> This is maybe should have its own discussion thread but seems to be part
of
> how this is all going to work.
> 
> M.
> 
> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Ai Austin
> Sent: Tuesday, August 31, 2010 4:17 AM
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Global identifiers
> 
> myticaldemina makes a lot of good points... one thing that could be 
> problematic though relates to this comment...
> 
>>From: <mysticaldemina at xrgrid.com>
>>...I would suggest any
>>proxies would give the external system and identifier and not chain proxy
> to
>>proxy unless there is a reason to do it, and the assets should be copied
>>from the original source.
> 
> 
> I agree with the first half... no chains, just hand over the external 
> system "authority" and its given identifier pair for the identity
involved.
> 
> But I don't agree at all with the idea that you then have to get the 
> asset from that original authority.  The permissions could have 
> changed, corruptions could have occurred or much more likely the 
> authority simply will no longer be there.  The asset "as is" (with 
> its textures, scripted content and what not) should be provided to 
> the destination location/grid if the object permissions allow it, 
> with proper transfer of the permissions to next owner exactly as if 
> an avatar to avatar transfer or rez in world took place on the local 
> grid, without trying to reload the asset from an original source.
> .
> 
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev