Metaverse Ink

It took a long time, but OpenSim 0.7 is finally here! It’s quite difficult to explain the value of refactorings and of  re-conceptualizations of the software, which is what happened to OpenSimulator between 0.6.x and 0.7. Those things tend to be intangible at first (”WTF? This does the same thing! And it has bugs that it didn’t have before!”, etc.); the ROI only shows up later.

As an example of the new interesting things that can now be done, this new release features an embedded Web application for handling user registrations. It’s called Wifi. The features of Wifi are quite simple:

• Account creation, optionally controlled by the administrator
• Configurable default avatars for new accounts
• Account updates by both users and administrator
• Account deletion by administrator
• Password recovery via email
• Simple user inventory management

These features are enough for the worlds I run; they’ll be enough for many people, I think. This is just the first release, I expect Wifi to improve as we go a long — especially if more people want to help… I welcome help on this!

See it in action in one of my test worlds. Feel free to create a dummy account, login to it, recover your password, etc. And login to the world afterward. You can also use it for testing your own installation of the diva distro by hypergriding to it. (Note: this world is just for demonstration of Wifi and of the latest diva distro release; it will be shut down in a couple of weeks)

Wifi has a few interesting properties that make it a good fit for small-to-medium OpenSimulator-based virtual worlds. First of all, it doesn’t require the installation of Apache or other Web servers; it’s all done within the OpenSimulator code base. If you’re like me, you will think of this as a major win. Not having to install an additional major component like Apache and PHP/Python/what-have-you means less administrative hassle, less load on the machine, and just plain joy. Web app! No Apache! Just OpenSimulator! Yey!

Second, using the OpenSimulator code base brings many technical benefits. This isn’t an immediate benefit, but it is a benefit in the long run. Unlike the Apache-based Web apps that interface with the DB directly, Wifi interfaces with the OpenSimulator services layer using the core code, and therefore it is isolated from future changes to the OpenSimulator DB schema. In short, and of interest to diva distro users, Wifi will probably never be in the situation that other apps of the same kind are, always on the verge of being discontinued due to the hassle of making it catch up with the OpenSim schema. In the long run, this is a very good thing.

Third, technically, Wifi is a set of components that can be loaded up by both standalone simulators and Robust servers. What this means is that the exact same thing can serve diva distro worlds as well as larger grids in one seamless environment, OpenSimulator. I haven’t packaged it up for grids, but I might consider doing it at some point. So if your world grows to a medium grid, Wifi can handle it with no hassle.

Enjoy!

And, of course, also enjoy the extra security in HG 1.5, but that is invisible.

Here are the relevant links:

• Latest diva distro
• How to set it up in 5 steps (6 for *ix)

If you already have a diva distro up & running, simply run Update.exe on it and follow the instructions. This time, it’s really important that you read the release notes.

One last important note: the sequence of upgrades has a ‘pivot’ release at r12751. In other words, r12751 is a mandatory stop from all older releases. From r12751 on, upgrade gets you the latest. This new release today is r13458.

Yesterday, Stefan wrote down his thoughts on Linden Lab’s troubles. I loved that post, he’s right on. Let me add to that by stating the importance of the work that many of the laid off Lindens did, and the role of OpenSimulator from here on, at the technological level and beyond.

Things are moving into 3D, including the Web. I’ve been very excited with everything that is going on with WebGL. Sure, WebGL is still not good enough to render very rich scenes like those we find in highly immersive games, especially when the scenes aren’t optimized, such as the case with user-generated 3D content. But I have very little doubt that the needed optimizations will happen, and that soon we will have immersion on the web browser. It’s already happening. People want it, Google wants, it will happen.

So, let’s fast forward to the time when the Web browser can render rich 3D scenes, which, at the rate that the Google people and the Unity3D people are going at it, it probably is only a couple of years away.

Technically, the client-side is not the whole story. In order to develop highly immersive real-time environments with that kind of viewer, we still need a server side that can serve those 3D scenes in real-time to several clients. HTTP alone won’t do, it’s too slow. All MMOs use some sort of UDP-based protocol for the rapid state change notifications. HTML5’s Web sockets are there precisely for that reason.

Bottom-line: the server-side must serve more than HTTP.

There are a few of these game servers out there, the vast majority of them proprietary. Which is fine for the companies that own them. In the scenario where the browser is the 3D viewer, those companies can easily develop the necessary JavaScript components that talk to their back-end servers via WebSockets.

All these proprietary servers, however, are a bottleneck for the massification of 3D content on the Web. Just like for the Web itself, we need open source 3D scene servers. At the very least, we need open, standard protocols, so that people can focus on developing content without having to reinvent the network connectors, and the servers, from scratch all the time. (But with open standards come open implementations, so the result is the same: we need open source servers). Yes, we need an Apache for RT 3D scenes. Hmm, where did I hear that before…?

OpenSimulator, of course. When WebGL is good enough to render those rich 3D scenes, OpenSimulator will be there to serve those scenes in real-time to multiple clients. For free. This is the real importance of OpenSim, its main contribution. Another, secondary, contribution is all the research work that we have been doing in secure, portable identity with the Hypergrid. This is something that doesn’t exist on the Web, but it can be ported back. I’m not entirely sure the 2D Web needs it, but I’m pretty sure a web of virtual worlds needs it. Not all 3D environments will want to be connected in a web of peer servers; but many will.

In all of this, we must thank Linden Lab, especially Cory Ondrejka and Marc Lentczner, for making their protocol public; that made OpenSim legally possible. All other game companies are protective of their protocols, to the point that they go after anyone who tries to reverse-engineer them. That was not the case with Linden Lab, and we must thank them for that. They allowed us to focus on the server side. The fact that the client was available independently, for free, was no small thing either: it made the effort appealing to lots of people who got instant gratification of a Linden-like world on their own computers. More people means more eyes, more energy. MW and Lbsa were right on from the very beginning!

Going forward, the main challenge for OpenSim is to step back from the monstrosity of LLUDP and LLCAPs, which were designed for one very particular kind of environment, and figure out the minimum set of messaging that’s necessary to serve 3D scenes in RT to multiple clients. Minimum is good. The good thing about OpenSim is that the client protocols are plugin modules; OpenSim is not tied to any one particular client, not even LL (in theory; the reality of the code is a bit different… that’s why I say that stepping back from the LL protocol will be a challenge for OpenSim).

I feel like we’re parting ways with a long-time, dysfunctional, companion who decided to make a left turn, and I’m looking forward to what’s coming!

The news came yesterday after lunch: major layoffs at Linden Lab, as much as 30% of their employees. Lindens who had been there from early on, respected engineers, all laid off. All of those who had, at some point, been involved in the idea of virtual world interoperability — gone. Then the new vision: Second Life on a browser, accessible to the masses via well-known social networks. Wow. This is what I call a 90-degree course adjustment.

Clearly, I know nothing about the internal situation at Linden Lab. Probably their VC money has dried off, maybe their revenue is not enough to pay so many people. Who knows what’s behind a 30% ‘rightsizing’… But the new vision is an indication that this is not just about balancing the budget sheet; it’s about redefining what Second Life is. LL’s CEO wants it to be more like FarmVille than like World of Warcraft. Too many people have commented on his vision, I’m not going to do it. He’s the head of the company, he should try to make his vision come to life.

What I want to talk about here is what this 90-degree course adjustment entails for OpenSim. I confess yesterday I had that familiar feeling of having reached the point of having to stand and lead. Not me, personally. But the OpenSim project, as a whole. The torch is on us. Let me explain.

In spite of being inherently a rebellious project, OpenSim has always existed in the shadow of Second Life. The rebellious nature was, indeed, just a confirmation of that dependency; the kind of relationship teenagers have with parents. A lot of people in the OpenSim community have been assuming that, sooner or later, the large Second Life virtual world would be trading avatars and money with OpenSim-based grids. The Open Grid Protocol (OGP) prototype, first unveiled in the summer of 2008, was a teaser; a promise of what could come next. Many OpenSim core developers have been deeply involved in efforts for virtual world interoperability, first in the Architecture Working Group, and, recently, in the VWRAP working group at the IEFT. Both of these working groups were led by Linden Lab engineers… who have been laid off.

In the wake of these layoffs, the idea that Second Life will be part of a larger web of virtual worlds is today more remote than ever. There’s no one left in Linden Lab to carry the interoperability torch, at least not of the kind we were thinking. It looks more likely that Second Life will be part of the Web itself, complete with the Web’s inability to deal with portable identity, and therefore eager to serve the largest pool of users on the Web, the 400 or so million Facebook users.

It’s always hard when the driver we were relying on suddenly makes a left turn from where we thought we were going. The question for OpenSim now is this: do we really want to follow Linden Lab on that left turn? Or do we take the torch and lead?

Personally, the last thing I want to do is to be involved in one more Facebook app. That’s the kind of interoperability project that I give my undergrad students on a 3-week time period. Not only it’s technically uninspired, but it’s missing the core of what I believe interoperable virtual worlds can bring to the Web itself: true, S2S portable identity. Not just “this is me” a-la OpenID, but “this is me, and I have a lot of baggage that I want to access while I’m visiting your site.” The vision of interoperable virtual environments is as exciting to me now as it was 3 years ago.

As usual, I don’t speak for the entire OpenSim project. And it’s probably too early to internalize what this course adjustment really means for OpenSim. But one thing is for sure: if there is going to be a web of virtual worlds, a decentralized S2S system of 3D environments that can seamlessly exchange user agents securely, that web will be made of OpenSim servers entirely, for the foreseeable future. Second Life is out of the picture.

You knew this was coming, and here it is: Metaverse Ink Search is now serving OpenSims around the world! This has been in the works for a while — in fact, it has been working for a while — but we kept it under wraps. A month ago or so, Eric Reuters wrote an article about it, but we still didn’t say much of how this whole thing works for OpenSim. This post explains it.

We worked with the OpenSim project in implementing the basic plumbing for search engines to operate in virtual worlds. We think this basic plumbing is the right support for searching virtual worlds, be them closed or open to the world wide web, and we are happy to see the grid-wide search project now using this same basic plumbing. The fundamental design philosophy is that the region’s data exposure to clients other than the viewer is a decision that involves 3 authorities: grid operators (if regions are connected to grids), region administrators, and parcel owners/content producers:

• Grid operators decide whether the grid is to be closed or open, and the amount of openness.  For closed grids, their data should be off-limits to external search engines like MI Search, just like the data in Bank Of America is off-limits to Google. This can easily be achieved by setting region configuration variables appropriately. Those configuration variables can be set so that only a grid-wide search engine can access the regions’ data.
• For open grids and standalone sims, region administrators decide whether to expose the data, the level of data exposure, and *which search engines can access it*. This last part makes virtual world search subtly different from web search, and for the better. On the web, search engines find web servers, and their pages, by following hyperlinks. All data reached is assumed to be public and, as such, indexable. This has caused a lot of pain on the Web, so let’s not go there. The idea here is that region administrators decide who indexes their data, and how much data is exposed to them. Data can be exposed to one or more virtual world search engines.
• Finally, parcel owners and content producers decide what data is intended to be found by checking the “show in search” check box in parcels and objects. In OpenSims, that checkbox tends to be free of charge.

All this is accomplished by configuring a core module of OpenSim called DataSnapshot. The configuration is done in OpenSim.ini, in the section pertaining to the DataSnapshot module, and it allows the variety of behaviors described above. So if you want the searchable data in your region listed with MI Search, go ahead and configure OpenSim.ini for it.

A second optional module deals with serving images (see how it looks here). This module, called ImageService, is a region module that extends regions with the ability to serve images onto the Web, so that explicitly marked, rich 2D content can be shared within a grid and/or with the whole world. The only images served are those whose keys are exposed via the DataSnapshot module, i.e. images related to things marked for search. That way we avoid exposing the entire collection of textures stored on the grid/asset server. The ImageService module is available from OpenSim’s GForge. If you want MI Search to show pictures of your wonderful regions, go ahead and place the dll of the ImageService in your OpenSim/bin directory.

The DataSnapshot module has been part of OpenSim since April 2008; the ImageService is our latest addition. OpenSim region operators have been able to figure it out, even though there were no announcements whatsoever. So much so, that we now have hundreds of regions on our opensim index in a variety of places, grid-ed and standalones. We are really excited to provide the first glimpse of the emerging Virtual World Web!

We’re delighted to announce that Metaverse Ink’s OpenSearch has been selected as the default interface for search in the new viewer realXtend, whose 0.2 release was announced today. The realXtend project has been working closely with OpenSim in order to add some major features to it, both in terms of graphics and in terms of the underlying architecture of virtual worlds. The most important addition is the idea of an “avatar system”, a piece of the architecture that sees avatars as entities that can move freely between worlds — not just sims on the same grid, but sims on different grids. An avatar has an identity and an inventory, and that’s what’s being served from that component. The avatars themselves can now be created with a standard 3D modeling tool.

We believe that OpenSim, with these realXtend additions and other additions that are already in the making, is the future of interoperable virtual worlds. We are excited to be a part of it!

So, download realXtend, and try it out. Don’t forget to click the Search button and see OpenSearch natively served. Now you have a choice on the search engine you use for each search, just like what happens in modern web browsers.

Happy Searches!