Re: [mmox] Loosely Coupled Virtual Worlds

"Mystical Demina" <MysticalDemina@xrgrid.com> Fri, 27 March 2009 16:14 UTC

Return-Path: <MysticalDemina@xrgrid.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1633A6C80 for <mmox@core3.amsl.com>; Fri, 27 Mar 2009 09:14:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.153
X-Spam-Level:
X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Rm6WAPGABar for <mmox@core3.amsl.com>; Fri, 27 Mar 2009 09:14:41 -0700 (PDT)
Received: from k2smtpout01-01.prod.mesa1.secureserver.net (k2smtpout01-01.prod.mesa1.secureserver.net [64.202.189.88]) by core3.amsl.com (Postfix) with SMTP id 7C9CD3A6824 for <mmox@ietf.org>; Fri, 27 Mar 2009 09:14:41 -0700 (PDT)
Received: (qmail 21165 invoked from network); 27 Mar 2009 16:15:36 -0000
Received: from unknown (HELO TWEEDY001.kevin-tweedy.com) (68.178.225.179) by k2smtpout01-01.prod.mesa1.secureserver.net (64.202.189.88) with ESMTP; 27 Mar 2009 16:15:35 -0000
Received: from KEVINPC ([173.49.10.182]) by kevin-tweedy.com with MailEnable ESMTP; Fri, 27 Mar 2009 09:15:31 -0700
From: Mystical Demina <MysticalDemina@xrgrid.com>
To: 'MMOX-IETF' <mmox@ietf.org>
References: <49CAAACF.8030208@gmail.com><e0b04bba0903260811s765643b1q5ffcb51ff0a90429@mail.gmail.com><62BFE5680C037E4DA0B0A08946C0933D72A1E3FC@rrsmsx506.amr.corp.intel.com> <f0b9e3410903270702h102952f8t89da7052a70fd4f9@mail.gmail.com>
In-Reply-To: <f0b9e3410903270702h102952f8t89da7052a70fd4f9@mail.gmail.com>
Date: Fri, 27 Mar 2009 12:15:21 -0400
Message-ID: <C6197B866A3440CC9339834A812783C6@KEVINPC>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C9AED5.B3C0E4C0"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acmu5J5lCz6Ny7IPTJ6V8BLsabiESAAEW0FQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049
Subject: Re: [mmox] Loosely Coupled Virtual Worlds
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 16:14:43 -0000

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: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] 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

 

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 <john.hurliman@intel.com>
wrote:

>-----Original Message-----
>From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] 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
>
>On 2009/3/25, Jason Giglio <gigstaggart@gmail.com> wrote:
>
>
>       http://www.meerkatviewer.org/whitepaper.pdf
>       http://www.meerkatviewer.org/whitepaper.odt
>
>
>
>
>The above document seems remarkably insightful on various fronts:
>

...
>
>*      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

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox




-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director