Subject: [mmox] Loosely Coupled Virtual Worlds

From: Jason Giglio <[email-masked]>
Date: Wed, 25 Mar 2009 18:06:07 -0400

Since it has come up several times that there is interest in a more
lightweight proposal, here is a paper I co-authored with Pleiades
Consulting called "Loosely Coupled Virtual Worlds".

The short version -- The viewer could just perform full logout and login
seamlessly (and potentially behind the scenes) with a client-side
credentials cache.   The various worlds need not communicate or trust
each other at all.

http://www.meerkatviewer.org/whitepaper.pdf
http://www.meerkatviewer.org/whitepaper.odt

---

From: Gareth Nelson <[email-masked]>
Date: Thu, 26 Mar 2009 12:49:26 +0000

This makes me think if we split the problem into 3 basic areas:
1 - Authentication
2 - Teleport/moving avatar
3 - Moving content

Then the meerkat approach works very well for number 1.
For point 2, I believe we need to start discussing some of the down
and dirty details now, since it is much simpler to move an avatar than
it is to move content.
Ultimately, to pull this off will require some kind of standard
protocol for sticking an avatar in an environment and getting back a
description of that environment for rendering. Something that can be
implemented as an extension to existing VW servers would do the trick,
i'm picturing an extra ClientStack module in opensim for example, or
even a proxy that sits in some VW provider's network and does protocol
translation.

The focus should be on 3D worlds for this work - since it does not
make sense to TP between 2D and 3D worlds.

What I propose is this, upon TPing to world A from world B, the client
may maintain a connection to world A to keep IMs etc (agent domain for
the win), but disconnects from any simulators or equivalents on world
A. It then connects to world B and receives an initial scenegraph or
just a big array of objects defined using meshes or prims (a combo of
both seems the most efficient way to do things). Then updates to that
scenegraph are sent as needed by the server, just saying "object #354
is now at position <235.0, 12.7,100.3> with a rotation of
<0.0,91.2,0.0> and a directional velocity of <11.0,0.0,0.0>" with some
kind of efficient binary protocol. Extensions for things such as
inworld scripts can be added at a later date - but this is the basic
stuff.

2009/3/25 Jason Giglio <[email-masked]>:
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>
>

---

From: Morgaine <[email-masked]>
Date: Thu, 26 Mar 2009 15:11:15 +0000

> http://www.meerkatviewer.org/whitepaper.odt

The above document seems remarkably insightful on various fronts:

   - It highlights that placing your assets under the control of an identity
   provider is a poor model as it inappropriately couples distinct issues.
   Identity and assets should be decoupled so that each can be supplied by
   different parties.
   - Indirectly, it highlights that the Agent Domain model does not have a
   solution to the problem of accessing worlds with which there is no trust
   agreement.  People will want to enter arbitrary worlds, and therefore that
   restriction is inadequate.
   - There will be millions of worlds in an Internet-scale metaverse, which
   makes the concept of interop through trust agreements far too narrow.  Trust
   loses its meaning entirely when scaled to millions, becoming mere paperwork
   or "*security theater*".
   - It notes that many of the complexities of the OGP protocol disappear
   when the client handles its own cross-world login and identity management,
   transparent to the user of course.
   - It also notes that it is the user who is best placed to determine which
   world has the rights to see her assets, since by choosing to enter a given
   world you are implicitly agreeing that its inhabitants have the right to see
   you --- that's inherent.
   - It promotes the concept of decoupled services generally, which is a
   goal to which I believe we all subscribe.

The user and engineering benefits of this scheme seem a lot more promising
than those of the officially presented proposals so far, and it has the
added benefit of being compatible with most of the client-oriented VW
architectures that we have discussed.  In particular, it would work with a
decoupled-asset form of OGP.

It also reflects that this is where the open source movement is heading
quite naturally.  It is a common propensity of FOSS developers to add new
interface mechanisms to their clients to widen their user base and
usefulness.

What's more, the scheme is even compatible with the LESS interop model,
because such a multi-service client could easily connect to LESS either
directly or through a compatible proxy.  The fact that a hypothetical LESS
world provider might not allow foreign clients or proxies to access its
services is just a matter of policy choices, and does not affect this
argument about mechanisms.

Morgaine.

2009/3/25 Jason Giglio <[email-masked]>

---

From: "Hurliman, John" <[email-masked]>
Date: Thu, 26 Mar 2009 20:17:24 -0600

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Morgaine
>Sent: Thursday, March 26, 2009 8:11 AM
>To: Jason Giglio
>Cc: MMOX-IETF
>Subject: Re: [mmox] Loosely Coupled Virtual Worlds
>
...
>
>*	Indirectly, it highlights that the Agent Domain model does not
>have a solution to the problem of accessing worlds with which there is
>no trust agreement.  People will want to enter arbitrary worlds, and
>therefore that restriction is inadequate.
>*	There will be millions of worlds in an Internet-scale metaverse,
>which makes the concept of interop through trust agreements far too
>narrow.  Trust loses its meaning entirely when scaled to millions,
>becoming mere paperwork or "security theater".
 
This is, in my opinion, the fundamental flaw in OGP. Explicit trust maps (whitelists) work great when IBM wants to define policy to connect to the Linden Lab grid, but has no meaning and no hope of scaling when you talk about defining trust for millions of simulation grids and millions (or at least thousands) of identity providers. This is the primary reason that Intel and many members of the OpenSimulator/OpenMetaverse community have not considered OGP as a strong proposal for virtual world interoperability. If this understanding is not accurate, it would be helpful if an OGP author could step in and clear up the confusion.

John

---

From: Charles Krinke <[email-masked]>
Date: Fri, 27 Mar 2009 06:02:08 -0800

I think what is happening here is we have half of a solution that needs a
bit more symmetry.

A citizen from a SecondLife grid can certainly connect today to an OpenSim
grid or standalone using the Agent Domain notion. But, a citizen from an
OpenSim grid such as OSGrid cannot cannot to a SecondLife grid in a
symmetrical fashion as there is no Agent Domain notion in OpenSim.

I look at this and think more along the lines of passports and border
crossings between virtual countries.

Using this metaphor, there needs to be a handoff of an avatar from one grid
to another grid for simulation. Now, I can see some notions of a circuit
connected back to ones home grid for certain authentication and object
inventory issues, but in general this is a border crossing between
countries.

When I mean symmetry, I also mean that a citizen of a SecondLife grid may
enter a region on OSGrid, but similarly, I would expect a citizen of OSGrid
to be able to enter a SecondLife grid. Else this interoperability is one way
and not advantageous to both parties.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Thu, Mar 26, 2009 at 6:17 PM, Hurliman, John <[email-masked]>wrote:

> This is, in my opinion, the fundamental flaw in OGP. Explicit trust maps
> (whitelists) work great when IBM wants to define policy to connect to the
> Linden Lab grid, but has no meaning and no hope of scaling when you talk
> about defining trust for millions of simulation grids and millions (or at
> least thousands) of identity providers. This is the primary reason that
> Intel and many members of the OpenSimulator/OpenMetaverse community have not
> considered OGP as a strong proposal for virtual world interoperability. If
> this understanding is not accurate, it would be helpful if an OGP author
> could step in and clear up the confusion.
>
> John

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: "Mystical Demina" <[email-masked]>
Date: Fri, 27 Mar 2009 12:15:21 -0400

I just wanted to add I can see the agent being on the same computer that is
running the rendering which would typically being a client which would know
how to pass any needed references to one ore more locations inventory could
be utilized from, including my local disk.  Although not sure why the
simulator would need access to inventory, seems this agent will handle any
request for a particular object and provide it to the simulator which would
allow inventory to come from any other computer in the world.

Or this agent may be a proxy for my client who would run on a server I am
logged into and handle these negotiations.

It is my opinion we need to move past the idea of the inventory being
something owned by a grid and more to a source of an objects that I have
access to that can be used into a simulator.  This object(s) could be copied
and cached into the simulator or it could be a proxy, and to some degree at
least some if it probably need to be, it can be a shell of the object that
is actually instantiated somewhere else and provided once or updated in a
steam of information that could be multiple times a second or long term like
daily or more; or event driven.

Some thoughts.

Kevin Tweedy

SL: Mystical Demina

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Charles Krinke
Sent: Friday, March 27, 2009 10:02 AM
To: Hurliman, John
Cc: MMOX-IETF
Subject: Re: [mmox] Loosely Coupled Virtual Worlds

Charles Krinke
OpenSim Core Developer
OSGrid Director

...

John

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Charles Krinke <[email-masked]>
Date: Fri, 27 Mar 2009 08:28:04 -0800

We have had this discussion on and off for a couple of years now on OpenSim
regarding where objects should be stored.

In general, it is argued that objects unique to an avatar are best stored in
an avatar-unique manner, be that a home grid, a home region, or a USB thumb
drive.

But, also in general, it is argued that objects that need to be interacted
with by *other* then the owner, need to be stored in a manner that allows
this interaction.

>From the OpenSim viewpoint, we have headed down a hybrid approach for grid
objects or assets. Some assets are stored on the local region hard disk,
some are stored on a gridserver complex if this region is part of a grid.

>From the interop viewpoint, I would think each virtual world, or
instantiation of a software that supports a virtual world would need to deal
with this with their own vision in mind. I would not presume to tell
SecondLife how they should or should not store objects and assets. For the
purpose of this group, I would tend to focus on how we may interact with
other existing virtual worlds implementations such as chat, teleport,
presence and devolve the asset storage for the most part back to the
architecture making up the virtual world.

Charles Krinke
OpenSim Core Developer
OSGrid Director

2009/3/27 Mystical Demina <[email-masked]>

>  I just wanted to add I can see the agent being on the same computer that
> is running the rendering which would typically being a client which would
> know how to pass any needed references to one ore more locations inventory
> could be utilized from, including my local disk.  Although not sure why the
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Charles Krinke
> *Sent:* Friday, March 27, 2009 10:02 AM
> *To:* Hurliman, John
>
> *Cc:* MMOX-IETF
> *Subject:* Re: [mmox] Loosely Coupled Virtual Worlds
>
>
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: "Mystical Demina" <[email-masked]>
Date: Fri, 27 Mar 2009 13:55:16 -0400

But not all inventories may originate from a virtual world.

Or be from one virtual world.

Just trying to open up what seems to be an assumed position.

The current model also limits content providers and adds a lot of overhead
and cost to content delivery and updates.  For instance if I am a content
provider will we require my customers to first upload their inventory into a
specific grid before it can be used.  What about updates and fixed?  Would
be much each if I simply upload my fix and all references to it are able to
get the updated instead of this model in SecondLife where I have to
distribute my product to every person that buys for them to rez it again,
remove the old, all that kind of stuff.   And then there is the content of
dynamic content that will be changing as part of the service that is
provided.  Granted some of that may be done with scripting but I can see
models where my content is specific to a user, to time a day, to other
factors and different content would be provided by the same request for the
inventory item.

I respect your experience with OpenSim but having 15 years of internet
experience and 27 years of software industry experience and I believe Darwin
always wins in the end and to me that will be what ever the least costly,
easiest model, quickest to implement solution that will ultimately be the
direction.  I would suggest the current direction isn't really addressing
the cost and management of content and will not scale to 1000s of grids.

Kevin Tweedy

SL: Mystical Demain

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Charles Krinke
Sent: Friday, March 27, 2009 12:28 PM
To: Mystical Demina
Cc: MMOX-IETF
Subject: Re: [mmox] Loosely Coupled Virtual Worlds

Charles Krinke
OpenSim Core Developer
OSGrid Director

Some thoughts.

Kevin Tweedy

SL: Mystical Demina

  _____  

Cc: MMOX-IETF

Charles Krinke
OpenSim Core Developer
OSGrid Director

...

John

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Morgaine <[email-masked]>
Date: Sat, 28 Mar 2009 02:22:31 +0000

I agree strongly with Mystical Demina on this subject.  In a metaverse of
potentially millions of virtual worlds and thousands of providers, it makes
no sense whatsoever for a person's inventory to be held always by your
identity provider (except by choice).  This is bad service factoring.

Your inventory will hold objects from any number of different worlds, and
this will also apply to your avatar's clothing and objects worn or held when
moving or teleporting between worlds.  Using OGP terminology, the Agent
Domain service that provides your identity bears no strong relationship with
the worlds from which your inventory items originate --- indeed, you may
have no items at all from the world(s) of your AD provider.

A good approach here would be to define a separate service dedicated to
handling inventory objects or assets.  OGP's two domains of Agent Domain and
Region Domain should be expanded with a third, an Object Domain offering
object or asset services.  Such decoupling will allow users to choose their
own asset providers (potentially more than one at a time) to provide the
level of service they require and add competition on quality and cost.
Running one's own asset service is also an important option.

Note that for symmetry your inventory should also be an object, namely a
hierarchical container.  This should be storable either locally or at any
chosen asset provider(s).

Morgaine.

> direction.  I would suggest the current direction isn’t really addressing
> *Sent:* Friday, March 27, 2009 12:28 PM
> *To:* Mystical Demina
>
> *Cc:* MMOX-IETF
> In general, it is argued that objects unique to an avatar are best stored
> in an avatar-unique manner, be that a home grid, a home region, or a USB
> thumb drive.
>