VWRAP is in limbo. Even though I was not involved in it until recently, I feel bad that it may simply disappear. It feels like a massive waste of energy for those involved for longer than I was; but, more importantly, it feels like a missed opportunity for gathering a critical mass of virtual world / virtual reality engineers — a community that seems to be plagued by silos– together with a critical mass of people who have been driving some important protocols on the Web.

The Past

To recap,  here’s a brief history of that working group, from pieces that I can gather from memory and from Google. The IETF WG was spearheaded by people in Second Life’s Architecture Working Group, a group that seems to have had its first official meeting in September 2007 and that still exists today despite the severe lay offs at Linden Lab. The IETF working group started in March 2009 as MMOX, with the goal of discussing virtual worlds interoperability. They had their first BoF that month. Linden Lab was the dominant leader, but at that time they were able to attract a few respected engineers who had nothing to do with Second Life, such as Jon Watte (of Forterra, now at IMVU), Heiner Wolf, and others. Even Larry Masinter, a prominent figure in the W3C, was there. There seems to have been lots of heated discussions about the meaning of interoperability. By October 2009, MMOX changed its name to OGPX — the original Second Life / IBM “Open Grid Protocol” — and the non-SL engineers stopped contributing. The group started discussing what seemed like a generalization of OGP that they termed Virtual World Region Agent Protocol. In April 2010, the group changed its name again, this time to VWRAP. At that time Linden Lab started laying people off, with the big layoff in June 2010. Soon after, Joshua Bell, Linden Lab employee and one of the co-Chairs of the working group, announced that Linden Lab was suspending its involvement in virtual world interoperability. At that time, there were several working drafts submitted, and people chose to continue the discussions.

That’s the story, in a nutshell. Here is my take on it.

The original idea behind MMOX was very exciting. Could they really come up with bridges of some sort between many different virtual worlds that use completely different technologies? Well, at least OLIVE and Second Life — that would have been a major technical win. Unfortunately, the discussion quickly converged to no — “quickly” as in 2 days after the MMOX mailing list started in March 2009. There seemed to be a disconnect between the people pushing for Linden Lab’s drafts and the people who submitted the other drafts (unfortunately, none of those drafts mentioned in the ML archives  are available anymore). According to this,  at the first BoF, a suggestion to split the group into several groups seems to have touched a nerve — perhaps by hinting at the technical or social or political impossibility of satisfying the different notions of interoperability floating around.

Compared to MMOX, OGPX/VWRAP was a lot less exciting. The original goal had failed. Nevertheless, Linden Lab and the community around it proceeded by focusing on a possible variation of Second Life that would be decentralizable, supposedly with OpenSimulator-based worlds playing an important role in that. But with the departure of Linden Lab from the interop scene in June 2010, the existing VWRAP drafts and discussions were left hanging in air; the only viable system to apply them to was… OpenSimulator itself. But from all the core developers of OpenSimulator, only John Hurliman had made significant contributions to VWRAP. With this impending scenario of having OpenSimulator be the lonely target of VWRAP, that’s when I decided to take a closer look at what that group had been discussing, at the end of August 2010.

I started by reading all the active drafts: the intro,  the authentication, and the type system. I confess I was completely puzzled by what I read. I made a journal-style review to the intro document, and sent it for discussion to the ML. I could have also commented on the other drafts, which were equally puzzling in their own right, but the intro seemed to be the root of the puzzle. There was silence for a couple of weeks, and then hell broke loose.

The Options

Perhaps it’s a good thing that VWRAP dies. But it really is a shame that the original idea behind MMOX didn’t happen. Eventual drafts coming from that group would be secondary to the value of bringing a critical mass of VW engineers together. So here is a post-mortem of what I think the disconnect was in the very beginning of MMOX. Maybe there will come a time when people realize what went on and start talking again.

A group like that would benefit tremendously from thinking of interoperability within the REST style of client-server applications, even if many VW engineers look at REST and the Web browser as a threatening alien invasion. There are lots of misunderstandings about REST; suggested readings: this and this. Once you grok it, think in REST for conceptual clarity regarding the importance of independent evolution and variability.

Think of the VW client-server protocols as something opaque that no standards body should interfere with; like Flash for example. So SL would be application/sl, OpenWonderland would be application/wonderland, WoW would be application/wow, IMVU would be application/imvu, etc. Imagine that there are browser plugins for all of these MIME types, just like there are for Flash and Unity3D. These MIME types may or may not be publicly documented, which is to say that these protocols may be public or proprietary — and that’s ok. I stress that this REST/Web-browser model is just for conceptual clarity; in reality, there can be fat clients for each of these applications.

As much fun as it may be to design these protocols and UIs, there’s nothing particularly standardizable in them. Diversity here is a good thing, because there are many different ways of doing these protocols and UIs, and companies have competitive advantages in rolling their own. Their solutions may bomb; but diversity is very much needed.

Rather than trying to force everyone into using exactly one and the same client-server application protocol, the pertinent question for interoperability is the one that Jon Watte was pushing for in the very beginning of MMOX, but now using my suggested conceptual model: how can a server-side that serves application/sl to its clients interoperate with a server-side that serves application/wonderland and with another that serves application/vnd.unity? The answer is in 4 parts:

1. If you have an application-specific client (e.g. the SL client or the Wonderland client, non-REST style systems), then, by default, interoperation is limited to offline data exchanges, because of the extreme coupling between the client and the server side. Maybe we can all agree on a common representation of 3D objects, so that objects created elsewhere can be imported by all these applications. COLLADA seems like a perfectly good solution. With luck, interoperation can also happen for certain capabilities of these worlds, such as IM, if the different applications happen to have been designed for that.
2. We can design decentralized systems within each application type. So, for example, OpenWonderland has its own federation mechanism. The OpenSimulator Hypergrid is a federation for SL-style VWs. The OGP protocol, before it derailed into VWRAP, was headed in the same direction. This is a shallow concept of interoperability, because the decentralization mechanisms are bound to the specific application types. We can bring one of these up for a standard, but it will be a shallow standard, worsened by the fact that each application type has its own ‘natural’ design for its federation, largely influenced by the already extremely high coupling between clients and servers. So for example, the Hypergrid federation works for the Linden Lab client as-is. But if the Linden Lab client is modified to account for the existence of a federation, then the design of such Federation may be quite different. Coupling galore!
3. We can design protocol bridges ala LESS. In this case, we extend our server-side to peer up with servers of different kinds for the purpose of extending the space in co-simulation style. This is an interesting concept that allows true interoperation between VWs of different types while allowing everyone to keep their own fat clients. An advantage of this approach is that the simulated entities never leave their home worlds, therefore being a good basis for protecting IP (only rendered data needs to flow). The main disadvantage is that it requires server-side computational duplication. That is, if I want my world’s users to connect to someone else’s worlds, I need to allocate computational resources for the co-simulation in my world. Another disadvantage is the engineering nightmare of developing those bridges.
4. If you have an application-agnostic client like the Web browser (REST style), true interoperation can happen without duplication of computational resources and without having to build protocol bridges: as the user moves from one server-side to another, the browser simply loads the corresponding application client program. It becomes possible for these different server-sides to engage in interactions that negotiate all sorts of things as the user moves around (i.e. OpenID and beyond). Here we’re not limited by the client speaking only one application protocol anymore, because the protocol comes to the client dynamically — code-on-demand is one of the principles of REST style applications.

#1 is a solved problem; it’s just a matter of will on the part of VW implementers. The other 3 are more interesting as they support online, RT interoperability. I highly recommend anyone interested in interoperability to roll their own federation first. But please don’t bring it up for a standard — that’s quite an arrogant move! If you want to document it, do what Google recently did with VP8 — submit an IETF Independent RFC at most, or simply document it outside of the IETF (example). #3 is a good short-term solution for true interoperability between different types of VWs, but presents engineering challenges that do not scale. Only #4 scales — not surprising if you understand the goals of REST.