second life : there can be only one?

the foreground lights dim as the camera closes in on philip linden (portrayed by christopher lambert.) viewable only in silhouette now, we see an exhausted fighter, his sword already falling from his hands. the decapitated heads of vivaty, metaplace and forterra are still rolling as the bodies that once supported them fall in slow motion to the ground. lightning dances around the industrial setting, lighting philip's face for a moment. queen's "princes of the metaverse" plays in the background as the words of mitch kapor (played by sean connery) echo in the ears of our protagonist... "there can be only one."

or at least that's the image i sometimes get when i hear when about virtual worlds failing. a lot of people have been trying to extract cash from the virtual world, but it's a tough market. and a number of people have commented lately that in the post-hype world, second life™ may be hurting, but it's at the head of the pack and has the market for social virtual worlds more or less locked up.

but is that true? can there be only one?

just to clarify, i'm talking really about public, social virtual worlds. i'm not talking about virtual world platforms or small, departmental virtual meeting rooms. i'm talking about full-on massively multi-participant experiences.

OpenSim is an excellent project; as is SimianGrid. both are open source projects intended to replicate the functionality of linden's server software. the former seeks to maintain compatibility with linden's existing protocols while the later is more focused on next generation VWRAP protocols.

but neither are virtual worlds as much as they are open source software projects. they are both excellent projects, but they both explore the "solution space" of the virtual world domain and not the "problem domain."

no... what i'm talking about is public virtual worlds, with's lots of space for a bunch of people to hang out in world and do those things that virtual people do. this sort of knocks out Croquet / OpenCobalt (which is also mostly a "project") and (sadly) vastpark and teleplace. they're not bad concepts, they're just not massive.

if you look over at the OpenSim Grid List, you see that there are several grids out there, but the number of people visiting them is tiny. why is this? why is it that OSGrid, the largest of the OpenSim grids listed, is only attracting one 200th of SL user base?

my guess is it comes down to functionality, economy and community.

kvetching about features OpenSim lacks out of the box seems to be a popular sport these days. but it probably doesn't do much for the world to repeat some of the more extreme arguments. at the end of the day, some people like the second life permissions system and some people don't. some people like in-game currency, other people don't. but it seems that of the people willing to pay money for virtual space, most people either want those features (so they can do commerce) or don't really care if it's there or not. it seems that few customers are actively opposed to operating in a virtual world with cash and permissions.

without a turnkey system for starting a grid with cash transactions and a robust permissions system, the cost of implementing these features falls to the grid operator. without the virtual economy, it's a little harder to attract people to your virtual experience, and thus your community remains small.

so what can you do to grow OpenSim or Simian or OWL based virtual worlds into mega-monster avatar playgrounds? simple. stop trying to be second life™.

i think the answer to the question "can there be only one second life?" is yes; there really can only be one. but you can go on to have a lot of virtual experiences that are noticeably different from SL, and in many ways product differentiators. so let's not talk about things in terms of second life, and start thinking in terms of "next generation virtual worlds."

the obvious one that everyone is talking about is, "make second life run in a browser." there are enough people out there talking about Unity3D, WebGL and OnLive that a quick round of googling can find you a depth of opinion. (for extra fun, search for "+rezzable +unity3d +opensim".)

the next obvious one is, "make your virtual world more social." it's clear from linden lab's recent moves that they've heard this one. they interpret it to mean "follow the money, integrate with facebook."

another differentiator that is near and dear to my heart is "let info flow in and out of the virtual world." Linden Lab introduced an amazing new feature recently with it's media on a prim and shared browsing experience. but the truth is, putting a web page up in a virtual world isn't exactly new. heck, even sirikata did it. NanoCosm was doing it back in the late 90's. but that's the simplest way to get info into the virtual world.

how 'bout we let in-world groups map to facebook groups and twitter groups? why can't i easily see my facebook friends and twitter followers in world? for that matter, why can't i just log in using my twitter credentials. they _do_ support OAuth, after all.

and assets. Second Life's asset system requires you to upload images and what-not to their servers. why couldn't i just point to a texture or a COLLADA .dae file out on the web somewhere and say: "when i drag this item out of my inventory, i want you to go out to the web to get the data used to render it."

so i think my key point here is... don't try to recreate second life. it's been done. it attracted a fair number of people and a lot of hype. move on, do something better.

the next five years of SL : or, yet another rambling blog post about second life

so the recent tumult at linden lab got me thinking about the lab, second life™, virtual worlds in general, people's brains and business. and apple; i live in the bay area, so when the subject turns to "turn around stories" we start talking about apple.

yes, you know.. apple. the people who make the iPad, iPod, iPhone, iTouch and iEverythingElse. it's hard to believe, but there was a time when apple products were the domain of artists, students and assorted nut-cases like me who just wanted to be annoyingly different. before the iPod, apple's profits came from selling half-rate knock-offs of the Xerox Alto system software wrapped around well designed, but marginally manufactured hardware. (that is until they started selling half-rate knock-offs of the Xerox Alto system software wrapped around Avi Tevanian's master's thesis micro-kernel wrapped around well designed, but not completely marginally manufactured hardware.)

now don't get me wrong, i'm not a wintel bigot; nor am i an apple hater. i'm just telling it a little bit like it is to make a point. in the 1990's and early 2000's, you were a fool to waste time with macintosh products. they were temperamental, expensive closed boxes and using them set you off from the wider community of PC users and the bazillion programs you could run under windows.

as much as guy kawasaki likes talking about how the early mac team was trying to build something "insanely great," the mac operating system rested too much on it's laurels. throughout the late 1980's and 1990's, apple's steve-jobs-less leadership frittered away it's leadership position shuffling business units, preparing them to be the "next new thing." while the public was introduced to a stream of "interesting" products like the newton, powerCD, quicktake, cyberdog, opendoc, pippin and macintoshTV.

so by the mid-90's, apple's arch-nemesis to the north was nipping on their heels with Window95 and MS Office. the good news for apple was the decision to build user centered software with GUIs instead of crufty command sequences was vindicated. the bad news was that the courts allowed microsoft to rip off apple's look and feel.

and then steve jobs returned from the corporate hinterland, slashing projects, killing divisions and laying off staff. at the time, apple employees had a term for it, it was called "steve-ing." as in... "wow. they laid off the kitchen staff for mariani 1, i think imaging products division is going to get steved."

so jobs came back, turned apple around and today iPads are flying off the shelf and jobs hob-nobs with guys who can launch nuclear missiles at the google campus.

but what changed? why are apple products now cool? (yes, this is where we start talking about second life)

apple products are cool because apple products appeal to both a user's need for functionality AND the user's emotional closeness to the experience of using those products. apple products are cool. they delight. when you use them, they treat you like a movie star. they make you the center of their little device universe. they are cool and that coolness rubs off on you. so no matter how much of a dork you are, if you're using an iPhone, you feel like one of the cool kids.

can we say that about linden lab products now?

okay. loaded question. let me ask it another way. how does second life have to change to bring back that sense of emotional closeness?

waaaaaay back in 2005 and 2006, the hype cycle was in full swing. everyone was convinced that this was the wave of the future and we would soon all be virtually working in our virtual offices. so you couldn't teleport or you crashed every 15 minutes or the whole grid had to reboot every thursday. it wasn't a problem because you were experiencing "the future." and when you participated in the future, it made you cool.

but the future was a reasonably crappy place to work. prototyping real products in SL was annoying at best, and often impossible. you could have a virtual PC on top of your virtual desk in your virtual office, but it was just a prop. you couldn't use it to collaboratively edit documents with people in your virtual crib until very, very recently.

second life was a taste of the future; distance would soon be a thing of the past. we would have meaningful human interaction virtually.

but the promise of second life wasn't enough to keep the broader community of technology innovators "emotionally engaged." that a core group of enthusiasts drove the content creation economy with such primitive tools is testament to the creativity and ability of second life's residents.

for the broader community of content designers who wanted to use SL to build things that would interact with the outside world, or even live mostly in the reified world, the time to frustration was often much shorter than the time to delight. and when you have a tool that frustrates you more than it delights, it's hard to have emotional engagement.

and that's where we're at now... second life is a pretty cool niche with a comparatively small community of people using it to build engaging experiences. for the last several years the business guys at linden have been trying to figure out how to break out of that niche.

philip rosedale's return to the helm of linden has invigorated the community, and everyone seems to have a different opinion of how the world went wrong and a different narrative for restoring it to its former glory.

some view SL as a "platform." that is, linden's value lies in it software. either as a service (as it is now) or as a product (like SL/Enterprise), they say that untold riches await the lab if they could just figure out how to market it properly. to grow adoption, you simply reduce costs, develop new markets and watch the cash roll in.

others view SL as a "community." that is, it's value lies in it's community, waiting to be monetized with search and ad sales. make it easier for facebook and twitter users to convert into SL users and watch the cash roll in.

and some people point to steve jobs' success in converting apple from a maker of second-rate computers into a consumer electronics powerhouse and say the lab should adopt an "experience" strategy. "engage customers and give them an experience that is emotionally meaningful for them." perhaps that means enhancing the graphics capability or enhancing in-world music events.

but the truth is, none of these approaches will work by itself. linden and second life are at an inflection point, much like apple was in 1996 when steve jobs returned to re-orient the company. apple had it's strategic re-organization that involved layoffs and management changes.

but one thing to consider is it took steve jobs about five years from the time he returned to the time the iPod was released. so even if linden is pointing in the right direction, it could be years before we see the next big thing out of the lab.

VWRAP still seems to draw breath, despite linden's reduced participation

so a couple hours ago, josh bell (aka joshua linden) sent out an email indicating linden lab (makers of the Second Life™ virtual world) no longer has the capability to actively participate in (or lead) the VWRAP working group within the Internet Engineering Task Force (IETF).

from josh's email message:

Linden has reduced engineering resources tasked specifically with implementing the standards emerging through the VWRAP WG process. Linden will continue to be engaged on efforts that directly align with business goals and current development needs, and in fostering the ecosystem around Second Life ... For the near term, however, Linden will not be explicitly funding production of specifications or implementations related to virtual world interoperability. Linden Lab continues to be supportive of the standardization process and we hope to be able to be more actively involved at some point in the future.

josh goes on to say that he'll be continuing to serve as working group co-chair, but will participate as an individual, not as a linden employee.

I plan to volunteer my personal time to mediate discussions as co-chair of the working group, as long as there remains interest in tackling issues within the VWRAP WG charter. As individuals, many other Linden Lab employees are and continue to be involved in standardization efforts, around virtual worlds and other IETF efforts.

so... does this mean that VWRAP is dead? i think the answer would be "no, not dead, but it's definitely a metaphorical gut punch."

at the end of the day, corporations do not participate in IETF activities, individuals do. so linden's decision to pull resources from it's participation in VWRAP does not automatically shut the group down. but, it's no secret that linden sponsored many of the activities, instructing it's employees to participate in the standards development process on company time.

but it's hard to sugar coat this pill; the loss of a large commercial interest is going to cause a bit of confusion in the near term. individuals are likely to still participate, but without linden it's unclear who would be deploying VWRAP based services. at the end of the day, we can specify whatever we want; but if no one actually uses the specs, what's the point?

but all is not lost; the business motivations that led to the formation of the VWRAP working group are still there. there is still a market in virtual worlds for education, enterprise and entertainment. specifying protocols for virtual world services is still useful for driving down the costs of virtual world hosting and for supporting innovative ecosystems. in short, the fundamentals are still sound.

but there's now a bit of an "influence vacuum." the 800 lb. gorilla has quietly exited the tent, leaving a couple 300 lb. gorillas and a number of consultants. so, it will be interesting to see if any of the remaining players steps up to take a leading role.

our efforts in VWRAP are still useful, but the individuals involved in the standardization effort are no doubt interested in whose business requirements will drive the effort: IBM? Intel? Reaction Grid?

so... anyone interested in driving a low-mileage, late-model IETF working group?

Second Life : Hits and Misses

Word on the street is Linden Lab, makers of the Second Life™ virtual world, is in the process of laying off staff and shuttering remote offices. The few stories have surfaced over the last couple days are fueled by rumor and inductive reasoning. ( See Tateru Nino's story "Linden Lab Laying Off Staff, Closing Singapore Office" at massively.com for an example. ) Tateru's narrative is well told, but as of yet, Linden hasn't commented publicly regarding staff reductions. Reports of instability in the Linden Dollar exchange, the departure of key employees [*] and a failure to meet resident growth expectations have been feeding rumors of Second Life's demise.

But I'm not ready write off Second Life just quite yet. A lot of cool stuff came out of Linden Lab and even if the rumors of lay-offs are true, there will remain a nucleus of highly competent people delivering innovative new services.

So while we're waiting to hear an official word from Linden about staff changes, let's take a quick look at some of the Linden Lab hits and misses.

1. *HIT* User Generated Content (aka UGC)

Linden didn't invent the concept of "user generated content," but they were one of the first groups to really run with it. While universes like There.Com and ActiveWorlds also allowed UGC, Second Life allowed users to upload textures and build content in-world without prior editorial constraint.

We're in a world of "remix culture" where content innovation is fueled by the never ending stream of ubiquitous, culturally relevant media. In other words, we create meaning by reworking existing context in new and better contexts. Whether it's an artist that places a virtual Gandhi avatar in a virtual jail cell or simply a group of people gathering in world to discuss ideas, society as a whole benefits from the understanding and insight that comes from placing old media in a new context.

In the future, Second Life will be remembered as the first popular virtual world that understood this interplay between media and context and made it easy for participants to communicate "insight" by means of radical juxtaposition of common, socially relevant symbols.

2. *MISS* User Generated Content (aka UGC)

But it's not all goodness and light out there on the grid. There are serious issues with content theft and misappropriation of digital assets. Linden's process for dealing with IP theft follows guidelines established after passage of the Digital Millennium Copyright Act (DMCA.) While the Linden process appears in accord with US law, it does little (if anything) to prevent IP theft. Instead it provides a mechanism to repair damage already done; it requires IP owners to police the entire virtual world looking for infringers.

UGC is Second Life's "raison d'être." Without it, it would be an exceedingly bland experience. Some would argue that this virtual world is based on a system that ultimately discounts real world IPR by making infringement laughably easy.

3. *MISS* Pornography

The most obvious issue with the lack of prior editorial control on user generated content is the presence of pornography and obscene adult materials on Second Life's main grid. Expression of every carnal delight may be found in second life, ranging from "mildly unusual" to "outright obscene." Second Life is very clearly an "adults only" space; do not leave your children here unattended.

4. *HIT* Pornography

One person's obscenity is another's harmless fantasy. People are sexual creatures and stigmatizing physically pleasurable activities as being "dirty" or "obscene" does little to advance society and culture. Providing a space where individuals may come to terms with potentially embarrassing fantasies in an anonymous manner might actually have mental health benefits. Members of the transgender and fetish communities may experience very real emotional distress that prevents them from exploring taboo subjects in real life. The virtual world provides a safe, anonymous space to develop an understanding of the sexual self. This is in no way a bad thing.

The virtual world can also be a place where the disabled are able to explore their sexual persona. In the west, we sometimes force disabled people into a very non-sexual corner.; sex and disability can be a taboo subject in mainstream culture. For many disabled people, creating a sexually explicitly avatar in a virtual world can be liberating; especially as they have direct control over the degree to which their "real life" disability is expressed in the virtual world.

5. *HIT* Group Building

Most virtual experiences use assets created by a single person on a single desktop machine. Sure, digital assets can be created by groups of talented artists, and I'm guessing that most are. At the end of the day, there's only one person with one mouse altering one copy of the digital asset. Once the change is complete, the asset is saved in a file and distributed to other participants in the creative process.

Second Life's model is different. Building is an inherently social experience. Assets are created in the same virtual world participants inhabit. In fact, it's quite easy to find groups of people collaboratively building virtual things in one of the many "sandboxes" spread throughout SL's main grid.

The Second Life build system is the 3D equivalent of tools like Google Docs or Etherpad, when one person rotates a piece of an object being built, everyone with an avatar in the vicinity immediately sees the result. Everyone can immediately critique (or approve) the change.

6. *HIT* Digital Economy

To be sure, selling things in Second Life can be a pain. But over the last several years it's gotten increasingly less painful. In many online virtual worlds and MMORPGs, you can only buy content from the company running the experience. Turning the virtual world into a venue for individual-to-individual transactions is a true "hit."

Transactions totaling millions of US Dollars are executed annually. Real people are making real money selling bits; and that's a beautiful thing.

7. *MISS* Land and Object Backups

In an ideal (virtual) world, the content you create would stand as an eternal testament to your creative prowess. Sadly, we live in a real world where software bugs, database failures and system crashes conspire to delete the fruits of your online labor. In Second Life, you build on the live system. While there are backups occasionally, it is all to easy for your content to mysteriously disappear.

Products like Second Inventory allow individual content creators to explicitly save their creations. Linden Lab appears to have an "uneasy truce" with services like Second Inventory. You may find some Lindens privately acknowledge the utility of backing up content, but no one will go on the record publicly praising or damning the service. Second Inventory (and similar utilities in third party viewers) can too easily be corrupted into a tool that could allow unauthorized content copying. Supporting such a tool would not be a move welcomed by Second Life's content creation community.

So a content backup tool, which would be of great utility to content creators, could also be perverted into a weapon that could destroy the livelihood of that same community. Maybe someday there will be a tool that gives people the ability to backup and restore content they own, and only content they own. But until that facility is perfected this feature is probably going to remain too dangerous for general deployment.

8. *HIT* Spatial Voice Chat

A fair amount of attention has been paid to virtual worlds as venues for education and business events. Whether you're talking about using the virtual world to teach classes or meet with your business partners, the experience is still pretty compelling.

A lot of people ask, however, "how is Second Life different than a chat room or a WebEX presentation?" And you'll get a lot of different answers to this question. But I recently had the opportunity to watch new users learn a bit about the virtual world. These were people who were technically savvy, but not "Virtual Worlds People." I was a little surprised to discover that after they learned the interface, they found the experience "reasonably compelling." When asked why, their response was... "it was easy to figure out who was talking."

So... virtual meeting planners take note: real people like it when it's obvious who's avatar is speaking.

9. *MISS* Walled Garden

Second Life has aspects of other great online systems: it has the social networking of Facebook and Twitter; it has the ability to host content like Flickr; and it has the ability to host group conversations like IRC or Google Chat. But Second Life is not Facebook or Twitter or Flickr or Google Chat. It doesn't do any of these things nearly as well as these sites.

And maybe that's okay. Second Life is about creating immersive 3D experiences. It is not about image hosting or IRC chat sessions. The 3D experience creates an engaging social context that you just can't get from the 2D web. It's okay for Second Life to not be as good as Twitter or Facebook on the whole social networking thing.

But what isn't okay is that I can't link my Second Life identity with my Twitter identity or my LinkedIn identity. My FaceBook friends are not automatically my Second Life friends, and that's a problem. The "friction" involved in engaging my external accounts in the virtual world means it will never have the size and scope Linden's executives keep talking about.

Until Linden breaks down the garden walls and allows virtual land, assets and identities to be hosted by external organizations, Second Life will remain a pleasantly curious island in the sea of internet commerce and communication.

Conclusion

So there we have it, my short list of Second Life's "greatest hits and misses." What are yours?

* In the interest of full-disclosure, I should remind readers that I worked for Linden recently, though my role probably didn't qualify me as a "key" employee.

meego 1.0 is vaguely awesome

people who know me will tell you i'm a bit of a unix(tm) fan. i grew up with it as a developer, cutting my teeth on BSD variants of the late 80's. linux is near and dear to my heart, but getting it to run on laptops has often been a labor of love. but as i get older, i find i want to spend less time monkeying with install weirdness and more time using my computer.

which is why i'm happy to report that meego 1.0 is a bit of a delight to work with. not heard of meego? it's the illicit love-child of intel's moblin effort and nokia's maemo platform. i've been using moblin 2.1 on a dell vostro a90 (aka mini-9) and have found it serviceable, but with a few quirks. meego seems to have improved stability and sound support a bit. but most importantly, it's beginning to feel like a real, usable system.

loading meego is as simple as downloading the image from http://meego.com/, copying it to a flash drive and booting. users of dell mini-9's will encounter a few headaches due to licensing restrictions regarding broadcom's wireless drivers. you'll have to follow the steps outlined at slaine.org to get the wireless driver working correctly.

so, if you have a netbook, you might want to check it out.

VWRAP essentials : an abstract type system? hunh?

today's VWRAP essentials post is for a more technical audience. if you're reading this, i'm going to assume you're familiar with VWRAP, the Virtual World Region Agent Protocol. if you need a refresher, you can look at "what's VWRAP?" post on this blog, read the VWRAP Working Group Charter, or read the latest draft of the "VWRAP : Intro and Goals" document.

early in the list of technical deliverables for the VWRAP working group is the document titled "abstract type system for the transmission of dynamic structured data." in this post we're going to answer the question "what is an abstract type system and why should i care?"

c? c++? python? c#? php? javascript?

so there are a bunch of languages used by virtual world programmers. which one should we standardize on? if you answered "we shouldn't standardize on any of them," then you gave the right answer. VWRAP is a wire protocol intended to be implementable by any language. if you can open a network socket and receive arbitrary HTTP requests, we're hoping you can use it to implement VWRAP.

but this introduces a bit of a quandry. the type behavior of languages is mildly different. integers in c are 32 bits in length, unless they're 16 or 64. JavaScript seems to not have a limit, transparently converting regular integers into multi-precision integers (except when it doesn't.) and in some languages the results of adding integers to strings isn't the same as others.

while most languages provide a plethora of types (like integers, strings, dates, etc.) the rules for adding them together or converting them to other types are inconsistent. in normal development this isn't too much of a problem; on the rare occasion programmers have to code in different languages, there are frequently tools to manage the differences. these tools usually only work on a specific system, however. they're designed not to work in the general case, but tailored for a particular development environment.

it's still really nice to be able to use familiar types like integers, strings, dates and so on when describing protocol messages. but if there's no easy way to convert between types used in different implementations, what do you do?

the LLSD abstract type system

an early version of the LLSD abstract type system was introduced internally in 2005 and was intended to hide type system differences between C++, python and ruby based services. the intent was to store structured data independent of language-based type behavior. when a python program read data written by a C++ program, it would know what the rules were. integers were ALWAYS 32 bits wide. dates were ALWAYS stored in the same format; not a 32 bit int on some systems or a string on others.

over the past five years, LLSD has been refined somewhat, but the basic rules are the same: there are a fixed number of types that all languages SHOULD be able to understand. there are a fixed number of serialization formats (currently there are three,) each with fixed rules about how data is serialized and later de-serialized.

the benefit of this system is if you specify your abstract type system used to store or transmit data, and you make the serialization rules easy to implement, future programming languages, environments and operating systems should have minimal problems parsing the data.

LLSD for the impatient

the LLSD abstract type system defines 11 types: undefined, boolean, integer, real, string, date, URI, UUID, binary, array and map. The last two are "collections" meaning they're... well... they're collections of other types. arrays are (as you might have guessed) collections indexed by position while maps are indexed by keys. the undefined type is present to represent situations where the existence of an item is implied, but there's not enough information to assign a type to a data element. an example of when you attempt to retrieve an array or map element that doesn't exist. instead of getting an error, you get an undefined.

LLSD defines conversions between types that your implementing language should support. type conversions will get more important later when we talk about the LLIDL interface description language and programming styles that support loosely coupled systems. but for now just know that if you really want to convert the type of a data element, that's fine. but LLSD has a few rules about the conversion.

LLSD also defined default values for each type. defaults surface when you make an illegal type conversion. so if you convert a date to a boolean, you'll get the boolean default value (false.) if you convert an undefined value into any other type, you get the default value for that type. so if you attempted to read past the end of an array and cast that value as an integer, you would get 0, the default integer.

LLSD has three serialization schemes: XML, JSON and Binary. Each scheme is, in theory, no better than the other, but they were each designed for slightly different use cases. The XML serialization scheme is useful for environments that already use XML for other reasons. JSON is useful for web services and the Binary serialization scheme is useful for systems that need low message processing overhead.

better examples of serialized LLSD data can be found in the internet draft referenced above. but here is a very simple example of a map with three members: an integer, a string and an array:

<llsd>
 <map>
  <key>name</key>
  <string>Zocalo Merchants</string>
  <key>priority</key>
  <int>12</int>
  <key>position</key>
  <array>
   <int>128</int>
   <int>192</int>
   <int>20</int>
  </array>
 </map>
</llsd>

maddening weirdness can be your friend

there has been some criticism of LLSD's behavior regarding undefined type conversions and what to do when accessing a non-existent collection element. there are some very good arguments in favor of raising an exception. the primary benefit is that if there's an error involving type conversion weirdness, developers are more likely to catch it if the system signals an exception rather than "fails silently."

but there are two arguments against raising an execption. first, it's more complicated and requires that error handling be added to the abstract type system. secondly, it may lead to redundant error checking and brittle systems.

the argument goes something like this: "if i'm writing a service consuming an LLSD message, i'm probably going to be checking values at the application layer to make sure they make sense. if i'm checking them there, why do i need the presentation layer to check that they make sense?"

this argument implies that erroring out when you find an "illegal" type conversion doesn't really buy you anything, and you would have to complicate the specification to support it.

conclusion

so that's it. LLSD is a pretty small specification. there are already several oepn source implementations for the curious, and the most recent specification is available at the ietf.org web site. please take a look at it and give us feedback on the vwrap mailing list.

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.