Re: [ogpx] Tourist use case

["[e-mail]" <[e-mail]>]

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 <[e-mail]> wrote:

> On Fri, Oct 30, 2009 at 12:29 AM, Morgaine <[e-mail]
> > 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 <[e-mail]> wrote:

> On Fri, Oct 30, 2009 at 12:29 AM, Morgaine <[e-mail]
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>