The heterogeneous OpenSim
Enter OpenSim deployment. Just like the Internet, there is no one-size-fits-all technical solution to implement them. It runs (at least) on Windows, Mac, and Unix back-ends — in fact, on anything that runs Mono. And several different Mono versions are possible (although early ones might simply not compile OpenSim). Servers can be co-located at high-end data centres with unlimited bandwidth, or behind corporate/academic firewalls, or just underpowered PCs in a basement connected to a home ADSL solution — or run from your laptop. OpenSim can be configured as a standalone version, or have separate central servers. The whole range of configurations include standalone sims connected to external central servers, all central servers on a single machine or on separate ones (that includes moving the database servers out for increased performance and reliability), or Hypergrid-connecting several servers which are technically under the same grid, but actually have separate storage on different places. Servers hosting sims are not limited to a single location: they can be spread around the campus, or even around the world, according to needs or capabilities. For instance, a multi-campus, multi-department university or corporation might have sets of servers running at each department, but keep the central servers for all the organisation on the main data centre. Or each department might have their own central servers. Or students (or employees) might just add their own regions running from their own desktops and connect “on demand” at will. Finally, unlike some have claimed in the past, all this can be made secure, using passwords and encryption to make sure that only allowed regions are actually interconnected with each other.
But it’s not just about running OpenSim in the same organisation. Thanks to Hypergrid, you can interlink different grids from completely different organisations. You set the level of trust you wish: you can set aside some public regions on your grid and allow everybody to teleport to them; or you can conditionally allow just incoming teleports from grids you trust; or simply shut the whole world out of your grid. Hypergrid links are actually just URLs, and, like on the Web, if you know the link, and it allows incoming users from other grids, you can then teleport to them. The analogy to the Web is really almost flawlessly implemented.
It has a twist, though, one that was not implemented on the Web as Tim Berners-Lee designed it. Avatars are not simply “dumb viewers”. They carry identity with them: a name, their origin (the grid they come from), and, of course, the avatar’s precious inventory. The equivalent on the Web would be the ubiquity of identity providers (Facebook logins, for example) where your profile data is “carried” with you when you log in to a third-party site with a Facebook login. The difference is that on the Web there are no standards (OpenID and Oauth are two attempts to standardise the process, but the Web is not consensual about a single protocol to deal with identity — you just have to deal with a multiplicity of different identity providers, and support as many as you wish). Also, “identity” on the Web is rather limited in what is stored: mostly just the name, email address, and sometimes the profile picture is carried from one website to the other.
On the metaverse, the avatar and its inventory — plus the 2D profile info — are part of the identity as well. And Hypergrid 1.5 neatly addresses it quite well. You really have to experience it to get fascinated. All your inventory comes with you when you log in to another grid, but your items are not immediately available to the other grid even though you see them in your inventory — you need them to be rezzed first. When you do that, the item is tagged with your creator tag (even across grids!) and with a set of permissions you assign to it. Similarly, if you buy content on a foreign grid, and teleport back home, it gets stored in a special new system folder called “My Suitcase”. These flag content from external grids, which are available on the foreign grid central servers, and which only move to your region if you rezz them.
Two other layers of absolute coolness have been designed into the system. One, of course, is what content is allowed to be transferred. You can configure OpenSim to not allow any content to move out of your grid. Similarly, you can prevent content from other grids to be brought into yours. While critics might say that this doesn’t cover all possible options, it goes a long way to implement minimal protection. Obviously that a grid owner can see a rezzed object and copy it directly from the database, and you can’t prevent that from happening — but that’s exactly the same argument as being impossible to prevent your avatar and attachments and rezzed objects to be copybotted on the Second Life Grid. There is simply no way to prevent that from happening.
But at least you have some control. If you do not rezz an object in a foreign grid, nobody can get that object forcefully out of your inventory — exactly like on the Second Life Grid. A visible object, of course (just like in SL), can always be copied illegally.
Giving OpenSim users the same kind of content protection that they get in Second Life (not more, not less) has made some content creators be bold enough to start selling that content on some OpenSim grids. And when I say “selling” I really mean a working economy with the possibility to exchange virtual money with so-called real money. And working across grids, too. All this is not only possible, but it has been fully implemented by the Austrian company VirWoX, who run a money exchange for several grids and for Second Life as well. This actually means that yes, you can transfer L$ to a few OpenSim grids… or use any of the many payment services (including bank transfers!) to put some money there. The important thing is that even though your “favourite” grid is not among the ones listed, you can still get “Open Metaverse Currency” dollars, and just teleport to a grid which accepts them, shop there, and go back to your “home grid”. The underlying technology has been co-developed with the University of Graz, and dozens of more grids are currently beta-testing the concept, so I imagine that the list will grow — as will the number of “competing” exchanges, of course.
Something you won’t see on the video is testing voice or cross-grid profiles. Voice is quite interesting. As some of you might now, Linden Lab uses Vivox as their voice provider, probably because Vivox has a lot of experience with providing VoIP for games and virtual worlds. Well, you can buy a license to use Vivox with OpenSim too. But you have far more options. OpenSim supports open source VoIP providers as well, Freeswitch being currently the more popular choice, but it’s not the only one. The interesting aspect of voice is that you can interconnect VoIP switches with each other and with the phone network. So, yes, this means that in theory you can talk on the phone with someone in OpenSim, much like the (now closed) AvaLine service once provided by Linden Lab. Depending on the technology used, spatial sound (like in SL) might even be supported as well.
Then there is cross-grid messaging, cross-grid profiles, and a lot of other services that can optionally be provided across interconnected grids. They require special plugins and a backend server to deal with them (popular options include SimianGrid, which is a separate project, but well integrated into OpenSim. The beauty of the technology is that it’s all Web-based with neat APIs. This means that all can call functions from remote servers pretty easily.
So… to recap, this is all that works in OpenSim these days: intergrid teleportation with cross-grid content transfer, with permissions and creation tags; groups; inter-grid profiles and communication; voice with telephony integration. Not too bad! And it still manages to do all of that fully compatible with the latest official SL viewers. If you use a tweaked viewer like the ones from realXtend, you can even get meshes; and some minor things, like saving WindLight settings on each sim, or having prims over 10 m, also work nicely. As does sim backup and inventory backup… and so forth.