Re: [mmox] Creating walled gardens considered harmful

[Jon Watte <[e-mail]>]

Morgaine wrote:
>
> While the original idea came from Linden Lab, that is no stumbling 
> block:  every idea has to originate somewhere.  OGP has the great 
> merit of being all-embracing as a concept, once you see that certain 
> ideas like /teleport/ and /client endpoint/ are actually much more 
> flexible than they might at first appear.  /Client endpoints/ on an 
> OLIVE server could "easily" allow Second Life clients to interoperate 
> with OLIVE clients.
>

So, now for the less rosy situation:

Even with the definition of the three services that you enumerated:

   1. /Identity transfer is negotiated to provide continuity of identity
      across the change of environment./
   2. /Presence transfer is negotiated to discontinue presence in world
      A and commence presence in world B./
   3. /Asset transfer is negociated in the A->B direction to allow
      assets from world A to appear in world B, or to deny the transfer
      where appropriate./

There is no actual interoperability achieved if those are standardized. 
For a user of any other virtual world platform than SecondLife/OpenSim, 
these services would give them zero value. Thus, for virtual world 
platforms other than SecondLife/OpenSim, there is close to zero 
incentive to implement these services. And, because there is close to 
zero incentive to implement these services, there is close to zero 
incentive to participate in the standardization effort.

I think that this is a problem. I'd like to understand how others feel 
about the same thing. I could see a number of different standpoints:

1. "It doesn't matter if some platforms won't participate in this model; 
we only care about the ones who do." (This leads to the self-selecting 
clique problem, which leads to isolated islands of separate 
interoperability)
2. "We need reasonably broad adoption for a standard to matter, so we 
have to change the problem statement until there is value in the 
standard for a reasonably broad set of platforms." (This leads to the 
"re-define what we are doing" problem)
3. "If we start here, then we can build on that in the future, until 
such time as more platforms will get benefits from the standard." (This 
leads to the problem of building things intended to be used by others 
without any input on what their constraints are)

I currently am of opinion 2. I perceived the initial standpoint by the 
AWG contribution as 1. If you are of opinion 3, how are you going to get 
the requirements right?

I think that it's important that everyone who will contribute to this 
work actually clarifies what their assumptions are in this regard (as 
well as the use case/requirements regard).

Sincerely,

jw