Re: [ogpx] Tourist use case

[Han Sontse <[e-mail]>]

Begin forwarded message:

> From: Han Sontse <[e-mail]>
> Date: November 2, 2009 1:13:25 PM PST
> To: [e-mail]
> Subject: Re: [ogpx] Tourist use case
>
> On Nov 2, 2009, at 6:05 AM, Morgaine wrote:
> > Decoupling the simulation from the storage is one of the most  
> important things that this protocol will achieve if we
> > get it right.  We probably do need to ensure that SL's existing  
> "proxy everything" model can be expressed through
> > appropriate policy or deployment choices as it is likely to be a  
> requirement, but this should not constrain what the
> > protocol can do under different policies or deployment scenarios.
>
> Removing the 'proxy everything'  from the sim seems to me to be  
> fairly straight forward.  A connected client might get a list of  
> region-local UUIDs for content that has presence in the Sim.  As the  
> client works through the process of building a local representation,  
> some or all of the UUIDs might actually 'redirect' to another  
> service that provides the representation.  The Sim in effect is  
> saying, "I don't have a representation for this object, but you can  
> get the properties @ <url>?=<Sim_id>,<UUID>  or some such...  A  
> client requesting this asset representation is also communicating  
> where it got redirected from, so that the correct instance of that  
> asset is accessed.
>
> At the same time the Sim might have a partial representation of this  
> object!  This partial representation includes only the information  
> the Sim needs to manage the interaction of this object with the rest  
> of the Sim.   This management information is likely to be a very  
> restricted set of properties, and may not be static in nature.  It  
> could however provide some public information so that clients with  
> policy or capability restrictions in requesting the full  
> representation might still acquire a 'default' representation as a  
> placeholder.
>
> In thinking about this it occurs to me the asset might be a dynamic  
> service that has NO static representation, such that the Sim sees  
> (for example) the service as a dynamic, shifting, set of bounding  
> volumes. An untrusted user/client might see a low resolution stream  
> of textured meshes. A more trusted user/client might get a  
> complete .obj model and be receiving only skeletal updates from the  
> asset service.
>
> Abstracting a bit further, an asset is a service in and of itself.   
> The Sim provides a url to the relevant instance of the service.  The  
> client, asset service, and Sim negotiate a cooperative context/ 
> representation for the service.  This is true even if the service is  
> local to the Sim.
>
> If the asset service wants to require some kind of authentication  
> for privileged representations of the service they are welcome to do  
> so.  The Sim operator may already have some baseline relationship  
> with the asset-service.  Each user/client might have a different  
> relationship with that service.
>
> In this context a tourist might see minimal representations from  
> asset services that have restrictive access policies and more  
> complete representations from services that have less restrictive  
> policies.    What a tourist "sees" through the client has more to do  
> with their trust relationship with the asset service community than  
> with the Sim community.   Though I see no reason that such trust  
> relationships be mutually exclusive, nor even required.
>
> Han
>
>
> On Nov 2, 2009, at 6:05 AM, Morgaine wrote:
>
>> On Mon, Nov 2, 2009 at 11:49 AM, Carlo Wood <[e-mail]> wrote:
>>
>> I agree with you that information needed to see a rezzed object  
>> should
>> come from the region (simulator), so -- in principle there is no  
>> direct
>> reason that a viewer needs to have access to every asset server whose
>> assets are rezzed.
>>
>>
>> The region certainly needs to indicate which objects are rezzed in  
>> it --- it is the single authority that holds that information ---  
>> there is no other place where this information could come from in  
>> the current model.
>>
>> However, that does not mean that it has to actually hold the data,  
>> but merely to indicate which it is so that it can be fetched.   
>> Indeed, requiring the region to hold the data or to proxy it would  
>> be really bad for protocol scalability.  In any case, that's a  
>> policy choice --- our mechanism needs to be more flexible than this  
>> in its service endpoint choices, and not require the data to come  
>> from the region.  It is highly likely that many implementations  
>> will aim for higher scalability than is possible to achieve by  
>> routing assets through a sim.  Indeed, that's a primary reason for  
>> using caps for accessing decoupled services in a REST-like manner.
>>
>> Decoupling the simulation from the storage is one of the most  
>> important things that this protocol will achieve if we get it  
>> right.  We probably do need to ensure that SL's existing "proxy  
>> everything" model can be expressed through appropriate policy or  
>> deployment choices as it is likely to be a requirement, but this  
>> should not constrain what the protocol can do under different  
>> policies or deployment scenarios.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>>
>>
>> ======================================
>>
>> On Mon, Nov 2, 2009 at 11:49 AM, Carlo Wood <[e-mail]> wrote:
>> Using common sense, I'd say:
>>
>> * If you try to rez an object, policy comes in to determine if that  
>> is allowed.
>>
>> * Once an object is rezzed, EVERYONE that is in the region (that is  
>> allowed to
>>  enter the region thus) can SEE that object (and interact with it).
>>
>> I realize that it is *possible* for the region to implement a policy
>> where it selectively shows data to some people and not to others, but
>> I don't think we have to officially support every possible way to  
>> screw
>> up shared experience in VWRAP, just because it would be possible to  
>> do so.
>>
>> Compare with a protocol like SMPT: that dictates that if some email  
>> is
>> received, it is required to react in one of a few given ways. There  
>> are
>> other ways, but that would make the system stop functioning as  
>> intended,
>> so that is Not The Idea.
>>
>>
>> I agree with you that information needed to see a rezzed object  
>> should
>> come from the region (simulator), so -- in principle there is no  
>> direct
>> reason that a viewer needs to have access to every asset server whose
>> assets are rezzed.
>>
>>
>> An interesting question is now: what about assets that make up an
>> avatar? Once in-world, attaching a new attachment, or changing  
>> clothes
>> or shape, is just the same as rezzing of course: if the asset server
>> allows access (by that region) than the region can buffer it and show
>> it to everyone; otherwise attachment, or change of appearance, is  
>> disallowed.
>> However, in the case of teleportation I think we need to act more
>> intelligent than just black or white (allow or disallow the TP):
>> I'm in favour of allowing the TP independent of assets being used at
>> that moment, but instead detach assets and/or Ruth the avatar if
>> need be (at least, give the user that option).
>>
>> On Fri, Oct 30, 2009 at 10:23:43AM -0700, Joshua Bell wrote:
>> > Be careful about blurring the use of "asset services" between  
>> "stuff in
>> > regions" and "stuff I have". I think there is a big intersection  
>> - and may have
>> > the same characteristics and/or protocols, but I also think they  
>> are are
>> > distinct. I would guess that there will be asset services  
>> associated with both
>> > agents and regions - off the top of my head:
>> >
>> > Uses of an agent-associated "asset" service:
>> > * content to client app (inspect your inventory)
>> > * content from client app (upload/import to inventory)
>> > * content to region (rez something)
>> > * content from region (buy/take something)
>> > * content to agent (give something)
>> > * content from agent (receive something)
>> >
>> > Uses of an region-associated "asset" service:
>> > * content to client app (see the world)
>> > * content from client app (upload/import to region)
>> > * content to region (during teleport/region crossing)
>> > * content from region (during teleport/region crossing)
>> > * content to agent (buy/take something)
>> > * content from agent (rez something)
>> >
>> > I'm using "asset" in quotes since that term may be overloaded.  
>> "Content" might
>> > be a better term.
>>
>> --
>> Carlo Wood <[e-mail]>
>> _______________________________________________
>> ogpx mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>> _______________________________________________
>> ogpx mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ogpx
>