Re: [mmox] Loosely Coupled Virtual Worlds

Morgaine <morgaine.dinova@googlemail.com> Thu, 26 March 2009 15:10 UTC

Return-Path: <morgaine.dinova@googlemail.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 E791528C0FD for <mmox@core3.amsl.com>; Thu, 26 Mar 2009 08:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.746
X-Spam-Level:
X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 bcLSv3jwsoZ1 for <mmox@core3.amsl.com>; Thu, 26 Mar 2009 08:10:23 -0700 (PDT)
Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 219E43A6DFD for <mmox@ietf.org>; Thu, 26 Mar 2009 08:10:22 -0700 (PDT)
Received: by ewy9 with SMTP id 9so614114ewy.37 for <mmox@ietf.org>; Thu, 26 Mar 2009 08:11:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+D44ogm8RY24YRvMcS7y/OHXrPIL3qTSvFQjSNHdw+M=; b=TpEG1G3y8525mCXC/NTVu661M5L4Tg81nkjlAHbSGD9NOTv6LXoXsXvkoK1+99jaSP ESdi0Mmi+JkL0yWcWgCHqsm6PodwkwAmMw0LAoMhGgyjCUR75tC0ECN2cIWi4/INhRVG VHc2IjKuGDY0/Ybl8oe8o0O9Kbj9ydWEHpmBA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XSktz4QjE7NGxw0RkWDVCV0auZrOJJwVdQTJGiY9mRT/7CqpoSsQ7RSxZqfuRlrNew vhpWHzHxpMFn6zqEJed32jbbMTjAQHp/1Kqd3lKt/cCk2VRY9hyNrbpKkbcznAkHRWvm aUoLmFdY5+ObYlkDPAmqezJXwr4j68u9FHTJ4=
MIME-Version: 1.0
Received: by 10.210.52.15 with SMTP id z15mr740278ebz.87.1238080275106; Thu, 26 Mar 2009 08:11:15 -0700 (PDT)
In-Reply-To: <49CAAACF.8030208@gmail.com>
References: <49CAAACF.8030208@gmail.com>
Date: Thu, 26 Mar 2009 15:11:15 +0000
Message-ID: <e0b04bba0903260811s765643b1q5ffcb51ff0a90429@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: Jason Giglio <gigstaggart@gmail.com>
Content-Type: multipart/alternative; boundary="0015174be84c004d1c0466070795"
Cc: MMOX-IETF <mmox@ietf.org>
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: Thu, 26 Mar 2009 15:10:25 -0000

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:


   - 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 <gigstaggart@gmail.com>

> 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
>
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>
>