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

[Meadhbh Hamrick <[e-mail]>]

hey peeps...

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." 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/ * [e-mail]