Re: [mmox] Creating walled gardens considered harmful

Christian Scholz <cs@comlounge.net> Thu, 02 April 2009 21:18 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 2F6833A69C5 for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 14:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.195
X-Spam-Level:
X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.196, 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 jWDY-aizDA2G for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 14:18:44 -0700 (PDT)
Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id DCD1F3A695F for <mmox@ietf.org>; Thu, 2 Apr 2009 14:18:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 370B91CE024A; Thu, 2 Apr 2009 23:19:28 +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 tz90ZhpN+sCg; Thu, 2 Apr 2009 23:19:25 +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 3DF8F1CE00CC; Thu, 2 Apr 2009 23:19:25 +0200 (CEST)
Message-ID: <49D52BDE.8060502@comlounge.net>
Date: Thu, 02 Apr 2009 23:19:26 +0200
From: Christian Scholz <cs@comlounge.net>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Lisa Dusseault <lisa.dusseault@gmail.com>
References: <e0b04bba0903250007k6886383bja0a06884e8081ac7@mail.gmail.com> <e0b04bba0903281057g943ce9cjdcce0fc2712a4ec3@mail.gmail.com> <49CF1B1E.4070506@gmail.com> <e0b04bba0903290138ifbfaf18p930f87d1e49e6dbb@mail.gmail.com> <49D0081E.4010007@gmail.com> <e0b04bba0903291942k69f6e970yee8b8a80dd8df2fa@mail.gmail.com> <49D0D846.5010401@gmail.com> <170fa1780903300854s34da03eaq8b3ed2f7eb9c2a62@mail.gmail.com> <382d73da0903301459j308445f7uec660dab275175a1@mail.gmail.com> <49D1500C.1030604@gmail.com> <ca722a9e0903301657m3615ae8fnb07b428419e563f6@mail.gmail.com>
In-Reply-To: <ca722a9e0903301657m3615ae8fnb07b428419e563f6@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: MMOX-IETF <mmox@ietf.org>, Kari Lippert <kari.lippert@gmail.com>, Jon Watte <jwatte@gmail.com>
Subject: Re: [mmox] Creating walled gardens considered harmful
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 21:18:46 -0000

Hi1

Lisa Dusseault schrieb:
> How about a very persona-oriented (specific) use case...

Always good :-)

> Lisa has a house in one virtual world, with virtual rooms that she
> frequently hangs out in, that friends might find her at.  One day she
> goes to a party in another virtual world.  She leaves behind a note on
> her virtual door or bulletin board (she has control over the
> presentation, it could be a spinning hovering party hat or a blue
> police phone booth if the home world allows that).  The note has a
> link to the party world because it's an open party.  Lisa's friends
> can now find her, and the more seamless their experience in getting
> from the first virtual world to the second, the more likely they are
> to enjoy the experience, follow through, and see her.
> 
> Seamless is a goal, but might involve:
>  - Not launching a new client, if possible, and if it is
>       - A transition that is not too jarring, minimizing reload
> screens, blank screens, dialog boxes, choices
>  - Low time consumption for transport, including time navigating from
> an initial destination to a final destination, if allowed by the
> destination world
>  - Avoiding a registration step if possible, and if it is
>       - Lisa can recognize her friends under the moniker she'd
> normally see them under

So here I would say that this isn't necessarily a virtual worlds 
specific use case. You want to have the same on social networks without 
any 3D interaction. And I guess this thing people call the Open Stack (I 
know, it isn't a stack :-) ) is already going into that direction.

In an ideal world you might simply enter e.g. your openid, you 
authenticate via the OP and the rest should be automatically aavailable 
to that virtual world: profile, friends list, inventory as long as it's 
compatible, chat, groups and so on.

Now if we go one step further and assume that there is some mechanism to 
also carry on your identity without any user interaction then it should 
be rather seamless (but also less secure of course). How that might be 
implemented might be up to the group to find out. But as Eran also 
wanted to think about adding identity support to OAuth that might 
actually be possible then.

>  - Keeping avatar consistency to the extent possible, for recognition
> as well as seamlessness

Here I wonder if there couldn't at least be some very simple 3D 
represenation which is easy to implement, does not give you the whole 
experience you would get with a native client but at least could 
understand who is around and roughly where.

> For bonus points, Lisa can open a door from her house into the party,
> and visitors can get a glimpse of what's beyond, then just walk
> through.

Yay, a portal! :-) But maybe at least some sort of video service might 
also be possible where the client only needs to understand that video 
part in a portal but nothing else of the foreign virtual world. I am 
just wondering if that really makes sense if you cannot move through it.

-- Christian



> On Mon, Mar 30, 2009 at 4:04 PM, Jon Watte <jwatte@gmail.com> wrote:
>> Kari Lippert wrote:
>>> <clearing throat>
>>>
>>> I've been lurking for some time now and reading and trying to understand
>>> the basic user requirement that is driving this work. I have to admit this
>>> is as close as I've seen.
>>>
>>> I understand "teleport" (and believe if you can define it well enough,
>>> smart people can make it so) but it leaves me asking why? Why would a user
>>> desire to "teleport" from one VWE to another? The answer to this will, I
>>> believe, help you focus on what needs to be included in the definition of
>>> what it means to "teleport", and what can be safely set aside for the
>>> moment.
>>>
>>> Kari
>> I think "teleport" is an implementation detail. Does this use case seem like
>> a good description of what you consider a "teleport"?
>>
>>
>>     2.1. Friend Invite
>>
>>
>>       2.1.1. Description
>>
>>
>>
>>  1.  User A uses virtual world system A that complies with MMOX
>>      interoperability.
>>  2.  User B uses virtual world system B that complies with MMOX
>>      interoperability.
>>  3.  User A wants user B to visit him/her in system/world A, and gets
>>      a suitable URL from his/her system (A), and sends this to user B
>>      using any transport (mail, IM, integrated communication, carrier
>>      pigeon, ...)
>>  4.  User B clicks/activates this link.
>>  5.  After a brief "loading" screen, user B sees user A in user A's
>>      environment, including a representative form of any simulated
>>      object in that environment.
>>  6.  User B can interact at some level with the objects from user A.
>>  7.  Objects that user B take out of inventory show up in some
>>      representative form for both user A and user B.
>>  8.  User A can interact at some level with any objects that user B
>>      bring out of inventory.
>>
>>
>>
>> Note that I assumed that if you have avatars and objects, you also have
>> text/speech, but that's a poor assumption -- it should go as line 5.5 in
>> this use case, I guess.
>>
>> Sincerely,
>>
>> jw
>>
>> _______________________________________________
>> 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


-- 
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