Approaching Virtual World Interoperability

Several new developments are brewing in the metaverse. The Massive Multiplayer Online Experiences IETF group has started to form, co-chaired by Linden Lab and IBM. Linden Lab has started publishing standards drafts for virtual world interoperability. OpenSim has started exploring linking grids together with HyperGrid. The topic of virtual world interoperability is at the forefront of many people's minds. Due in part to the success of the web model (everyone can run their own website), individuals and businesses are waiting for the opportunity to run their own virtual world simulation, content development or storage business, spatial search engines, or maybe a mashup service that twitters virtual world activity. But before this can happen, the barriers need to be broken down between the walled garden virtual worlds of today and allow virtual concepts (identity, persistence, content) to move between worlds. How we get there is the topic of a heated debate.



First, some definition of terms. When I talk about multiple virtual worlds or multiple grids, I'm referring to multiple (independent) administrative domains. Intel has a vast set of web services that they offer under a single administrative domain at intel.com. I have my own personal blog and an OpenID service at jhurliman.org, my own administrative domain. This blog links to both intel.com and jhurliman.org, creating a possible interaction for the reader with those domains. Virtual world interoperability is about exploring the possible interactions across virtual world administrative domains. Even the simple concept of linking raises questions about carrying avatar identity and appearance across domains, and the complex topic of content transfer touches on nearly every hot security issue from DRM to webs of trust.



It always helps to start with a use case to ground discussions in reality. In an interview with Reuters, David Levine from IBM coined a popular use case that has helped shaped the conversation around virtual world interoperability. “Success in this space means killing a dragon and taking its head to another grid, slapping it down in a nightclub and having a disco,” he said. To map this back to virtual world interoperability terms, the use case would be obtaining some content in one administrative domain and transferring it to another administrative domain. There is an implicit notion that you have to obtain the content in administrative domain A before "slapping it down in a nightclub" in administrative domain B. In other words, preserving the scarcity (and therefore preserving some value) of content across administrative domains.



Preserving scarcity of a virtual good across administrative domains brings up a number of issues. Why is that content scarce in domain A? Do the same reasons for scarcity exist in domain B? The content may be the result of a difficult quest in the fantasy world of A, but how do you preserve the meaning in domain B and make it more than just another disco decoration?

 

Solution #1: Let the courts decide



In this approach, we assume the dragon head is implicitly valuable. Possessing a dragon head has value both in world A and world B. No technical measures are used to attempt to preserve the scarcity of content. However, a set of permissions can be assigned to content, and content fingerprints and auditing trails can help track down unauthorized usage. This approach has some proven value as it's the approach taken by Second Life, one of the most successful virtual economies, along with many web content businesses such as stock photo or 3D model vendors.

Solution #2: Move the content, reference the context


This solution assumes the content itself has no value, and all of the value exists in the contextual meaning of the content. The dragon head can be moved to a domain where it's assumed everyone will make copies and those copies will proliferate to even more domains. However, those dragon heads can link back to something in domain A that proves a particular user completed a quest. An example of this solution is the Xbox Live Achievements. I can put a "gamer card" on any website that says what my current Xbox gamer score is, and I can copy that content and edit my gamer score to say whatever I want. However, the real value of the card is being able to follow a link from it to http://live.xbox.com/member/jhurliman, which exists inside the xbox.com domain and authoritatively confirms what my Xbox gamer score is (would be much better if it wasn't for all this virtual world stuff).

Another version of this solution is to use cryptographic signatures to prove that domain A stated that some identity completed the dragon head quest. In the Xbox Live Achievements example, xbox.com could vouch that the jhurliman identity has a particular gamer score on a particular date. Although the implementation is different, it's still the same solution category because it assumes the content itself has no value. Only the contextual meaning of the content is valuable. If the dragon head itself had value, there's nothing stopping anyone from separating the content from the signature and copying it from one end of the metaverse to the other.

Solution #3: Digital Rights Management


In theory, DRM will allow content to carry an inseparable list of rights that governs usage. This is the content publisher's utopia, as content can transfer between any administrative domains and be copied any number of times, but the original publisher has full control over when, where, and how content can be used. An example of this is Apple's encrypted songs purchased from their iTunes store. It also means that no effort has to be spent developing virtual world interoperability standards that protect content, because the content can protect itself. The only problem is that it doesn't work. However, a reasonable approach is to stay open to the possibility that some domains will want to implement DRM regardless of technical feasibility, or that the technology landscape may shift in the future to a scenario where it is possible.

Solution #4: Trust maps


This category of solutions supports situations where the content itself may or may not have value. The general idea is to setup virtual world grids that have trust agreements and create a list of policies for content transfer. Domain A can say "I trust that domain B will take reasonable measures (such as solutions #1 or #3) to prevent users from making unauthorized copies of the content, therefore I will allow the dragon head to transfer to domain B". These policies are really just the technical implementation of a data sharing partnership. If Blizzard and Linden Lab want to allow content to transfer between the World of Warcraft and Second Life worlds, there is nothing standing in the way aside from a Simple Matter of Programming. Standards make the programming well defined, but selling this as virtual world interoperability is disingenuous. The other solutions attempt to solve the problem of content transfer between untrusted domains, while this solution dodges the question by growing administrative domains with explicit trust maps. Once you have have a million fantasy quest worlds and half a million casual social worlds all wanting to transfer content between each other, the N by N trust mapping fails to scale. Linden Lab's Agent Domain and OpenSim's current HyperGrid implementation fall into this same solution space on opposite sides of the spectrum (agent domain blacklists by default and hypergrid whitelists by default).

In Summary


None of these solutions preclude the others. In fact, solutions #1, #2, #3, and #4 can all be used in conjunction. Heated debate usually arises when one of these solutions is presented as "the" solution for virtual worlds, and a model for interoperability is presented that requires a particular solution or precludes other solutions. Whatever interoperability model finally emerges, it seems reasonable that it will support all of these possibilities and require none of them. That's part of what makes the web so successful today.
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.