Re: [ogpx] Tourist use case

["dyerbrookme at juno.com" <dyerbrookme at juno.com>]

In other words, now the copylefists appear to have set up the proposition, and have been setting it up for months and months, that if we want interoperability and interworld travel, we will have to further shed property rights in the name of "seeing" other worlds because the agent "must" access every other asset server in the metaverse without anything blocking him.

I've been following this discussion for awhile, and I want to point out again that it is not a technical discussion, but a political discussion, and it's a profoundly political discussion about sharing the power and property of the Metaverse which some conceive of as collectivized and free, and others view as having ownership rights 
required to sustain economies.

It involves the constant, relentless refrain of the copyleftists and extreme Extropians in Second Life: "I "must" have access to "my" inventory for which I have permissions and the system "must" deliver the assets to my view or I can't see it."

Says who? You completely overlook that the creator of the assets may have intended their permissions to exist only in that world, and not available to spread at will throughout the metaverse just because you own one copy. Many non-transfer items are on copy for that world, but that doesn't mean they were intended for copy elsewhere. The copy permissions system could evolve to designate "transit" or "other world" permissions but that should be an opt-in by the creator, not an opt-out. Sure, there might be people who want their wares copyable or transportable throughout the metaverse but *not everybody* and we're all aware that just as soon as you mandate the "must copy it to see it" mantra *everywhere* you have handed over all property to all agents. 

The "right" to access inventory and view assets isn't the agent's, it's the right of the owner of the platform and the right of the creator of the object, *the copyright* and *that's ok*. The right of visitors/tourists has to be balanced against the right of existing *citizens* as in the RL analogy. Invocation of "walled gardens" and such doesn't hold, because there must be choice. You can't say "all tourists and immigrants can have everything for free and have it copyable to resell" whereas the citizens who pay the platform owner's costs have to pay for it, and wish to pay for content to support creators who in turn want their intellectual property rights 
sustained.

You persistently claim that property rights are metadata that have to be stripped away in the interest of the technicalities of building "the pipes," but that is a profoundly political act, not a technical one, as it turns over all the assets of the Metaverse to every passing "tourist".

What's especially contradictory is that the same people pushing for the ability to derender content and people they don't like, through alternative viewers, are demanding the ability to see and access every asset on every asset server "just because".

This looks to me like a blatant grab for all the assets of the Metaverse by one company, or by one small group grabbing the interoperability topic.

Interoperability is not consumer-driven and there is no demonstrable need for it except for that manufactured by a few companies for their own agenda.
____________________________________________________________
Medical Insurance Quotes
Compare medical insurance companies and save money now.
http://thirdpartyoffers.juno.com/TGL2141/c?cp=1wJOeTBdfDuXhCBbabgBWgAAJ1BAkQUOY6racJgsKTPwXVdzAAQAAAAFAAAAAN8H_T4AAAMlAAAAAAAAAAAAAAAAABJQNgAAAAA=
Great post Joshua, leading to many key issues!

On Fri, Oct 30, 2009 at 5:23 PM, Joshua Bell <josh at lindenlab.com> wrote:

On Fri, Oct 30, 2009 at 12:29 AM, Morgaine <morgaine.dinova at googlemail.com> wrote:

This directly implies that asset services must be quite separate from ADs.  Although we haven't spelled it out, clients must have access to an arbitrary list of asset services, because as agents travel around the VWRAP-compatible metaverse, the regions they visit will contain objects from an arbitrary number of asset service providers.

Without access to these asset services, the visited regions would not be visualizable at all.  And denying visualization is no business of the AD's.  This makes it clear that access to asset services should not be mediated by the AD at all --- the AD's role should be limited to allowing or denying entrance to a region.  Once inside a region, it is the region that offers capabilities for access to the asset services of assets within the region.

After reading this a few times, I agree with the high level sentiment - but be careful regarding the terminology, as specific wording tripped me up the first few times through.

My writing style tends to be preoccupied with precision, and readability can suffer, sorry. ;-)

I did however mean exactly what I wrote, and I chose the term mediate deliberately for its breadth of coverage, because I wanted to convey strongly that the AD should have nothing whatsoever to do with allowing or denying access to specific asset services relevant to a region, directly or indirectly, in any manner at all other than by permitting entry in the first place.

This may seem like major anathema from a centrally-controlled, single asset service perspective.  However, it falls out naturally when you consider:

• David's point about no AD policy control over remote services,
  
• Carlo's point about users having control over their own inventory,
  
• the quite widespread support for an agent/region split in policy controls,
• John's support for strongly decoupled asset services as in Cable Beach,
  
• my point about not breaking region visualization once in a region.

All of these points shout loudly that considering assets and inventory to be part of the agent service is badly structured because it creates unnecessary constraints.  It seem far more appropriate to consider asset services as independent, so that whoever needs them can gain access to them if the services permit it.  (This doesn't imply a free-for-all, to be clear, but only that there should be no a priori barriers by design, such as would occur if ADs were given exclusive power to grant caps for all asset services.)

Instead, if an AD provides an inventory service (a policy choice), then this is just one contributor to the client's inventory.  [I'll cover this explicitly further below.]

In the SL protocol today, clients only ever communicate with a region. It's the region's responsibility to provide the data for what the agent sees. This occurs both for items that would be considered aspects of the region (chairs, buildings, trees, waterfalls) and "transient" items (other avatars with attachments). The region exposes a data source (today, the byte-efficient but fairly grotesque family of UDP packets) of the description of objects (prims, textures, sourds, animations, ...) which the client consumes.

Behind the scenes, the region may be pulling those object definitions from an asset service, or they may be present in the region definition itself. The client is unaware of this - it's hidden behind the services the region exposes.

That's fine. :-)   Right from the earliest days of the AWG, it has many times been said that the proxying performed by SL sims is merely a design choice or implementation detail, and that other implementations of the same protocols could choose to proxy fewer services, or none at all.

This is actually a very important issue for the protocol, because proxying has a major impact on the scalability and availability of a sim, and also on the scalability and availability of any services that it proxies, so flexibility of choice is crucial.

If services are decoupled then such flexibility can be achieved with nothing more than appropriate configuration of service endpoint locations to permit the whole gamut of proxying choices to be expressed, including no proxying.  And REST was chosen among other reasons for its flexibility in allocation of endpoints, so we already have the means to do this. :-)

Now for the terminology bit: we can call the services the region is exposing "asset services" but these could be quite distinct from the sorts of things present in an agent's inventory. One phrase that's potentially confusing is "the regions they visit will contain objects from an arbitrary number of asset service providers" - while I agree with the high-level interpretation of that statement, I think it paints a picture that as you're exploring a region, the client is *necessarily* going off and making connections to a variety of asset servers to fetch the data.

I don't think VWRAP should *preclude* that (I imagine it's only sensible for things like textures to be referenced by URLs which could be coming off of any old place), but my initial reading of your text was that the client would necessarily be fetching things from external asset services. For example, if I buy a chair on FooGrid and drop it on BarGrid, when you visit BarGrid you're having to ask FooGrid's asset service for the description. Again, I think that's *conceivable*, but shouldn't be *necessary*. (And I don't think you're claiming that - but my first read-through came away with that impression.)

I certainly agree on the principle of deployment choice!  :-)

We periodically tell each other that we're interested in defining only mechanisms, not policies, but this is implied all the time, I hope.  The principle is so clear and uncontested that it's widely seen as universal in IETF protocol work, although the latter is my own personal reading of it.  For us here it means that nothing important is precluded, and that a given provider may choose not to implement or configure a given feature or facility, yet the mechanism that we provide should allow it.  In the current case, it means that service proxying must be a deployment choice, neither required nor precluded by the protocol.

Perhaps I should explain further the phrase that gave you trouble above.  I was trying to indicate that once an agent is in a region, denying the user the ability to visualize the world around her would be a very bad idea, as it would break the intended perceptual mashup.  "Breaking the perceived world" is such a poor idea on many fronts that nobody has proposed it as far as I know, and if we have a legacy design that may be interpreted as suggesting exactly this then it should raise immediate red flags with us.  (I'm not saying that it does.)

The original OGP idea was almost always described with the AD as sole provider of seed caps, but the caps concept is of course not actually limited in this regard, and I've been working towards a flexible interpretation.  In my preferred interpretation stemming from our discussions about tourism, it includes the semantic that the AD can provide cap access to other sources of seed caps.  It is through this mechanism that we would implement the variously described key concept of "separation of agent and region policies" or "policies are local" or "no policy export", and it is this that would allow us to support the DDP principle through which we achieve tourism in those VWRAP deployments where it is desired.

I hope that this explains it better.  Such choices are not precluded nor mandated -- the AD doesn't have to provide a cap to any given region or RD, that's a policy decision.  But if it chooses to grant the cap for access to a particular region then that region's policies now apply within the region.  It is then up to the region to grant the seed caps that give access to the assets that allow the region to be visualized, as one crucial operation.

Here is is my design principle for a caps system that would meet multiple requirements:

Gaining access to resources via caps is akin to exploring a caps tree.  Each inner node (region) provides a seed cap that gives access to any number of leaf nodes (asset services) and to any number of child nodes (other regions).  What distinguishes the AD is that it's the root node of the tree.

Now I can fill in my earlier forward reference to how inventories should be structured:  if the AD provides an inventory service (a policy choice), then the items in the inventory offered by the AD are the items delivered by the asset services linked at the leaf nodes of the AD's initial caps tree.  Not only is this elegant and extensible through tree-structured design, but it also supports an unlimited set of policies and deployments without prescribing nor proscribing anything.

And, of course, one can conceive of clients that implement a policy of not trusting FooGrid for anything and wouldn't make such a connection - FooGrid could be blacklisted by some large search company, my ISP, or perhaps my AD.

Definitely.  That's a policy choice, just don't grant the region cap!  :-)
 

Indeed, but fortunately it hasn't been proposed that asset services be part of the agent service in VWRAP.  The legacy SL model of assets and inventories clearly doesn't apply in our extended scenarios, and the OGP documents never covered asset services at all, so we're defining the asset services and inventory model of VWRAP as we speak. :-)

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.

This is a great analysis, which we hadn't approached previously.  I think your list could be used directly to drive our use case analysis to be sure that we're covering all the bases.

Note that at this stage I'm considering all resources to be accessible through caps, not only for symmetry and simplicity but because we haven't defined any other access mechanism yet, so my reference to "assets" was intended to apply to all "content" in the widest sense.  This broad use of the word "asset" stems from our choice of phrase "asset service" --- if we don't use the broad meaning then we're precluding storage of data such as objects and terrain on asset services, which would be a bad idea as we'd have to invent yet another type of storage service.

I think this hints at the problem caused by using SL-defined terms in our wider setting.  Perhaps we should spend a week revising the terminology that applies to VWRAP.  (We did this at the start of AWG to create an AWG Glossary, and it was very illuminating.)


Morgaine.




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

On Fri, Oct 30, 2009 at 5:23 PM, Joshua Bell <josh at lindenlab.com> wrote:

On Fri, Oct 30, 2009 at 12:29 AM, Morgaine <morgaine.dinova at googlemail.com> wrote:

This directly implies that asset services must be quite separate from ADs.  Although we haven't spelled it out, clients must have access to an arbitrary list of asset services, because as agents travel around the VWRAP-compatible metaverse, the regions they visit will contain objects from an arbitrary number of asset service providers.

Without access to these asset services, the visited regions would not be visualizable at all.  And denying visualization is no business of the AD's.  This makes it clear that access to asset services should not be mediated by the AD at all --- the AD's role should be limited to allowing or denying entrance to a region.  Once inside a region, it is the region that offers capabilities for access to the asset services of assets within the region.

After reading this a few times, I agree with the high level sentiment - but be careful regarding the terminology, as specific wording tripped me up the first few times through.

In the SL protocol today, clients only ever communicate with a region. It's the region's responsibility to provide the data for what the agent sees. This occurs both for items that would be considered aspects of the region (chairs, buildings, trees, waterfalls) and "transient" items (other avatars with attachments). The region exposes a data source (today, the byte-efficient but fairly grotesque family of UDP packets) of the description of objects (prims, textures, sourds, animations, ...) which the client consumes.

Behind the scenes, the region may be pulling those object definitions from an asset service, or they may be present in the region definition itself. The client is unaware of this - it's hidden behind the services the region exposes.

Now for the terminology bit: we can call the services the region is exposing "asset services" but these could be quite distinct from the sorts of things present in an agent's inventory. One phrase that's potentially confusing is "the regions they visit will contain objects from an arbitrary number of asset service providers" - while I agree with the high-level interpretation of that statement, I think it paints a picture that as you're exploring a region, the client is *necessarily* going off and making connections to a variety of asset servers to fetch the data.

I don't think VWRAP should *preclude* that (I imagine it's only sensible for things like textures to be referenced by URLs which could be coming off of any old place), but my initial reading of your text was that the client would necessarily be fetching things from external asset services. For example, if I buy a chair on FooGrid and drop it on BarGrid, when you visit BarGrid you're having to ask FooGrid's asset service for the description. Again, I think that's *conceivable*, but shouldn't be *necessary*. (And I don't think you're claiming that - but my first read-through came away with that impression.)

And, of course, one can conceive of clients that implement a policy of not trusting FooGrid for anything and wouldn't make such a connection - FooGrid could be blacklisted by some large search company, my ISP, or perhaps my AD.

Indeed, but fortunately it hasn't been proposed that asset services be part of the agent service in VWRAP.  The legacy SL model of assets and inventories clearly doesn't apply in our extended scenarios, and the OGP documents never covered asset services at all, so we're defining the asset services and inventory model of VWRAP as we speak. :-)

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.




_______________________________________________
ogpx mailing list
ogpx at ietf.org
https://www.ietf.org/mailman/listinfo/ogpx