Subject: Re: [ogpx] Tourist use case

From: Carlo Wood <[email-masked]>
Date: Mon, 2 Nov 2009 12:49:29 +0100

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 <[email-masked]>

---

From: Morgaine <[email-masked]>
Date: Mon, 2 Nov 2009 14:05:00 +0000

> reason that a viewer needs to have access to every asset server whose

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 <[email-masked]> wrote:

> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>

---

From: Han Sontse <[email-masked]>
Date: Mon, 2 Nov 2009 13:13:25 -0800

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:

> 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.
>
>
>
>
>
>

---

From: Han Sontse <[email-masked]>
Date: Mon, 2 Nov 2009 13:21:28 -0800

Begin forwarded message:

> From: Han Sontse <[email-masked]>
> Date: November 2, 2009 1:13:25 PM PST
> To: [email-masked]
> Subject: Re: [ogpx] Tourist use case
>
> 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.
>
> 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  
> 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.
>
> 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
>
>
>> 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.
>>

---

From: Carlo Wood <[email-masked]>
Date: Tue, 3 Nov 2009 00:30:40 +0100

This only advantage that I can see by this (the region only tells you
that object "xyz" is at position P with orientation O), is that then
you might be able to cache objects on the viewer.

However, THAT is only possible if 'xyz' is unique (some UUID) that changes
as soon as an object is editted in anyway, expect position and orientation
of course (rez parameters, not part of the object).

On Mon, Nov 02, 2009 at 02:05:00PM +0000, Morgaine wrote:
> 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.
> 
> 
> 
> 
> 
>

---

From: Morgaine <[email-masked]>
Date: Tue, 3 Nov 2009 09:45:36 +0000

The main reason why we're using REST and HTTP is to leverage the
infrastructure of the web and hence give ourselves massive scalability.  It
opens up the possibility of transparent caching and proxies and load
balancing and a lot of other good things, which we're going to need if
virtual worlds are going to become all-pervasive.  But to achieve that we
need to leave behind the narrow focus on sims and "free the services", which
is what REST and caps allows us.

The potential advantages really are huge, and go beyond mere caching in the
viewer.

Morgaine.

================================

On Mon, Nov 2, 2009 at 11:30 PM, Carlo Wood <[email-masked]> wrote:

> things
> requirement,
> >     * 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
> >     > regions" and "stuff I have". I think there is a big intersection -
> and
> >     may have
> >     > distinct. I would guess that there will be asset services
> associated with
> >     both
> >     > I'm using "asset" in quotes since that term may be overloaded.
> "Content"
> >     might
> >     > be a better term.
> >
> >     --