Re: [vwrap] Consensus? What exactly should be in the protocol

On Sep 21, 2010, at 11:15 AM, Meadhbh Hamrick wrote:

> so after yesterday's fireworks, i think it's safe to say the group
> agrees we're trying to build standards for "some kind of virtual
> experience."

I think this can be nailed down a lot better, Meadhbh. Or maybe there  
are completely different goals at play here. Probably the latter,  
let's see.

Here's what I think would be really cool for this group to do: this  
group could be trying to build standards for portable user agent  
simulation state, a part of which, but not all, is portable identity.  
Where:

1) "portable" means what it means on the Web: communicated between  
sites in different trust domains
2) "user agent" means what it already means on the web: the data that  
represents the user on the web server
3) "simulation" is the new thing that these web apps do: they take the  
user agent data and place it in a  simulation of a 3D environment,  
possibly, but not necessarily, giving the user a visual representation  
called 'avatar'. As the simulation proceeds, the user agent data may  
change.

I think it's very uninteresting -- and mostly void of any effect in  
practice -- that this group engages in the design of a standardized  
virtual world user experience, e.g. making the SL features be a  
standard for all virtual worlds. For example, they all have maps! they  
all have IM! they all have currency! etc. -- that's as pointless as  
trying to standardize the user experience for social network  
applications.

> we agree that the group should define "services," to
> simulate the virtual world.
> and we should define enough services that
> a software developer could take our documents and code something that
> has a good chance of a) interoperating with other software developer's
> output and b) provides a reasonably complete virtual world experience.
> further, i _think_ we agreed there should be no requirement that a
> service deployer should have to deploy ALL the services we define;
> it's up to the individual deployer what services they want to offer.
>
> a lot of people on this list have experience with Linden's Second Life
> Viewer (and similar programs.) i think the experience of a virtual
> world through this program has shaped a lot of people's recent
> opinions of what should and what shouldn't be in a virtual world.
>
> josh bell gave a presentation titled "what's *not* in VWRAP" at last
> spring's IETF face to face in anaheim. you can find the notes here:
> http://www.ietf.org/proceedings/10mar/slides/vwrap-6.pdf [warning,
> PDF.]
>
> to begin the discussion, i'm going to list a few things i think should
> be standardized by this group, then a few things that i think
> shouldn't. please note that i'm all for standardization, it's just
> that for some of these features we may want to rely on what josh
> refers to as "convention" rather than standardization. in other words,
> peeps should definitely develop standards for enough stuff to be able
> to render a virtual world with terrain, objects and avatars, but i
> don't think this group has to standardize everything (like postcards.
> why the heck do postcards go through linden's servers when it's
> EXTREMELY likely that if you have a second life account you also have
> an email account. but i digress.)
>
> so here's my list. i'm not trying to tell people the is the only list
> that would ever work. they're just my thoughts...
>
> * type system - in
>
> i'm a big fan of the abstract type system and it's related
> serialization schemes. i'm not the world's biggest fan of LLIDL. i
> like what it's trying to do, but all that line noise used to define
> resources is annoying.
>
> * authentication - in or out? BOTH
>
> so now that linden has de-emphasized their participation in this
> group, and we probably won't know for a while if they'll ever
> implement anything we specify, why bother with legacy linden
> authentication. their current "legacy" auth goes over XML-RPC which
> IMHO is the internet equivalent of a skin disease that you just can't
> get to go away. it also uses MD5. i can't express my feelings for MD5
> in polite company.
>
> there are some very interesting conversations / arguments going on
> regarding OAuth. it's a well understood authorization technology that
> many of us on the list have used in the past. OpenID is also vaguely
> popular, though i'm not it's biggest fan. i do know that some of the
> .edu peeps are supporting shibboleth which is (correct me if i'm
> wrong) layered on top of SAML.
>
> however... there is one aspect of the current auth spec that is (IMHO)
> "really cool." and that's the part that provisions a seed capability.
> zha and i have bounced up and down about how caps solve some vexing
> problems dealing with loosely coupled collections of services.
>
> also, most current OAuth instances like to direct people to HTML web
> pages. this can be a problem for peeps with desktop  apps. yes, you
> can integrate a web browser with your viewer and capture the final
> redirect. btw, one of linden's problems with this idea was you got
> software distributed by linden that redirects people to web pages
> owned by other people, and this sorta freaks some corporate users out.
>
> so... were i the empress of all the internet, i would decree that
> linden legacy auth and linden OGP auth be deprecated and declare that
> implementers were free to use whatever auth technology they want to
> use to authenticate the user prior to giving them their seed cap. but
> because i was a kind monarch, i would define one or two standard,
> thought non-normative, techniques for using other auth technologies.
>
> so instead of calling this auth, i would go back to calling it
> "service establishment."
>
> * maintenance - IN
>
> if you look at the existing auth spec, there's a resource defined for
> login-time user maintenance. it's pretty straight forward to support
> on the client side, and there's no requirement that you have to use it
> on the server side.
>
> * account properties - some IN, mostly OUT
>
> i think we should have a standard way for a client or service to
> request basic information about a user, an agent or an avatar. but
> honestly, i think a lot of the stuff that get's displayed in the
> Second Life Viewer's profile floater could just as easily be rendered
> as a web page.
>
> * agent / avatar control - IN
>
> yes, we should define a standard set of messages for controlling the
> user's avatar. however, i think we should build an extensible control
> sub-protocol. so maybe we start with messages labeled 'CONTROL-MOVETO'
> to define how the user's
> avatar should be moving around the virtual world. later we may want to
> add 'CONTROL-ANIMATION' for synchronizing an avatar's animation with
> real-life events from the client.
>
> * asset access - IN
>
> there's lotsa fun stuff that's been hypothesized for next generation
> assets. suffice to say, at the very least manipulation of meta-data
> and a way get link objects in user's inventories and objects in world
> with objects in an asset server is "a good thing."
>
> * asset upload - OUT? maybe? IN? kinda
>
> there are plenty of great protocols and data formats for defining
> assets. X3D, COLLADA, etc. and HTTP PUT is well understood. so i don't
> know that we have to create any new protocols for uploading assets.
> but we may want to define a technique by which a user can tell an
> asset server it's wants to upload something and then the asset server
> gives the client a URL to a HTTP PUT resource where it can upload it.
>
> * build tools - OUT
>
> the ability to do "group builds" in second life and OpenSim instances
> is one of the compelling things about those worlds. i think there
> should be a standardized way to do builds "in world." but IMHO, SL
> does it wrong. OpenSim inherited SL's wrongness. we could do it MUCH
> better. but i would recommend we pass on building a standard for it in
> this group.
>
> * communication - some IN, some OUT
>
> anyone who's experienced the "joy" of second life's group chat feature
> can quickly see how it's not up to the task. XMPP is a PERFECTLY GOOD
> chat protocol. however, for spatial chat, you would probably want some
> way to identify a location in the virtual world as the endpoint of a
> chat message, so at the very least we should have enough specification
> for how to represent locations or avatars in the virtual world for
> XMPP or SIMPLE or IRC or whatever chat protocol we would want to use.
>
> but the existing linden legacy protocol chat should definitely be
> deprecated. or caught in a dark alleyway when no one's around and put
> out of it's misery.
>
> * event profiles - OUT
>
> this is something that should be a web page
>
> * friends and groups - OUT? IN?
>
> this is a tough one. groups are kind of an important part of second
> life's social fabric. but i have a hard time justifying a group access
> and management protocol when i know that the first thing a third party
> is going to do is ignore the protocol and implement something that
> talks to twitter or facebook.
>
> but... it is still nice to have some standard way to query a user's
> presence. maybe the thing to do is to define a
> "presence field" in a user or avatar's public profile. you could then
> stuff the URL to your public profile on your facebook page or some
> twitter app somewhere and virtual world clients could "do the right
> thing" by querying your social network on facebook / twitter / avatars
> united / etc, reaping the links to user's public profiles and then
> querying their presence status.
>
> or maybe i should just shut up and go code some examples.
>
> anyway... thoughts?
>
> * parcels - OUT! OUT! A THOUSAND TIMES OUT!
>
> parcels are a linden invention that (IMHO) should not be part of this
> protocol standard. i'm all for lindens making publicly defined
> extensions to describe their parcel system, but i don't think every
> region should be forced to carry this bit of linden baggage.
>
> * land and region profile - IN
>
> on the other hand, it's good to know a thing or two about the virtual
> land upon which your avatar stands (like where to go to get the scene
> graph). that should definitely be in the protocol.
>
> * search - OUT
>
> this should be a web page.
>
> * teleport - IN
>
> * virtual currency - OUT
>
> * world map - OUT
>
> * "space server" - IN
>
> this is the resource that defines the adjacency and shape of various
> regions. i don't think we could have a meaningful virtual world
> experience without it.
>
>
> okay... these are just some ideas to kick-start the conversation. i'm
> interested to hear what other peeps think. if i didn't mention your
> favorite service it was an oversight, not a slight.
>
> -cheers
> -meadhbh
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap