Re: [mmox] OGP scalability concerns

"Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com> Thu, 02 April 2009 22:21 UTC

Return-Path: <infinity@lindenlab.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 5B8873A6A71 for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 15:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.228
X-Spam-Level:
X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1]
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 bjeT5M6ubuyS for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 15:21:14 -0700 (PDT)
Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id DDBFC3A68DD for <mmox@ietf.org>; Thu, 2 Apr 2009 15:21:14 -0700 (PDT)
Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id A035F3DBC05E; Thu, 2 Apr 2009 15:22:16 -0700 (PDT)
Message-Id: <D61EE1DB-11DF-4471-A000-9104CD11B219@lindenlab.com>
From: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
To: "Hurliman, John" <john.hurliman@intel.com>
In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Thu, 02 Apr 2009 15:22:16 -0700
References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <CD02023C-3E7B-4E76-8429-11035C827E53@lindenlab.com> <f0b9e3410904011701i2ccb03d4r1b48d33cfe3988ea@mail.gmail.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com>
X-Mailer: Apple Mail (2.930.3)
Cc: "mmox@ietf.org" <mmox@ietf.org>, Jon Watte <jwatte@gmail.com>
Subject: Re: [mmox] OGP scalability concerns
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, 02 Apr 2009 22:21:16 -0000

i think the way we were initially thinking about it is that "the agent  
domain" is the group of systems / interfaces that house information  
unique to or focused on agent based services while the "region domain"  
was the hypothetical place where virtual space based services lived.  
we proposed that division because services like identity, profiles,  
groups, presence, affiliation, group or proximal chat, item scheduling  
(i.e. - rezzing), avatar movement and instantiation, etc. all  
generally scale along the agent or virtual land / space axis. (they  
DEFINITELY do in second lifelike systems, and i would argue they also  
do in most other architectures.) in our nomenclature, we would  
probably refer to IM, presence, etc. as being "services" of the domain  
which most constrains their scaling behavior.

so for example, if you built a group IM system that requires you to  
authenticate yourself to whomever manages your virtual identity, the  
servers on the back end would encounter scaling problems as the number  
of groups (and presumably also the number of agents) grew. that's why  
_we_ call group IM an agent domain service.

we also use the term "domain" in it's more traditional sense to imply  
a bounds of authority. which is to say, we assume that all hosts and  
services inside a domain are administered by the same entity. that  
being said, there's no reason you can't have sub-domains, and there's  
no reason that two services associated with "the" agent domain can't  
be split across two administrative domains (like maybe yahoo or AOL  
get in the business of moving virtual world IM messages but don't want  
to deploy a world themselves.) it would require some coordination of  
identity management issues, but i'm sure they're tractable.

On Apr 2, 2009, at 2:02 PM, Hurliman, John wrote:

> Thank you Christian, I think this is the right approach. Using  
> partially defined blanket terms such as "Agent Domain" or "Region  
> Domain" conjure up different ideas in everyone's head and also tend  
> to imply an unnecessary aggregation of services. If we can clearly  
> define the actual work items such as identity, authentication,  
> authorization, asset storage, asset representation (content types  
> and metadata), communication and contact lists, etc. we would likely  
> find much more common ground between parties and could start  
> partitioning the work into manageable sized chunks.
>
> John
>
>> -----Original Message-----
>> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf
>> Of Christian Scholz
>> Sent: Thursday, April 02, 2009 1:05 PM
>> To: Jon Watte
>> Cc: mmox@ietf.org
>> Subject: Re: [mmox] OGP scalability concerns
>>
>> Jon Watte schrieb:
>>> Meadhbh Hamrick (Infinity) wrote:
>>>> so maybe we might say "virtual world avatar interop" or "virtual
>>>> world event stream interop"?
>>>>
>>>> but not say "virtual world interop" 'cause it's too vague?
>>
>> I would say that in fact we have quite a few areas where
>> interoperability is possible if we start to cut the problem space  
>> into
>> smaller chunks.
>>
>> Here are some:
>>
>> - Identification (who is this agent?)
>> - Profiles (information about the logged in user)
>> - friends/contacts (probably most worlds have this)
>> - group memberships (not every world might have this)
>> - (instant) messaging
>> - presence
>> - Assets such as textures/photos/sounds etc.
>>
>> Now if you take those than we can discuss what interoperability means
>> for each of them. In fact there are many formats/protocols already
>> available:
>>
>> - OpenID, InformationCards etc. for identification
>> - OpenSocial RESTful API or PortableContacts (the same protocol) for
>> profile and contacts (in a limited fashion at least)
>> - XMPP or IRC (and other proprietary formats) for instant messaging.
>> Might also include presence although maybe this needs to be extended.
>> - SMTP for not so instant messaging
>>
>> So in fact for some areas interoperability would already be possible.
>> It would at least allow a user with an account on service A to login
>> to service B and maybe be able to match contacts, chat with people on
>> other services and so on.
>>
>> And basically what is describes then is a simple social network. If
>> you add 3D services on top then you have your virtual world and this
>> is where it becomes complicated.
>>
>> If you take the above elements you also have an Agent Domain. So in
>> fact it's nothing else than the social networking part where the
>> Region domain would be those additional 3D services.
>>
>> Of course the AD also does a bit more, like trust brokering.
>>
>> The thing is though: Why group all this together into one big chunk?
>> It will be more likely in the future that you will have data stored  
>> on
>> several services: your profile might be on MySpace (or one of many),
>> you
>>  chat via IRC on freenode, you have photos on flickr which you might
>> want to use as textures. So IMHO it makes sense to allow this to be
>> split up into several services. The only question is how to bind this
>> together.
>>
>> I already mentioned XRDS here once, which is basically a list of type
>> URI/service URI pairs. A user could describe via XRDS where profile,
>> friends list etc. is stored and the client or the simulator could  
>> then
>> go and fetch it. No big Agent Domain would be needed and you also
>> could support various services where client and simulator could  
>> choose
>> those they understand.
>>
>> The only thing of course where it gets tricky is authorization
>> brokering. You don't want your data public (at least not all of it).
>> OAuth might give you some means of authorizing third parties to give
>> out
>>  data on your behalf. But the problem is of course that you'd need to
>> authorize each service individually which is not user friendly.
>>
>> So here is where some thinking is actually needed: How can an
>> authorization broker be implemented. I would prefer it be OAuth based
>> because libraries and understanding of OAuth is there (and of course
>> it's also at the IETF ;-). And maybe we come back here to the  
>> original
>> scalability problem of the AgentDomain but at least it would be only
>> one problem for the AD to solve (although the name might be not
>> correct anymore then because all the stuff related to an agent would
>> be spread across different services).
>>
>>
>> As for naming though: it would then be
>>
>> - profile interop
>> - contactlist interop
>> - group interop
>> - chat interop
>>
>> etc.
>>
>> The question to the group would now be: Would it be worthwhile to try
>> to use all those existing specifications and just build a way around
>> them to bundle those things? IMHO the implementation wouldn't be so
>> hard to do. It would be an area though where it's very mixed with
>> where the web/social networks are going so it would make sense to do
>> this together with web folks.
>>
>>
>>
>>
>>
>> -- Christian
>>
>>
>>
>>
>> --
>> COM.lounge GmbH
>> http://comlounge.net
>> Hanbrucher Strasse 33, 52064 Aachen
>> Amtsgericht Aachen HRB 15170
>> Geschäftsführer: Dr. Ben Scheffler, Christian Scholz
>>
>> email: info@comlounge.net
>> fon: +49-241-4007300
>> fax: +49-241-97900850
>>
>> personal email: cs@comlounge.net personal blog: http://mrtopf.de/blog
>> personal podcasts: http://openweb-podcast.de,
>> http://datawithoutborders.net
>>
>> _______________________________________________
>> mmox mailing list
>> mmox@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmox
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox