Re: [mmox] Creating walled gardens considered harmful

[Morgaine <[e-mail]>]

On Wed, Mar 25, 2009 at 5:17 PM, Jon Watte <[e-mail]> wrote:

>
> Once you start talking about higher-level functions like "OGP Teleport" or
> having a client/viewer connect to simulation services, we immediately run
> into significant political and technical challenges, where I don't think
> there is actually a possibility of "one model fits all" or even "one model
> fits most."
>
>
 Jon, I think we need to go beyond the entrenched pre-BoF statement of
positions and telephone analogies if we are to get anywhere at all.  I
suggest that we leave the general presentations behind and talk about VW
specifics at a technical level, one at a time.

You claim some fundamental incompatibility introduced by the concept of
teleport, but I believe that that is unfounded.  Let's examine it more
deeply.

When a client A1 from world A in the OGP ecosystem requests a teleport to a
specified address in some other world B, three things happen at a conceptual
level that are entirely independent of the actual details of OGP (I'm going
to avoid OGP terminology):


   1. *Identity transfer is negotiated to provide continuity of identity
   across the change of environment.*  This is carried out by the identity
   provider of A contacting the identity provider of B if the two providers
   have an interop agreement, but if B is unknown to A then we do not yet have
   a scheme for this.  (The latter can be expected to be the majority case in
   an Internet-spanning metaverse.)  The 3-world interop
scenario<http://www.ietf.org/mail-archive/web/mmox/current/msg01114.html>captures
both cases.
   2. *Presence transfer is negotiated to discontinue presence in world A
   and commence presence in world B.*  This is mediated by the identity
   provider of A requesting termination of the old presence in A, and the
   identify provider of B requesting startup of the new presence at a specified
   location in B.  At the end of this process, the avatar in client A1 can now
   perceive that it is present in the environment of world B (but nobody else
   can).
   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.*  This involves seeking authorization and transfer from the
   asset provider of A, which is conceptually a separate service from
   identity.  Since the avatar of A1 may be wearing or carrying items from many
   worlds, this operation is carried out by B for each asset provider
   involved.  At the end of this process, everyone else in B can also see A1's
   instantiated assets.


The above 3 things have to happen whatever the world architecture, otherwise
the real goal of interop *from the point of view of the user* has not been
achieved:  *to create a mashup in which the user's avatar is now in a new
world setting and visible to new people*.

This is equally applicable to architectures in which only the world servers
communicate among themselves.  "Teleport" just means changing the presence
from one shared space to another, and the only difference is in the words
used to describe the operation.  *Identity transfer* is still required or
there is no interop, although visible names may change of course.  *Presence
transfer* is still required otherwise an avatar would not be able to appear
in new environments.  *Asset transfer* is still required otherwise there
will be no new assets visible when avatars appear in new places.

All of these things are required for full-featured 3D world interop (2D
worlds and Limited Capability Clients require only a subset).  Where is the
problem with handling these requirements using server-server communications
alone?

Please be specific, post-BoF.


Morgaine.








On Wed, Mar 25, 2009 at 5:17 PM, Jon Watte <[e-mail]> wrote:

>  Morgaine wrote:
>
> Splitting the work of MMOX into various implementation-oriented groups
> would be an excellent way of making progress, but it carries a *severe
> danger*:  *it could create several non-interoperating walled gardens*, if
> the groups work independently without a common view and purpose.
>
>
> One problem is that we don't even agree on what interop should be, and what
> adds value to the growing global interconnected metaverse. I think this is
> compounded by the fact that the group started out as a proposal to
> standardize work done in the Second Life breed of virtual worlds, without
> any particular consideration for the significant architectural differences
> to almost all other platforms.
> In fact, *we don't even have representatives from most platforms in this
> group*, which I think is a real shame, and a problem if we want broadly
> implemented interoperability. We may do well by trying some more outreach.
>
>
> *For the non-virtual-world-savvy on the list*: If I were to make a cell
> phone analogy about the problem, it would go something like this:
>
> The problem we want to solve is that I am on the Sprint network, and my mom
> is on the AT&T network, and I want to call my mom.
>
> The OGP proposal, in this analogy, wants to standardize how handsets
> connect to carriers. Let's say it is somewhat similar in function for
> virtual worlds to what GSM, or D-AMPS, or CDMA, or UMTS is for cell phones.
>
> The LESS proposal, in this analogy, wants to standardize how carriers talk
> to other carriers. Let's say it is somewhat similar in function for virtual
> worlds to what SS7, H.320, or SIP plus codecs are for phone networks.
>
> The interoperability provided by the OGP ("GSM") model is that I can take
> one phone, and connect it to different carriers. If I want to talk to my
> mom, I disconnect from Sprint, and re-connect to AT&T, and I can talk to
> mom.
>
> The interoperability provided by the LESS model does make it so that I can
> call my mom through my existing carrier. However, it decides to leave the
> handset standard (GSM vs CDMA) outside of interoperability, both because
> building handset/base station suites is really expensive, there are already
> lots of such stacks already available from different providers, and because
> the basic functionality (talking across different carriers) is actually a
> more enabling technology than re-connecting your phone to a different
> carrier, while simultaneously being cheaper to implement. There is, however,
> nothing remotely as well accepted in virtual worlds as GSM, UMTS or even
> CDMA are in the cell phone world. There is also nothing remotely as well
> accepted as SS7 or H.320 or SIP.
>
>
> Yes, this analogy can only be taken so far before it breaks down and
> becomes a hinderance rather than a help, but I do think it does help focus
> the discussion about charter: *Does it really make sense to discuss the
> "GSM/D-AMPS/CDMA/UMTS" question in the same working group as the
> "SS7/H.320/SIP+codecs" question?*
>
>
>
> If OGP was a pure service broker protocol (similar to a service bus, or
> OSIDs), then we could probably find common ground -- but then, why not use
> OSID, or one of the dozen or so similar service broker technologies already
> available? Or, in fact, why not just expose a XML-RPC or SOAP interface that
> returns an XML blob of defined schema that lists named/typed services as
> URLs, and we're done?
>
> Once you start talking about higher-level functions like "OGP Teleport" or
> having a client/viewer connect to simulation services, we immediately run
> into significant political and technical challenges, where I don't think
> there is actually a possibility of "one model fits all" or even "one model
> fits most."
>
>
> Sincerely,
>
> jw
>
>