Re: [mmox] OGP scalability concerns

["Hurliman, John" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Christian Scholz
> Sent: Thursday, April 02, 2009 1:05 PM
> To: Jon Watte
> Cc: [e-mail]
> 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: [e-mail]
> fon: [phone]
> fax: [phone]
> 
> personal email: [e-mail] personal blog: http://mrtopf.de/blog
> personal podcasts: http://openweb-podcast.de,
> http://datawithoutborders.net
> 
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox