[Opensim-dev] Global identifiers

diva at metaverseink.com diva at metaverseink.com
Tue Aug 31 17:56:52 UTC 2010 

One last thing, possibly of interest to the folks in VWRAP:

Another thing that happened to OpenSim as it reached 0.7 was the 
reconceptualization of the software itself. As a consequence of this 
reconceptualization, interoperability architectures such as the 
Hypergrid are built as optional components that don't affect the core of 
the walled-garden code.

As such, for those who don't like the Hypergrid for whatever reason, you 
can experiment with your own ideas of interoperability without having to 
tip toe around it. I suggest you understand HG1.5 first, as not to 
reimplement it again. Then, if what you want to do is really different, 
and not just a layer of *policy* above HG1.5 (policy specifications will 
be supported soon), follow the same philosophy of modularizing things 
properly, as that will give your architecture a chance for people to use 
as plugin. If you run into a missing hook, just let me know.

Bottom line wrt interop, two major things happened: 1) the hypergrid 
1.5, a system-to-system (S2S) architecture with the trust/security model 
explained below; and 2) the clean up of the framework, allowing anyone 
to experiment with interop.

diva at metaverseink.com wrote:
> One more thing, a bit less important than the others, as the others 
> pertain to grid-level content, and this one pertains to user-level content:
> 
> - WRT to the user agent itself (i.e. name, appearance, etc.), the user's 
> user agent service (a grid-level service) is the party responsible for 
> creating user agents that are launched at foreign grids. As such, that 
> component is the authority that defines what agent data to send. If the 
> user agent service of one grid so wishes, all of its users' agents can 
> be anonymized and stripped off their clothes before going out.
> 
> - HG 1.5 has another, symmetric, grid-level component called the 
> Gatekeeper which has the role of deciding what comes in to its grid. So 
> if the Gatekeeper so wishes, it can anonymize all foreign user agents 
> and strip them off their clothes before allowing them in.
> 
> In other words, the user agent service and the gatekeeper service are 
> the yin and yang of the Hypergrid.
> 
> diva at metaverseink.com wrote:
>> [unrelated to the narrow issue at hand, but since people want to know, 
>> here goes]
>>
>> HG 1.5 has a trust/security model. The base case is one where grids 
>> are peers, and the traveling of one user agent from his home grid to 
>> another establishes the *base trust* in the following manner:
>>
>> - Everything that the agent references from his home grid is made 
>> available to the foreign grid where the user is. In other words, the 
>> user is the driver of trust.
>>
>> - Everything else that is not referenced by the visiting agent is out 
>> of reach. "Out of reach" is a soft security model, i.e. the resources 
>> are available on the internet, but you need to know their identifiers 
>> in order to get them. Their identifiers behave as capabilities. This 
>> is the part that still needs work, as Melanie thinks 'soft' is not 
>> enough.
>>
>> This trust model is the base upon which trust policies can be defined. 
>> In other words, we now have the basis to add additional grid-level 
>> specifications that overwrite the user's actions.
>>
>> Melanie wrote:
>>> Hi,
>>>
>>> HG 1.5 doesn't address these concerns. Also, please remember that
>>> assets need to be freely available to all, else they can't be
>>> displayed. The observer gets a copy, too.
>>>
>>> Animations, textures, sounds, etc. need to be given to all observers.
>>>
>>> Melanie
>>>
>>> Mike Dickson wrote:
>>>> Right. I think some of the use cases related to how content is shared
>>>> have been glossed over. In a completely open model which is what has
>>>> been discussed this is all pretty straightforward.  But if I'm running
>>>> an asset service (as part of a grid or separately) I might want to
>>>> provide access controls as part of that service. The same with user
>>>> services.  I may have a trust relationship with one agent service and
>>>> allow content to be transferred to agents that service represents. But
>>>> for another agent service for which no such relationship exists I'd 
>>>> like
>>>> to deny access to content. And even in the transfer case does the new
>>>> user get a new copy or a reference. That concept isn't supported now 
>>>> but
>>>> in a distributed grid its an important distinction. I might wish to 
>>>> know
>>>> that copies of objects rezzed in a simulator always come from a 
>>>> specific
>>>> asset service.
>>>>
>>>> In short I think how the security model works is way more important 
>>>> than
>>>> a caching optimization being applied to a URI/URL.  Its important to
>>>> understand what levels of trust between services are supported and 
>>>> under
>>>> what conditions an access is supported.  As an Agent Service I may
>>>> consider even the "Names" of my users to be confidential and only to be
>>>> revealed to services for which a trust relationship exists.
>>>>
>>>> Mike
>>>>
>>>> On Tue, 2010-08-31 at 13:23 +0000, 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
>>>>
>>>>
>>> _______________________________________________
>>> 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
>

More information about the Opensim-dev mailing list