Re: [mmox] OGP scalability concerns

Christian Scholz <cs@comlounge.net> Thu, 02 April 2009 20:04 UTC

Return-Path: <cs@comlounge.net>
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 912FB3A6D4F for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 13:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.216
X-Spam-Level:
X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_36=0.6]
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 jcYmR9LljDIm for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 13:04:51 -0700 (PDT)
Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id C2B7C3A6CAE for <mmox@ietf.org>; Thu, 2 Apr 2009 13:04:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 40A416F4011; Thu, 2 Apr 2009 22:05:18 +0200 (CEST)
Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LF2gVMtgfUfD; Thu, 2 Apr 2009 22:05:17 +0200 (CEST)
Received: from [192.168.2.101] (pC19EBF8B.dip.t-dialin.net [193.158.191.139]) by post.comlounge.net (Postfix) with ESMTP id 9BD451CE00CC; Thu, 2 Apr 2009 22:05:16 +0200 (CEST)
Message-ID: <49D51A7D.8000104@comlounge.net>
Date: Thu, 02 Apr 2009 22:05:17 +0200
From: Christian Scholz <cs@comlounge.net>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Jon Watte <jwatte@gmail.com>
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>
In-Reply-To: <49D4E5AF.2030301@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "mmox@ietf.org" <mmox@ietf.org>
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 20:04:52 -0000

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