a platform for a compelling, immersive 3d virtual world

so Tateru Nino's just penned a nice, short blog post: Linden Lab Can't turn Second Life into an Engaging Digital Experience.

go read it now, i'll wait.

okay. back? great! let me add a few notes.

in Second Life's early days, it was pretty clear Linden thought of it's creation as an online service for the creation, display and sale of 3d content. back then, you heard a lot of people at the lab saying things like "Your World, Your Imagination." i've heard people say uncharitable things about Linden's founder Philip Rosedale, but seriously, whatever his faults, he was VERY good at internalizing and communicating Second Life's fundamental message: "This is YOUR playground, Linden is here to make sure the plumbing works."

throughout the early-mid 2000's, the SL community rambled along, doing cool things, showing them off, building an early community. after the hype cycle started kicking in, corporate america showed up and a few of their denizens thought (and i paraphrase here): "oh hey, check it out. it's like WebEX except i can build 3d doo-dads to demonstrate concepts and since it's a 'game' i can get away with looking like something other than a corporate drone."

as IBM and Cisco and other corporate heavy-weights started looking at SL as a tool for business operations (rather than just marketing,) you started to hear a lot of talk about SL as a "platform." up 'til this time people had used the word "platform" synonymously with "service." but now the big guys wanted to run a server or two behind their firewalls so corporate secrets wouldn't have to leave the corporate intranet. there's absolutely nothing wrong with this concept; but it's not what SL was initially built to do.

a couple "one off" solutions were built for various corporate customers, but their features were never integrated into the main-line SL service offerings. Linden management was caught in a dilemma: their casual consumer customer base was exploding in 2006, but corporate users seemed like a great market. Linden's challenge was how to increase stability and capability for consumer users while adding features for corporate customers.

around 2006 Linden, IBM, Cisco, Intel and a few other corporate heavies started talking about interoperability in virtual worlds. this eventually led to the Virtual World Interoperability Forum. the VWIF was supposed to produce detailed functional descriptions of how virtual worlds work so there was a good chance virtual worlds operated by different companies could talk to each other. the VWIF eventually sputtered, giving rise to the Second-Life focused: Architecture Working Group (AWG), Open Grid Protocol (OGP) and eventually the Virtual Worlds Region Agent Protocol (VWRAP) working group in the IETF.

but please note, when a crowd of network interoperability people use the term "platform," they don't mean the same thing as when second life users (and even most Linden management.) Second Life management had used the term "platform" to mean, "hey, here's a service you can use to do cool stuff." they did not mean "hey, we have a technology platform you can download, extend and deploy."

but throughout the latter 2000's when Linden was working on their "behind the firewall solution" for corporate customers, there was a small kernel of Linden employees that did intend to make a real-life, honest to goodness "technology platform." the idea was to corral linden's server software into an appliance customers could plonk down in the middle of their data center. viola! instant virtual world populated only by corporate users.

for a lot of different reasons, this turned out to be harder than initially suspected. one reason (certainly not the only one) was the difficulty of maintaining two distinct code bases: one for corporate, behind the firewall use and another for the consumer solution. because Second Life was always considered a "service," there were a wide variety of assumptions the code could make about network architecture and peer service availability. and it turns out that some of the assumptions you make for a huge virtual world with 85,000 concurrent users are not the same as the assumptions you make for a couple simuators and a smattering of "behind the firewall" users.

whatever the reasons, the project to convert the Second Life "service" into a behind the firewall "platform" failed. (though it should be noted a lot of very skilled Lindens did a lot of awesome work to shoehorn Second Life into an appliance.)

about the same time Second Life/Enterprise (SL/E) was being discontinued, Linden's official support for an open virtual worlds interoperability protocol evaporated as well. sic transit gloria munde; at least there's still OpenSim.

but what relevance does this have to the modern world?

does it mean there's no market for "behind the firewall" virtual worlds?

does it mean that Second Life as a "platform" is an architectural dead end?

what about content? and the network effect?

let me offer my two cents about these questions.

first off, Second Life is not and nor has it ever been a "technology platform." Second Life is a "service." it was coded by people who made certain assumptions about their environment (like where the asset servers existed, that peer services were "trustworthy" and what features end users demanded.)

so my first assertion is, the failure of Second Life/Enterprise (SL/E) and VWRAP does nothing to refute the existence of a market for a well-developed, well-supported "behind the firewall" virtual world solution. SL/E's failure simply means it's damn hard to cram the Second Life code base into a small number of servers. in fact, it's so hard that the NRE and support costs are waaaay out of line with any income the service could generate.

i also believe that Second Life, as a technology platform, is dead. as a service? sure, it's still cranking; there are a bazillion people (myself included) who log into SL to socialize and play. what's more, i think Linden also thinks SL as a technology platform is dead. recent actions from Linden management make it clear they're putting all their resources into making SL as compelling an online service as possible.

Tateru Nino speculated that a team of crafty engineers could rebuild something like Second Life in about 6 weeks. i'm more inclined to say it would take 18 months before you get something close to SL's performance and concurrency. were i to develop a business plan for a startup doing more or less the same thing Linden's doing, but with a better, cleaner architecture and the ability to deploy as a real technology platform, i would estimate about 15 man years to beta launch. taking a completely arbitrary figure of $200,000 per man year, you wind up with a $3 million price tag.

so this has got to be how the VCs, angels and midnight engineers are looking at it: given Linden's flat subscriber growth, why would someone risk $3x10^6 on a new virtual world platform?

how 'bout something like a "Social Virtual World" that uses identity information from Google, Facebook, LinkedIn, Twitter (or even your own corporate LDAP server) ??? that might be compelling.

or even a "virtual world technology framework" that niche application developers could easily extend. that seems like it would be a good idea.

maybe even a "content framework for 2d and 3d experiences" where you could easily develop some kind of 3d model using blender, maya, etc. and have it automagically uploaded to the cloud where virtual world servers could easily import it. bonus points if you work through the intellectual property issues.

so there are a lot of interesting things a VC or angel could fund and an entrepreneur could build, but rebuilding Second Life? no thanks, i'll pass.

announcing project brookdale

this is a quick post to announce "project brookdale," an open source implementation of the Virtual World Region Agent Protocol (VWRAP) suite. VWRAP is a collection of specifications produced by the IETF's VWRAP Working Group. these specifications define interoperability for a "second life-like" virtual world. you can find more information about VWRAP on my VWRAP Page or the blog post "what's the virtual world region agent protocol?"

project brookdale will produce PHP, JavaScript and C/C++ middleware that manages protocol interactions. it is not, in and of itself, a complete virtual world implementation. it is instead designed to be used to simplify the development of VWRAP compatible tools and services. this division is not completely unlike the division between libomv and OpenSim.

here's a quick list of things you'll find in brookdale:

Dynamic Structured Data (DSD) and HTTP Transport Bindings

"DSD" is an evolution of the previous LLSD and LLIDL abstract type system and interface description language. the main difference between DSD and LLSD are minor changes in the XML serialization and a "layered" approach making it easier to use VWRAP messages with non-HTTP transports. more information about the motivations behind DSD can be found in a "abstract resource definitions vs. LLIDL". the internet draft draft-hamrick-vwrap-data-00 describes DSD in more detail.

one feature desired by implementers of previous OGP and early VWRAP work was clear guidance or agreement for how to handle content negotiation and caching of VWRAP messages carried over HTTP(S). draft-hamrick-vwrap-foundation-00 builds on the previous work and describes the use and interpretation of HTTP headers and status codes for content negotiation and caching.

project brookdale provides PHP and JavaScript classes and C functions implementing the interface semantics of DSD. it allows web and application developers to easily manipulate VWRAP requests, responses and events.

a capability management facility and capability broker

web capabilities are an integral part of VWRAP. they allow distributed, trusted systems to grant fine grained access to sensitive resources without a global identity management system. an informal introduction to capabilities in VWRAP can be found in the earlier blog post, "VWRAP essentials : capabilities".

capabilities serve as aliases for RESTful VWRAP resources. composed of a cryptographically unguessable URL, they combine authorization to access a resource with that resource's address. the "capability broker" is the system component that maps a URL managed by a system to the object or database row it represents.

a simple VWRAP event queue over long poll

the VWRAP event queue is a simple abstraction for unsolicited server to client communication. VWRAP currently reifies the event queue as a "long poll" over HTTP. it is hoped that future work will specify the use of WebSockets as a carrier for VWRAP events.

simple connection manager with trust model support

trust between components in a VWRAP system is established by asserting identity using an X.509 client certificate. the VWRAP specifications do not require systems to trust any particular entity or certification authority, but they do require entities accept connections that use client side certs. in other words, a VWRAP system is free to ignore X.509 credentials from a client, but it must not disallow clients from sending them.

one ramification of the VWRAP trust model is it requires a "trusted" service to potentially present a destination-dependent certificate to a remote peer. an authentication service, for instance, may identify itself to an asset service by presenting it with a certificate issued by the asset service (or a trusted third party certification authority.) the brookdale connection manager maintains a mapping between destination URLs, client certificates and their related private keys.

VWRAP Authentication (including OAuth support)

VWRAP defines several "native" authentication technqiues as well as the use of OAuth in protocol transactions. the brookdale authentication components manage the process of user authentication and the seed capability lifecycle.

Client Application Launch Message processing

the VWRAP client application launch message (CALM) is an optional message sent to a web browser with specific details of which servers a client application (like the second life™ viewer) should contact to complete the login and rez process. intended to be used in conjunction with web authentication and authorization schemes like OpenID or OAuth, brookdale contains PHP, JavaScript and C functions to generate and process calm messages.

we're starting by publishing a few PHP and JavaScript files at the project brookdale page. these files are much more "middleware-ish" than they are "application-ish," but more will be coming in the next week.

the release of the code corresponds with the latest VWRAP abstract type system proposal. more code will be released at the brookdale site as the newer VWRAP drafts are published this month.

pay for your lag?

there's a discussion over at gwyneth llewelyn's blog between her and rob blechner about the upcoming linden town hall meeting. one of the topics mentioned is lag, and what can be done about it. gwen is happy to hear philip rededicate the company to fighting lag, but rob makes the point that in a user generated content world, there's not a lot you can do about it.

this got me thinking... why not build a world where there's a financial cost to creating laggy prims?

determining what's laggy these days isn't an exact science, but i think we know enough to know make a few reasonable assumptions. saying "unoptimized textures and large collections of prims lead to more lag" is a good start.

maybe users in the virtual world could be given a "lag budget" measured in ARC-hours. (ARC is "Avatar Rendering Cost.") if you go over your lag budget, you have to pay for more. so if you were given 6000 ARC-hours per month, you could wear your 1500 ARC outfit for only four hours before you had to buy more lag. but you would get 40 hours of use out of your 150 ARC ruth-esque outfit.

maybe a benefit of premium accounts could be you could sell your unused lag on the "open lag exchange."

just a thought.

VWRAP essentials : what's in the protocol?

it's no secret that VWRAP is heavily influenced by Second Life™'s next generation OGP protocol. (one view of how the OGP effort became the VWRAP working group can be found in "notes on the history of the VWRAP working group.") so it's not surprising that many people believe that every feature of Second Life™ will be found in the VWRAP protocol suite.

but this isn't the case; there will be many features of Linden's virtual world that won't be found in VWRAP. in this post, we're going to look at the VWRAP charter, a recent presentation by josh bell [PDF], and talk about why it's not a big deal some things are left out. but let's start with what's in and what's out.

what follows is a list of features that are widely believed to be "in" and "out." this is not an authoritative list; the feature list will only be official when the internet drafts describing VWRAP become RFCs. there's still time to influence the VWRAP protocol suite; join the vwrap@ietf.org mailing list and make your voice heard.

what's in : authentication and trust

the first step a client application should take when dealing with the virtual world is to authenticate themselves. in VWRAP the authentication process begins with the presentation of credentials and ends with the client application receiving a "seed capability" or "seed cap." you can find more information about this process in the "VWRAP Trust Model and User Authentication" draft.

the seed cap is a randomly generated, difficult to guess web address (URL.) when queried it returns information about where to find other services (like how to place your avatar in a region or manipulate your inventory.)

some members of the VWRAP mailing list have suggested that a virtual world open to anyone without authentication would be a productive use of the protocol. to support this use case, the authenticator in an authentication message is optional. which is to say, the protocol does not require an authenticator like a hashed password to accompany a login message, but the virtual world you connect to might.

it's also been pointed out that using Transport Layer Security (TLS) client certificates, OAuth or even HTTP authentication may be useful in some situations. so it may be more accurate to call the "authentication" phase more of an "identification with optional authentication" phase.

no matter what technique you use to successfully authenticate your client application to your authentication service, after it's over, the client has a seed capability and the authentication service has enough information to identify the client's user.

what's in : inventory, assets and basic permissions

developers should expect a "streamlined" asset system. there is a requirement to maintain positive copy control on objects for users who want such control. but the existing inventory / asset system used in Second Life™ is starting to show it's age.

assets in VWRAP will be represented as LLSD maps, retrieved using resources defined using the LLIDL interface description language, most likely over HTTP. an "asset" in VWRAP is a collection of meta-data and data. the "data" of an asset is tightly constrained by the asset's type: cubes are represented by cube data; textures with texture data; etc. asset meta-data will identify the creator, describe base permissions, and include textual descriptions of the object. assets will use URLs to reference other assets, and not UUIDs. for example, when a cube references a texture for each of it's faces, it will use URLs to point to the textures.

the SimianGrid project, which was born out of the Cable Beach Asset Server, has announced they will be participating in the development of the VWRAP inventory and asset system. Linden Research has not made a public statement of support of VWRAP inventory, but is expected to participate in it's development.

it should also be mentioned that regions could have region-specific assets. ground textures, the shape of buildings, etc. all might be stored in an asset server associated with the region and not with the user who created them.

what's in : spatial, user-to-user and group text and voice

text chat in Second Life™'s legacy protocol is mildly broken. spatial chat has reasonable performance, but uses the same protocol to carry text chat as to carry friend requests, inventory offers and such-like. group chat performance is much worse. its mostly the result of an arcane architecture involving routing chat messages though a simulator on the way to the user's viewer. simplification and performance enhancement is expected in both spatial and group text chat.

VWRAP will define a service for spatial, user-to-user and group text chat. there has been significant interest in using XMPP (or other established IM protocols) to carry text chat. this is a natural fit for user-to-user and group text chat.

voice is expected to work in radically the same way, but using SIP and RTP protocols instead of XMPP.

what's in : basic agent information

this does not mean "profile info." basic information would likely include very basic presence information like "this user is logged in" or "you can find this agent in this region." basic agent information is there to support other protocol functions (like teleportation and retrieving avatar shape info.)

what's in : teleport and region crossing

teleportation has changed radically from the Second Life™ legacy protocol. the biggest change is the idea that an agent's presence information can potentially be stored in two locations. OGP experimented with the idea that agent-oriented services should be segregated from simulation-oriented services. so if you wanted to know what region a user's avatar was rezzed in, you would query a service associated with that user, not with the region.

remember, in the OGP world, there may be several organizations that operate simulation regions. querying each of them to ask, "is this avatar located here?" is sub-optimal.

so this means that BOTH agent oriented services and region oriented services need to know where the user's avatar is. VWRAP is proposing extending the OGP Draft 5 Teleport specification to manage the intricate dance of moving an agent from one region to another.

what's in : avatar shape information

so we mentioned above that an agent's avatar will be available through the basic agent info service. it's unclear now what format avatar meshes will take. the existing Linden legacy format could be used. as could MPEG-V's ADML (avatar data markup language.) or maybe both.

whatever the format, a user's avatar will be made available to both client applications and simulation services.

what's in : the scene graph and object updates

when your avatar is rezzed into a region, the user's client application may pull a description of the scene graph. that is, the list of 3d objects observable in a given field of view.

there are several ways to communicate this information. for instance, the simulator could package up references to all items in the avatar's field of view and send it to the client as one large chunk. or it could just start sending a stream of messages; one message per object.

in the past, object update messages have been carried over raw UDP. in the future, object updates may be carried over RTP or an HTTP event queue.

what's in : object presence and physics simulation

objects in the virtual world persist. once they're rezzed, they should stay where they are until acted upon by an external force. "object presence" services will allow a client to query objects rezzed in the world for information like internal state, an object control channel (if you have rights to control it), etc.

objects that are subject to physical simulation may be moved or rotated by the simulation software running on the region they're rezzed in.

one of the fundamental features of VWRAP is that physics simulation happens centrally. that is, we don't do co-simulation where each client simulates physical interactions and then check with each other to see if any clients are out of sync.

what's in : region adjacency information

Second Life™ regions are rectangles, 256 meters on a side in the x and y dimension and stretching to infinity along the z axis. Second Life™ itself is a collection of these regions arranged in a grid. VWRAP will likely NOT mandate this shape as the standard for virtual worlds.

proposals have surfaced that describe the virtual world with spherical, cylindrical and toroidal coordinates. But even flat "grids" may have non-rectangular regions in the future. to help client applications figure out which systems to query for object information, a service is needed to describe the shape and partitioning of the virtual world.

this is not a map service per se, but something more fundamental. the virtual world is composed of multiple regions being stitched together to give the illusion of a seamless multi-dimensional space.

what's in : object and avatar control

a virtual world would be pretty boring if you couldn't move or animate your avatar. VWRAP will provide a simple, extensible protocol for sending control information to your avatar. the same protocol may be used to control other objects; think of virtual vehicles you climb in and drive.

what's out?

what's being left out of VWRAP is at least as interesting as what's going in. here's a rundown of major Second Life™ features you won't find in the spec.

what's out : game script

do not look for linden dollars in the VWRAP drafts; you won't find them. or at least you won't find them now. Linden expressed a preference that the linden dollar interface not be made part of the official specification. there are multiple reasons why this could be the case. VWRAP is still a technology under construction; a design flaw in VWRAP could lead to a very real vulnerability costing thousands if not millions of dollars. Linden also charges a fee for linden dollar transactions. it is possible they want to maintain control of the specification for purely mercantile reasons; to prevent VWRAP from letting third parties to wedge into the linden dollar exchange business.

some OpenSim developers expressed a desire to prevent Linden from encroaching on their turf. typical of their position is the statement, "why should i let Linden take a cut of my OpenSim based business?" the fear is that if a linden dollar API was included in the specifications, it would be considered mandatory. many OpenSim grid operators would not accept a mandatory linden dollar economy.

this is one of the most obvious places where business interest meets standards development, and it will be interesting to see what happens in the future. maybe Linden will open up a private VWRAP-like API for trusted partners. if you're an OpenSim operator not focused on eCommerce, this may be something you would be interested in. maybe third parties like two fish / live gamer will produce an alternative specification? it will certainly be interesting to watch the market develop.

what's out : land ownership

before i start any rumors, i should say that Linden is NOT going to eliminate private land ownership on it's grid. land ownership is not part of the VWRAP protocol suite because it's expected that different virtual worlds will manage land ownership differently.

VWRAP clients are expected to be able to query a region for "information about the place my user's avatar is at right now" and get a URL to a human readable, HTML web page. if the region supports land ownership, the web page will list that info. but the land ownership schema from Second Life™ will not be forced on all VWRAP virtual worlds.

this may be an issue for viewer developers. different protocols for land management will require client developers to know how to query a region for information about if and how ownership is represented and how to present it to the user.

what's out : building

so far there's been no mention of building as a use case for VWRAP. this doesn't mean it won't be supported, but it may be that building is handled by way of the generic object and avatar control protocol.

what's out : media attached to prims

Second Life™ has had "parcel media" for a while and recently added the ability to add media to a prim face. to date, this use case hasn't been discussed at length in the VWRAP working group. this is not to say it's not important, but it may be that the participants are happy to develop this standard later; perhaps after seeing what happens with Linden's "media on a prim" feature.

what's out : detailed avatar and user profiles

Second Life™ users are likely familiar with the standard user profile. imagine the ability to extend your profile to include information YOU think is important. this is what we're hoping to achieve by moving the profile information out of the core protocol and rebuild it as a simple web application. in the future, expect seeing a HTML page with protocol information instead of a fixed "floater" window in your favorite viewer. about the only thing the core protocol will specify is how to find the URL to the HTML profile page.

it sounds scary. but trust me; it'll be better.

why the sky not falling

some Second Life™ users may have an uneasy feeling, hearing that important features like game script, building and profile management WON'T be in the VWRAP protocol.

don't panic.

just because a feature is not in the VWRAP specification, it doesn't mean that feature will disappear from Second Life™ or any other virtual world. what it means is that Linden and the OpenSim developers may diverge on how they want to implement those features.

the lack of a feature in the specification means only that the participants could not find consensus on the feature's functionality. VWRAP will be complete enough to provide a rich experience. by agreeing to core functionality, it frees us to experiment with solutions for other, high-margin features.

it will, however, make client application coder's lives a little more complicated. where Second Life™ and OpenSimulator diverge, viewer developers will have to know how to work with both systems. this isn't as bad as it might seem; Linden's stock viewer already uses well known techniques to cope with protocol divergence. but more on that later...

in conclusion, let me encourage readers to subscribe to the vwrap mailing list where these specifications are being discussed. what to leave in and what to take out will certainly be the subject of continuing discussions. if you don't speak up now, you don't get to complain later.

VWRAP essentials : what does it mean to be "Second Lifelike" ?

so the VWRAP working group is off to a good start. we've completed the chartering process and published a few internet drafts. we also had a face-to-face meeting a couple weeks ago that identified a couple defects in some of our draft documents.

now it's time to start recruiting people to help with the effort. the documents we produce will require a number of participants documenting use cases, writing documents, creating sample code implementations, checking the technical contents of draft documents and reviewing the group's output to make sure it just plain makes sense.

but every time i ask someone to help out, they want to read our background documents. and this is where i start getting kind of embarrassed. we don't have nearly as many as we need. so i'm writing a series of blog posts about it to give an informal and informational introduction to VWRAP, the Virtual World Region Agent Protocol.

if you're new to VWRAP, you may want to read the "what's VWRAP.". for more detailed info, you may want to read the "VWRAP : Introduction and Goals" document. the current draft is 32 pages and is written to be as precise as possible. because it was written with "correctness" in mind, it can be a bit wordy at times. so my first couple blog posts will be high level discussions about what we're trying to accomplish.

several people have used the term "Second Lifelike" to describe the type of virtual world we're hoping to create. but that's a little bit of a fail; it's bad form to describe something new by saying "hey, it's just like this other thing, only a little different." so maybe the first question to ask is...

what does it mean to be second lifelike ?

if you've visited Second Life(tm) as a user and then visited World of Warcraft(tm) or EVE Online(tm), you know they're each pretty different experiences. WoW is mostly about fighting. sure, you can be social in some corners of the world, but what you're paying for is the ability to reign down hurt on other players. EVE Online is about dueling spaceships while Second Life is about capturing the experience of burning man by socializing and building interesting bits of art. or maybe its about business and education; we're still trying to figure that one out. but it's clearly more open ended than other popular massively multi-participant systems.

but for software developers and virtual world deployers, it's probably a good idea to have a better description of the protocol than "oh, it's sorta like Second Life(tm) or OpenSim." in the "intro and goals" document referenced above, there are three primary features of VWRAP virtual worlds:

1. the virtual world exists independently of the participants,
2. avatars have a single, unique presence in a single virtual world, and,
3. the virtual world contains persistent objects.

so let's look at these features in more depth:

the virtual world exists independently of the participants

some readers will remember VRML (Virtual Reality Markup Language.) it was a text based language for describing virtual world scene graphs. there was an interactivity model for VRML, so you could get objects to do things by interacting with the virtual environment. but for the most part, tools that used VRML rendered scene graphs on local systems and did not interact with remote systems or users.

so you loaded a virtual experience from local storage or from the web, rendered the scene, twirled around to look at the objects and could optionally interact with this "pocket universe."

some of the tools seemed advanced (even for today) and you could mock up some relatively interesting scenes. but, at the end of the day, there were no standards for how to invite other participants into your virtual creation.

this is NOT what VWRAP is all about. VWRAP is about multiple individuals accessing the same scene graph hosted on a public server somewhere and everyone sees the same thing when they log in. VWRAP worlds are inherently shared experiences, not pocket universes on someone's desktop system.

avatars have a single, unique presence in a single virtual world

like the reified world, the virtual world is a social space. the locus of social activity in the virtual world is the user's avatar; each avatar representing a single user. with due respect to even the best "real world" multi-taskers, you can still only be in one place at a time. so it is with avatars in the virtual world.

it also means that for every different virtual world, there is only one of you. by default, you can interact with everyone else in the world and they can interact with you.

the virtual world contains persistent objects

objects in the virtual world, like virtual worlds themselves, persist beyond a user's presence in the virtual world. if a user created a desk and chairs in a VWRAP virtual world, it would continue to exist until explicitly deleted. so the user could log in, create an object in a particular location in the virtual world and then log out. when another user logs in and travels to the same location, they would see that object.

the "intro and goals" draft referenced above describes these characteristics in more detail, but the text here describes the basics of VWRAP virtual worlds: there's only one of you, there's stuff in the world and the world doesn't disappear when you turn your back.

notes on the history of the VWRAP working group

after my last post about VWRAP, a couple people pinged me asking about it's history. here is a quick narrative of how VWRAP came to be and where it might be headed next.

the effort to establish the VWRAP working group has been ongoing for about a year, and it has a surprisingly rich history for an effort that's been ongoing for that short of a period of time. our group is certainly not the first attempt to develop interoperable virtual worlds standards; that's been going on for quite a while.

VWRAP recent history begins with an interoperability test sponsored by IBM and Linden Lab in the summer of 2008. using ideas that had been discussed in the Second Life(tm) architecture working group, several users were able to teleport their avatars from Linden-owned to systems owned by third parties.

there were significant limitations however. avatar appearance was inconsistent across regions and cross-grid access to inventory was more or less nonexistent. but as a first step, it showed that cross-grid teleports were possible.

interested users can find documentation of the protocol used by these early interop trials on the Second Life(tm) wiki:

• introduction
• LLSD
• authentication
• teleport
  

later that year we entered a time of economic uncertainty. virtual world interoperability did not seem to contribute to the bottom line, and there were significant near-term opportunity costs. "let's type up a report on our experiences, publish our final OGP drafts and focus on less risky things for a few months before coming back to it." we were in the process of mothballing the interop effort when things took an interesting turn.

inside the lab, we knew the UDP-based legacy SL protocol had some serious scalability problems; we wanted to move more services to LLSD over HTTP. most of our work serialized LLSD messages as XML documents and sent them over the internet. as part of our "wrapping up" process, we figured we should register the MIME types we used for LLSD. this was the motivation for the original "LLSD Abstract Type System" draft published in early 2009.

at around this same time, the bidirectional http effort inside the IETF was heating up and mark lentczner was asked to submit a draft and a presentation on "Reverse HTTP" which was based on previous work at the lab with donovan preston.

originally intended to be small, stand-alone drafts with a limited scope, we began the task of publishing an informational RFC for the purpose of registering the LLSD MIME types.

starting a virtual worlds working group in the IETF was not a new idea. the SWMP mailing list had been setup in 2007 to discuss the idea. it eventually failed to result in a working group for reasons that are too complicated to discuss here. there was considerable resistance to the idea, but around this time, david lavine at IBM started asking "what's next with interop?" david and suzy deffeyes had invested a fair amount of effort in the 2008 interop trail, so it was a reasonable question.

the more we talked about it, the more it seemed like a good idea. in early 2009, mark lentczner and i lobbied inside the lab for the idea while david and suzy pushed the idea inside IBM. the IETF does not officially recognize corporate members, people who show up at IETF meetings represent themselves. but if a working group was ever to be formed, but none of us felt comfortable pushing the idea without the support of our management.

we eventually produced an argument for interop good enough to garner support inside IBM and linden, so in january of 2009, david lavine of IBM and i approached the IETF informally with a proposal to sponsor the work of developing a virtual worlds interoperability prototype. at the time, we had hoped to develop a protocol that would work for a broad range of virtual experiences.

IETF process calls for a "Birds of a Feather" or BoF meeting to be held to see if there is sufficient interest to justify creation of an official working group. on march 24th, 2009 the "MMOX BoF" was held at the 74th IETF meeting in San Francisco, CA.

it did not go as well as we had hoped, but it didn't go as bad as we feared it could.

we were unable to reach consensus for "broad interoperability." we would not be able to, as david lavine once hoped, "meet with your raiding party in the sims online, teleport over to world of warcraft(tm), slay a dragon and then teleport to a pub in Second Life(tm) to celebrate."

but we did discover that there were enough people at Linden Lab and in the OpenSimulator community that were interested in cross-world interoperability. the IETF allowed us to redefine our scope and hold a second BoF session. on july 28th, 2009, the "OGPX BoF" was held to discuss the scope of the work (OGPX standing for "Open Grid Protocol X".) this meeting went well and following some discussion on the ogpx@ietf.org mailing list, we were able to agree to a group charter.

in the IETF, a working group charter defines what the group is supposed to be working on and what documents it proposes to produce. you can view the current charter for the group at http://www.ietf.org/dyn/wg/charter/vwrap-charter . along the way, a number of people objected to the name "OGP" or "Open Grid Protocol" as they felt it implied the objective of the protocol was to manage cloud or grid based systems. many alternate names were proposed (including my favorites Open Virtual EnviRonments (OVER) and Agent BackbOne for Virtual Environments (ABOVE).)

eventually settled on the name "VWRAP: Virtual Worlds Region Agent Protocol."

as an aside, after changing the name from OGPX to VWRAP, we forgot to change the name of the mailing list until very recently. the current mailing list is vwrap@ietf.org, though there has been significant discussion on ogpx@ieft.org and mmox@ietf.org.

on march 23rd, 2010, the working group held it's first official face to face meeting in Anaheim, California. it was a mixed reality event with approximately 15-20 people being present in incarnate reality and 50 avatars attending in the virtual world.

the work continues on the vwrap mailing list, and anyone with an interest in virtual worlds interoperability is encouraged to participate.

what's the Virtual World Region Agent Protocol ?

i recently had the pleasure of talking with Maria Korolov at HypergridBusiness.Com. she was interested in understanding the differences between Hypergrid and VWRAP. (who knows, maybe there will be a story about it in the near future?) but this sort of got me thinking, there are very few places an interested non-specialist can go to learn about VWRAP, it's goals and approach to virtual worlds. this blog post is an effort to fill that gap.

what is VWRAP?

the Virtual World Region Agent Protocol (aka VWRAP) is an application layer wire protocol used to create "interoperable virtual experiences." it is also the name of the working group inside the Internet Engineering Task Force (IETF) developing the protocol.

okay... so that's a mouthful; let's break it down.

a "wire protocol" is a set of conventions and standards describing data flowing over a network. HTTP for instance, or SMTP are both wire protocols; they describe the format of messages web browsers or email clients generate. a protocol doesn't equal an implementation. the apache web server, for instance, implements the HTTP protocol, but does not define it. so it is with VWRAP virtual worlds: the protocol lists what data is exchanged in between systems cooperating to "create" the virtual world. VWRAP is expected to be implemented by server software at Linden Lab, the OpenSimulator project and SimianGrid (formerly Cable Beach.)

we say that it's an "application layer protocol" because it makes use of familiar net protocols for moving information around. that is, VWRAP messages are carried by HTTP and (possibly) RTP, the protocols responsible for the web and VoIP.

and what's an "interoperable virtual experience?" this just means that virtual world viewers can use VWRAP protocols to simulate a virtual world shared by multiple participants. i like to say "virtual experiences" these days as i've been involved in some pretty heated debates as to what the term "virtual world" means.

so VWRAP is a protocol and a community of people working to build systems that let users have a "Second Lifelike" experience, but in an "open" virtual world. that is, you can have an experience that looks like second life, but does not require your virtual locations or virtual belongings to be hosted by machines owned by Linden Lab.

why is VWRAP not like Hypergrid or OpenWonderland or Croquet or ... ?

there are several virtual worlds out there ranging from the game-like World of Warcraft(tm) to the open-ended Second Life(tm). Some are open source projects like Croquet, RealXtend, OpenWonderland or OpenSimulator. Others are commercial services like ReactionGrid or cooperatives like OSGrid.

VWRAP is not an implementation or (like Hypergrid) an extension to an existing implementation. it is an open protocol, developed by a community of interested parties with the intent that anyone can choose to implement it. so VWRAP will not be a new product, but likely a new feature to existing implementations and services that will make it easier for them to communicate with each other. (though there are sure to be "sample implementations" of the VWRAP specifications.)

VWRAP is "Second Lifelike" in that it assumes a virtual world somewhat like Second Life(tm) or one created with OpenSimulator. World of Warcraft(tm), Croquet and OpenWonderland use protocols that are significantly different from the ones for Second Lifelike worlds. and the way they think avatars will interact is a little different. it's not impossible for these systems to use VWRAP, but they're not what VWRAP was intended to support. (though there may be ways for these systems to use pieces of VWRAP. more on this later.)

another important feature about VWRAP: some people will consider it incomplete. the people behind VWRAP chose to NOT standardize certain features of virtual worlds. VWRAP does not include standards relating to ecommerce or "game script" like linden dollars. nor does it describe standards for virtual land ownership like Second Life's parcels and estates.

it does, however, make it easy to define new services and to extend existing services. so it should be pretty easy to extend Linden Lab's Snowglobe viewer (and other open source viewers) to support different, world-specific ecommerce and land ownership features. so you may not get to use linden dollars on OSGrid, but if a region owner wants to support something else, it should be pretty easy for the viewer developers to code to it.

in other words, virtual worlds users should find the software they use get a little more robust and should see new features emerge a little faster.

so to recap: VWRAP is a set of protocols, not an implementation. VWRAP protocols are expected to not only be the basis for new products, but also to be added to existing systems as extensions.

what is the IETF and why is it important to this discussion?

the internet engineering task force (IETF) is a "standards development organization" which focuses on internet protocols. it is well known for being the professional forum where TCP/IP (a very popular networking technology) and SMTP (the standard email protocol) were developed. the IETF is not a commercial organization; it's more like a non-profit or NGO. it's stated goal is to improve people's lives by making network equipment and software work together.

an interesting feature of the IETF is that when protocols are developed under it's auspices, they're considered "open" and "public." that is, there is no charge to implement them. you don't have to sign non-disclosure agreements and you don't have to pay money to download them. membership in the working groups that define standards is open to the public; anyone can participate. when Linden and IBM approached the IETF saying they wanted to develop a "next generation" protocol as an IETF activity, they were explicitly agreeing to public commentary and participation in the process.

that being said, there are some intellectual property issues. specifically, there is a patent held by IBM that may or may not have bearing on the implementation of VWRAP services. the IETF process requires participants to disclose any known patents related to the work. this allows developers to decide if they want to participate or agree to make a standard that may be covered by software patents. in this case, IBM filed the requisite disclosure and has offered VWRAP developers a blanket license to use their intellectual property for the purpose of implementing the VWRAP standard(s). i am not a lawyer, however. you should get competent legal authority to verify what i just wrote.

how will we know if we've succeeded?

there's been a little confusion about what we're trying to do with VWRAP. we're not trying to compete with Hypergrid or Croquet or OpenWonderland. rather, we're trying to define the protocol for services that anyone could implement, even 2d web services.

we'll know we've succeeded when after publishing our specifications, users can log into virtual worlds using their twitter or wikimedia account credentials. or if they're able to use the wikimedia commons as an asset server. or if they can teleport between OSGrid and Second Life(tm).

how can you help?

the VWRAP working group is made up predominantly of implementers. that is, people who write software are disproportionately represented. we need more input from people who deploy virtual worlds and from people who live in them. most of the discussions will be highly technical in nature, and that might be intimidating to some.

but it is an open process; everyone is welcome to listen to the discussion. as long as you're not abusive to other list participants, you are welcome to post comments or questions. keep in mind that the answers may not be exactly what you want to hear, and questions should be focused on the technology (and not Linden or OSGrid policy.) but as technology developers, we need to know what your use cases are.

the mailing list for this group is vwrap@ietf.org . a good place to start is by reading the "intro and goals" internet draft.

i hope this answers a few questions about the VWRAP protocol and working group. feel free to email me at OhMeadhbh@gmail.com with questions.