Re: [mmox] MMOX: Strawman scope/goals/approach

"Meadhbh Hamrick (Infinity)" <> Wed, 25 February 2009 00:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E5D728C272 for <>; Tue, 24 Feb 2009 16:59:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.523
X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RJpKB9orICLx for <>; Tue, 24 Feb 2009 16:59:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8DE7128C251 for <>; Tue, 24 Feb 2009 16:59:45 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id F13263DBC44D; Tue, 24 Feb 2009 17:00:03 -0800 (PST)
Message-Id: <>
From: "Meadhbh Hamrick (Infinity)" <>
To: Christian Scholz <>
In-Reply-To: <>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 24 Feb 2009 17:00:02 -0800
References: <><> <>
X-Mailer: Apple Mail (2.930.3)
Subject: Re: [mmox] MMOX: Strawman scope/goals/approach
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Feb 2009 00:59:48 -0000

cool. lemme put on my linden hat and throw out my US$0.02...

in terms of identity, we have a strong preference for authenticating  
application to application. part of the reason we like this is we have  
a requirement that our HTTP traffic be able to flow over proxies (of  
both the SOCKSish variety and the squidish caching variety.) we are  
therefore paranoid that somewhere, somehow, transport layer  
authentication information would be "eaten" by a misconfigured or  
miscoded piece of required infrastructure. we understand that many  
people deploying VW applications may not have this requirement, but we  
kindly ask people to respect our requirements. but... just because we  
have defined an application-layer-endpoint to application-layer- 
endpoint authentication protocol does not mean we're going to try to  
ram it down everyone else's collective throats. OpenID, OAuth, PKIX  
client certs and even *shudder* gss-api all have a place in the world,  
and that place may include authenticating endpoints in virtual world  

in terms of non-second-life-like systems... yes... some people may  
remember that Zero and I are both "smalltalk people" and have been  
working with squeak from the early days. i mention it only to  
contextualize the discussion with respect to croquet and some the  
related commercial ventures (like qwaq.) personally, i like croquet  
and have for a while. like any system it has it's benefits and its  
drawbacks, but more germane to this discussion, uses an interaction  
model that is slightly different than the one second life uses.  
however... there's a statement in the draft charter identifying the  
focus of this group as being "application layer wire protocols," and  
to the degree that this statement survives the WG formation process...  
i would hope we could define wire protocols that were independent  
enough of the interaction model to at least allow some reuse of the  
PDUs. if there was a way to make TObjects look like REST-like  
resources we might be able to go further and reuse some of the  
interaction model. (but i'm just offering it as a suggestion! i'm not  
saying croquet has to change to be more SL like before we'll play nice  
with you!) and who knows... maybe after detailed investigation of both  
system's interaction models, we could find a way to denote them both  
with the same representational system.

with respect to service discovery... the "SL mode" right now is to  
assume a list of services. ultimately this has got to change, and we  
know that. that was part of the motivation for the design behind OGP/ 
Auth. At the end of authentication, the client is in possession of a  
capability (protocol endpoint) from which it may request other  
capabilities (protocol endpoints) that address resources which may be  
accessed to request various services. all of the services CS mentions  
below could easily be implementable with this technique. i've heard  
from some quarters that capabilities give some people the willies and  
honestly... they gave me the willies too until i drank the kool-aide  
and started using BREW a couple years back. i would point out,  
however, that they've been in constant use with SL for over 5 years  
now and they tend to work quite well for us. ultimately, however,  
there are likely going to be some people who won't want to use them  
and sure... that's fine... what this means to me vis a vis protocol  
definition is we should separate the acquisition of a service endpoint  
from the service it enables. and this might be was CS was talking  
about below.

or it might have been about service versioning that came up from time  
to time in the PyOGP list. fwiw... we tend to be "chunky" in our  
service deployment, meaning we prefer to not operate several versions  
of related services simultaneously, but i'm sure we can come up with a  
way to create a versioning system in MMOX, and i warn people up front  
that enabling such functionality would likely be a tough sell at  
linden, but we wouldn't stand in the way of other virtual worlds  
operators / client developers wanted to add it to a spec we claim we  
want to adhere to. but just keep in mind we're likely to either  
strongly request the feature was optional or use it in such a way that  
our grid always looks like it only has a single version of each service.

merging social networking sites and virtual worlds sounds like a win,  
but i wonder if it's not a better idea for the two to develop  
separately and allow protocols in each area to reference each other.  
for example, OpenSocial is, as i understand it, currently implemented  
as a set of web-apis. i really like the idea of an opensocial app  
being able to "reach into the virtual world" and i like the idea of  
our virtual world supporting things like existing OpenSocial apps...  
let's just not make it a REQUIRED part of the protocol anytime soon.

so... to paraphrase... to the degree that linden can be the 800 lb.  
gorilla in a room where virtual worlds are being discussed and  
blizzard hasn't shown up... i promise to use my secret powers for  
good. the lab has no interest in scuttling anyone else's product  
roadmap but we ask that the more agile participants in this group give  
us a little slack with what we're able to implement and how fast.  
compared to the open sim peeps, we must seem like dinosaurs, and  
compared to tao, we're probably stromatolites. i just ask that peeps  
here please keep in mind we have an onerous repository of legacy code  
and a large installed base we can't abandon, so there's a reason we're  
moving slower than people might like.


On Feb 24, 2009, at 3:31 PM, Christian Scholz wrote:

> Mark P. McCahill schrieb:
>> +1
>> I really like the approach David is taking here. The first two items:
>>  * managing identity
>>  * naming and authenticating services in MMOX worlds
>> are prerequisites for getting anywhere with cross-system  
>> interoperability,
>> would benefit users of existing systems, and should be achievable  
>> in the
>> fairly near term. Understanding how to negotiate these services is  
>> the
>> place to start, rather than defining an abstract wire-level  
>> protocol, if
>> the intent is to bring something other than Second Life-like worlds  
>> into
>> the fold.
> +1 and I would actually list:
> - defining an identity endpoint
> - service discovery to find services for this identity such as profile
>   definition, friends list, inventory server, ...
> - distributed authorization
> Then having a way defined for services to be found and authorized  
> one could define the specifics of these services.
> I would extend this beyond MMOX worlds though because there is huge  
> interest in the web and social networking players as well.
> So maybe a seperate working group which has not the focus so much  
> just on virtual worlds for this part might make sense. But I have no  
> idea about the IETF process anyway at this time and if and how this  
> would be possible or wanted.
> -- Christian
>> Mark McCahill
>> On Feb 24, 2009, at 11:04 AM, David W Levine wrote:
>>> 1.        The ability to manage one's identity when interacting in  
>>> multiple MMOX spaces.
>>>       a.        Allowing presence information to be shared and  
>>> coordinated across
>>> MMOX spaces
>>>       b.        Permitting friends lists, and IMs to be shared  
>>> across spaces
>>>       c.        Permitting MMOX spaces to share naming
>>>       d.        Simple ways of allowing a consistent name, managed  
>>> by the user, and
>>>               verifiable by other users
>>>       e.        Single sign on, mediated by multiple spaces,  
>>> within the policy constraints
>>>               of the spaces
>>>       f.        A consistent appearance, within the constraints of  
>>> the various systems
>>>       g.        The ability to manage the degree of visibility /  
>>> coupling between identities
>>>       in MMOX spaces
>>> Note that for all of these, there is no requirement to couple the  
>>> systems together
>>> beyond managing identity, and share presence and IM information.  
>>> These use
>>> cases don't speak to how you move between spaces. You may have to  
>>> shutdown
>>> your client on one system and start another. This also is not a  
>>> "You must enable
>>> this" this is very much a "Make it easy for spaces which want to  
>>> enable this to do
>>> it." Also, note that "presence and messaging" speak to user needs,  
>>> and consitent
>>> appearance and name (when desired by users) again speeks to  
>>> meeting user's
>>> desires.
>>> 2.        The ability for the services in an MMOX world to be  
>>> named, and authenticated
>>>       a.        Services to associate virtual places and the  
>>> services which support them
>>>       with authentication and administrative domains
>>>       b.        Services to permit a service to validate the  
>>> membership of a remote
>>>       service in one or more authentication and administrative  
>>> domains
>>> This is needed so that we can do essentially any of the  
>>> interoperability work.
>>> Without some framework which lets us know who we are talking to,  
>>> it is
>>> impossible to trust the behavior of distributed systems.
>>> 3.        The ability to share content between MMOX spaces
>>>       a.        Import and Export of content and models (This may  
>>> well leverage off of
>>>       existing work such as Collada) Static, import/export of  
>>> content while not
>>>       terribly dramatic is an important part of the value chain of  
>>> interoperability
>>>       b.        Mark up schemes which recognize the existence of  
>>> multiple presentation
>>>       environments, but permit the sharing of content
>>>               i.        Shared "type" information for the various  
>>> types of graphical
>>>                       content which MMOX spaces contain
>>>               ii.        Extensible, with a common registry, so  
>>> that we can understand the
>>>                       types of contents a client can accept, and a  
>>> virtual space, or virtual
>>>                       asset store can be asked to provide
>>>       c.        A MMOX based, system independent asset addressing  
>>> scheme which includes
>>>               i.        Content negotiation based on 2b
>>>               ii.        Access Management based on (1) and (2)
>>> This is, to my mind, the key mid term deliverable
>>> 4.        The affordances in MMOX to permit the creation of micro- 
>>> payment economies
>>>       a.        Appropriate spots defined in MMOX protocols for  
>>> cost information
>>>       b.        Appropriate spots defined in MMOX protocols for  
>>> reference to
>>>               micropayment systems
>>> 5.        The ability to share "non immersive streams" between  
>>> spaces
>>>       a.        Markup to permit the consistent sharing of stream  
>>> media such as voice,
>>>               and video, with shared start and synchronization  
>>> information to permit
>>>               "parallel" events between MMOX space
>>> 6.        The ability to express Policy intent between MMOX  
>>> services and virtual spaces
>>>       a.        Places in reserved in the MOX protocols for  
>>> expressing policy intent
>>>       b.        One or more policy languages for expressing policy
>>> The solution space:
>>> Most of the deployed solutions partition the software problem into  
>>> the following chunks.
>>> 1.        Some form of a client which permits a user to interact  
>>> with the shared experience
>>> 2.        Virtual space servers which manage the state of a  
>>> portion of virtual space
>>> 3.        A set of supporting services used by the virtual space  
>>> servers
>>> Note that exactly how these three large chunks are assembled and  
>>> the granular nature of
>>> the services can vary radically, even when serving very similar  
>>> environments. Some
>>> environments push a large amount of rendering and management onto  
>>> complex clients,
>>> others perform the bulk of rendering in the server portion of the  
>>> deployment. Some
>>> implementations combine client and simulation into a single entity  
>>> which does some
>>> simulation and some user presentation. Some distribute the  
>>> simulation, some centralize it.
>>> The heart of most of the solutions is managing to accept and merge  
>>> a stream of updates,
>>> and then distribute the merged updates back to users. This can  
>>> happen at a range of
>>> granularities. The two ends of the spectrum, are, roughly, sending  
>>> updates as a fully
>>> merged audio visual stream, which the client merely displays, and  
>>> sending low level
>>> changes to a underlying mode, which the client uses to assemble a  
>>> complete visual
>>> representation of the scene.  Variations include croquet and qwaq  
>>> which use an
>>> underlying distributed object model to pass large amounts of  
>>> updates, and approaches
>>> such as used by SecondLife and Protonsphere, where voice is  
>>> managed in a separate
>>> service, with the merged state service merely letting the voice  
>>> service know where the
>>> users are located.
>>> Closely related, are issues of representation and format of  
>>> content. This takes several,
>>> separable forms. Import and Export of material to the core  
>>> environment, and, more
>>> problematically, run time representations
>>> Approach
>>> Our overall approach should be web centric, and web services  
>>> oriented. We can, and
>>> should think of sets of related services which can be composed as  
>>> part of different
>>> solutions which will enable varying degrees of interoperability.  
>>> We can, and should
>>> attempt to provide as web like an approach to function as  
>>> possible. Content negotiation,
>>> separation of protocol from security, separation of interface from  
>>> implementation and
>>> other techniques.
>>> Our goal is not to enshrine any single virtual world as the  
>>> standard for all MMOX spaces,
>>> but rather create a flexible, extensible set of services which  
>>> will allow us to grow larger
>>> and large overlapping sets of capabilities. My expectation is that  
>>> we will see a lot of low
>>> hanging fruit in the area of identity, authentication,  
>>> authorization and presence
>>> management (Where a user is, and allowing messaging to them across  
>>> MMOX spaeces)
>>> and initially, we will find a lot of format and content area  
>>> addressed by gateways,
>>> markup, and content negotiation. I see nothing wrong with having a  
>>> URI which refers to
>>> "A pretty maple tree with fall colors" which provides a way to  
>>> fetch the "Collada Style
>>> version" the "3dMax Mesh version" the "Linden Lab 1.2 sculpty spec  
>>> version"  such that
>>> a virtual space can select, through content negotiation the one  
>>> most useful to it.
>>> We get value, when we have consistent ways of referring to all the  
>>> various forms of
>>> content, and we get more value when we have ways of using existing  
>>> content negotiation
>>> to allow a web light selection of an appropriate form. It is  
>>> equally possible to imagine
>>> negotiating between a client and a virtual space, the desired form  
>>> of objects. There are
>>> some deep challenges lurking, such as when two different  
>>> approaches have radically
>>> different
>>> What I would encourage us, as a mailing list to do, is look  
>>> through the problem
>>> statement, and interoperability goals I've put together here. They  
>>> are an attempt to
>>> capture the various sentiments in the ongoing discussion. I am  
>>> sure I have missed points,
>>> and I am sure some people will disagree with some of the points I  
>>> have made.
>>> I would ask people to look for "No, you missed X" and "Hey, I  
>>> don't think Y" is true. I
>>> will attempt to capture all of those, and revise the document,  
>>> until we think it represents
>>> something close to the general group consensus. (I am not looking  
>>> for 100% consensus,
>>> but a "Yeah, this captures most of what we're trying to do." With  
>>> that in hand, I would
>>> suggest we could then begin to enumerate the specific services and  
>>> markups we need to
>>> support our goals, and begin to flesh out use cases to help us  
>>> understand the goals and
>>> services.
>>> I do not expect this to yield a set of specs which Linden Lab, or  
>>> OpenSim, Or any one
>>> virtual world vendor or project would implement whole. What I  
>>> expect it to yield is a set
>>> of specs, which can be combined with existing projects and code  
>>> bases to drive us
>>> towards a more interoperable future.
>>> Out of scope
>>> I also want to begin to accumulate a short list of "No, this is  
>>> out of scope" assertions
>>> 1.        We will provide all the affordances necessary to permit  
>>> a broad range of
>>> interaction policies. Appropriate policies for various deployed  
>>> solutions and
>>> future deployed solutions is out of scope, beyond providing us use  
>>> cases which
>>> highlight specific affordances we may wish to consider
>>> 2.        Whether or not immersive multi-party spaces are useful  
>>> and which specific
>>> capabilities are required is out of scope. We aspire to support a  
>>> broad range of
>>> possible capabilities, and we respect that different organizations  
>>> will have
>>> different perspectives on what is required. Our goal is to define  
>>> broad,
>>> interoperable frameworks which will enable a range of deployments,  
>>> not to define
>>> the one true model for this space
>>> 3.        Propose additional statements here
>>> Closing comments
>>> I don't think our collective goal can be to take any one existing  
>>> spec or solution and
>>> simply declare it the basis for our work going forward. At the  
>>> same time, we must base
>>> our work in actually running code, showing real interoperability.  
>>> Our goal must be to
>>> build supersets of function, based on existing products and  
>>> solutions which demonstrate
>>> real interoperability.
>>> The IETF favors working code and growing consensus over blank  
>>> paper and blue sky
>>> efforts. This is based in a history of success and failure in the  
>>> industry when it comes to
>>> building, promoting and succeeding at standards work. Work at the  
>>> IETF is grounded in
>>> working code.
>>> One way forward is to focus on several clusters of work. One: a  
>>> clear, broad framework,
>>> which forms the basis for long term broad interoperation. Two:  
>>> Capturing the current set
>>> of incompatible and overlapping formats and protocols in use, so  
>>> that we can create a
>>> extensible and shared catalog of artifacts for sharing. (eg. "Here  
>>> is the canonical,
>>> extensible  list of graphic content types you might want to move  
>>> on a MMOX transport"
>>> Three grow out  proposed solutions such as LLSD, OGP, and others,  
>>> as they are
>>> contributed towards a common superset which can be used to as the  
>>> basis for
>>> demonstrating concrete progress towards interop goals. Four,  
>>> Identify places where we
>>> simply want to use existing work, such as OpenID, OAuth,  X.509   
>>> and create a shared
>>> profile for how we can use these protocols to further  
>>> interoperability.
>>> <Scope01C.txt><Scope01C.doc>
>>> _______________________________________________
>>> mmox mailing list
>> _______________________________________________
>> mmox mailing list
> -- 
> Christian Scholz
> Blog:
> Company:
> Podcasts:,
> _______________________________________________
> mmox mailing list