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

[Morgaine <[e-mail]>]

Oh I think I see, Crista.  If I'm right then it's just your language that
differs a bit from ours, which shouldn't be too surprising. :-)

Judging by the post you linked, your "*user agent simulation state*" seems
to be simply our "*agent*", or if there is an in-world representation too,
then it's our "*agent + avatar*".

The avatar is (typically) a visual representation of the agent, but the
visual representation is of course performed in the client, not the server.
In VWRAP the media elements that the client requires to draw an avatar comes
from *asset services*, and proxying by the region as we see in SL would be a
highly suboptimal deployment pattern, albeit a valid one.  Normally assets
would travel straight from asset services to client applications to make the
most of the massively parallel paths of the Internet.  (Scalability is a
primary concern for us.)  The avatar representation is not referred to as
simulation in VWRAP.

The region's actual simulation service does perform *physics simulation* of
course, which comprises both environmental physics (gravity, mass, inertia)
and collision physics (bounding boxes, terrain), but that only affects
avatar position and orientation, not visual representation.

I think that straightens out the terminology differences in your phrase.
But VWRAP is not involved in standardizing avatars, as that would be quite
futile.  Avatars will be as varied as the asset services that carry the
components out of which avatars are represented.

We would expect industry standard formats to be used for representing
avatars, such as Collada.  Our protocol would be concerned merely with
placing agents in-world and, optionally, triggering the start of avatar
instantiation ("rezzing") in all participating client applications.  There's
a bit more to it, but that's the gist.

Does that make sense in an OpenSimulator context?  (I'm actually very
surprised to see that our terminologies differ so much --- we should have
come together a long time ago. :P)


Morgaine.






======================================

On Wed, Sep 22, 2010 at 6:22 PM, Cristina Videira Lopes
<[e-mail]>wrote;wrote:

>  Definitions here:
> http://www.ietf.org/mail-archive/web/vwrap/current/msg00317.html
>
> Morgaine wrote:
>
> On Wed, Sep 22, 2010 at 5:12 PM, Cristina Videira Lopes <[e-mail]
> > wrote:
>
>>
>> (1) Goal of the group: develop standards for portable *user agent
>> simulation state* (expand on that)
>>
>
>
> I think we may be witnessing the bow shock from a collision of meme systems
> here. :P
>
> VWRAP has honed its terminology rather well over the years, as has the
> OpenSimulator project I'm sure, but the two sets of terminology seem to be
> different.  We need to bridge this gap fast. :-)
>
> What is "*user agent simulation state*"?
>
> In VWRAP we have:
>
>
>    - *users* (humans driving a "*client application*");
>    - *agents* (the server-side embodiment of a connection from a client
>    application);
>    - *regions* that are primarily spatial but may orchestrate many
>    services;
>    - *simulations* that were traditionally run within a region but which
>    in VWRAP may be performed by a discrete "*simulation service*" that
>    could be external;
>    - *world state* which is primarily held and manipulated by a *region
>    service*.
>
>
> (Note that the above may sound a bit like SL, but it's not really. VWRAP
> services can be arranged in numerous different *deployment patterns*, and
> an SL-like configuration is merely one possible deployment out of many.)
>
> To the above should be added that we employ a *REST*-type protocol for all
> upstream communication between client application and server-side services,
> and being REST, clients and servers both have application state which is
> accessed and modified through CRUD operations, but the protocol is stateless
> as usual to provide us with the normal benefits of REST, such as
> addressibility, cacheability, etc.
>
> What we don't have is simulation state in the client application, so the
> phrase you used is a bit hard to tie down using our form of language.
> Explanation needed please --- I'll try to help you fit it into our
> terminology if I can. :-)
>
>
> Morgaine.
>
>
>
>
>
> ================================
>
> On Wed, Sep 22, 2010 at 5:12 PM, Cristina Videira Lopes <[e-mail]
> > wrote:
>
>>  Fair, Morgaine.
>> Here's an attempt at a plan for what could be in that draft.
>>
>> (1) Goal of the group: develop standards for portable user agent
>> simulation state (expand on that)
>> (2) Granularity of portability: virtual world application (expand on that)
>> (3) Principles of such standards: as close to the design principles of the
>> Web as possible (summarize)
>>
>> For (1) we need definitions for just about every word in there, which I
>> started to do, and we also need a good definition of "state" itself. What is
>> that state that gets ported around?
>>
>> For (2), I liked your long analysis, but I think there's a shorter way to
>> get where you got, we really don't need to reinvent the Web :) But we can
>> work on that.
>>
>>
>> Morgaine wrote:
>>
>>  Discussing what should be in draft protocol documents prior to actually
>> writing them would be a good idea.  We've suffered from this problem here
>> repeatedly, in that documents are just sprung on us and then it's a major
>> fight to get them back to a mutually acceptable common base.
>>
>> It would be infinitely more useful to find the common base first.
>> Documents have immense inertia, and the less in them that needs revising at
>> a core conceptual level, the less time is wasted by everyone.  A little
>> planning is a major time saver here.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>> ================================
>>
>> On Wed, Sep 22, 2010 at 4:28 PM, Cristina Videira Lopes <
>> [e-mail]> wrote:
>>
>>> OK. If more people are interested in this formulation, let's go ahead
>>> with this.
>>> It looks like Meadhbh, who has been the only active draft writer as far
>>> as I can tell (!),  doesn't like/want/? this formulation, so she is not in a
>>> position to write it down. It is completely unfair of us, and mutually
>>> frustrating, to expect that she is going to write down things that she
>>> doesn't like/want. So someone else needs put their money where their mouth
>>> is, and spend a couple of days writing an intro draft that's alternative to
>>> the one that is currently active, and that reflects everyone else's
>>> expectations on the existence of [virtual world] application domains of
>>> trust.
>>>
>>> Maybe once we have an alternative intro document, we can all converge.
>>>
>>> Any takers?
>>>
>>>
>>> Hurliman, John wrote:
>>>
>>> This is closer to what I had in my head for VWRAP. Start with the goal of a portable virtual world presence, and a couple of necessary services fall out of that:
>>>
>>> * Identity/Authentication
>>> * Assets (possibly Inventory, maybe)
>>> * Teleport (both login and simulation to simulation)
>>>
>>> Which will in turn require:
>>>
>>> * Type system
>>> * Capabilities/X.509/insert_security_here
>>> * Avatar file format?
>>> * Event queue?
>>>
>>> And leave everything else for VWRAP2. If we can standardize those services and meet that first goal it will be much easier to tackle things like friends or groups or avatar movement / state simulation or anything else. I don't know if there is any industry demand for a virtual world avatar movement RFC, but other people have different perspectives. I'm strongly in favor of working toward the portable virtual world presence and supporting service definitions first though.
>>>
>>> John
>>>
>>>
>>>
>>>  -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail] <[e-mail]>] On Behalf
>>> Of Cristina Videira Lopes
>>> Sent: Tuesday, September 21, 2010 5:47 PM
>>> To: Meadhbh Hamrick
>>> Cc: [e-mail]
>>> Subject: 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/ * [e-mail]
>>> _______________________________________________
>>> vwrap mailing [e-mail]://www.ietf.org/mailman/listinfo/vwrap
>>>
>>>  _______________________________________________
>>> vwrap mailing [e-mail]://www.ietf.org/mailman/listinfo/vwrap
>>>
>>>  _______________________________________________
>>> vwrap mailing [e-mail]://www.ietf.org/mailman/listinfo/vwrap
>>>
>>>
>>>
>>> _______________________________________________
>>> vwrap mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/vwrap
>>>
>>>
>>  ------------------------------
>>
>> _______________________________________________
>> vwrap mailing [e-mail]://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>>
> ------------------------------
>
> _______________________________________________
> vwrap mailing [e-mail]://www.ietf.org/mailman/listinfo/vwrap
>
>
>