Grider: Prototypying the next generation Hypergrid
I’ve already blogged (here and here) about hypergrid, a virtual world architecture that allows the federation of Opensim grids (or “worlds”), and in particular teleports between grids. Using hypergrid, you can teleport, for example, from OSGrid to my grid, the Condensation Land Grid, or between OSGrid and Sciencesim, or between Sciencesim and the Cyberlandia grid, etc. Wagner James Au reported in the New World Notes blog about a demo run by Tom Murphy at the Metaverse University in which hypergrid teleports were shown between grids located in different parts of the US. Hypergrid is developing very fast, and once it’s stabilized and distributed widely, it will implement the vision of a world-wide network of connected grids, where big corporate or educational grids will coexist with small, home-based grids. And thanks to the hypergrid teleport, all these grids will appear as a single world like Second Life is today — hence the name “hypergrid” :-)
Here’s a sample video showing hypergrid teleports in action:
In this article I’ll discuss some details of the current hypergrid architecture, some of the security risks involved, and how a new, more secure hypergrid architecture (sometimes called “safe hypergrid” or “hypergrid 2”) is being developed.
Taking a look at the Opensim console
If you own an hypergrid-enabled Opensim installation, try the following: log in, and teleport from one region to another. You will see a lot of information scrolling through the Opensim console, but if you look at the logs, you will find something similar to the following (I’ve trimmed the timestamps and the full module name to make the information more legible):
[LOCAL INVENTORY SERVICE]: Requesting inventory for user 17fff378-c1ad-4b42-ae8a-dcb644a5ceaf
[LOCAL INVENTORY SERVICE]: Received inventory response for user 17fff378-c1ad-4b42-ae8a-dcb644a5ceaf containing 17 folders and 32 items
What are these lines, and what do they mean? Well, the Linden viewer (and therefore all the current SL and Opensim-compatible viewers, since they all are, to some extent or another, based on the Linden viewer) assumes that the region you are in will cache (i.e., make a copy of) all your inventory, so that when you interact with your inventory (for example, when you search for an item, wear some clothes, remove an attachment, etc.), this interaction is handled by your current region, which then forwards the request to the inventory server, if needed.
Why is this so? I really don’t know — all I can do is speculate. Maybe the Lindens designed Second Life in this way in the hope of minimizing the number of interactions with the overloaded inventory servers, or maybe there’s some other reason. The fact is that the Linden viewer works this way: when you teleport to a new region, all your interactions with your inventory are handled by this new region (in many cases you won’t even notice it, because all your inventory will have downloaded and will be cached by the viewer anyway).
A problem of trust
This mechanism works well in Second Life, where all the servers are owned and controlled by Linden Lab, and therefore trusted, i.e., you don’t expect a Second Life region (or, better, the server that runs the region) to act against your interests, or the interests of Linden Lab. Of course you can find an island run, or occupied, by griefers, and then the avatars in the island might harass you. But the idea that the server itself may act against you is unthinkable in the Second Life grid.
Let’s now try an hypergrid teleport, and look at the Opensim log. We willl find lines similar to the following:
[HGStandaloneInvModule]: Processing request for inventory of 17fff378-c1ad-4b42-ae8a-dcb644a5ceaf
[HGStandaloneInvModule]: Sending back inventory response to user 17fff378-c1ad-4b42-ae8a-dcb644a5ceaf containing 17 folders and 32 items
Apart from the fact that the module issuing the message has changed, nothing else seems to be different. Now that we are in a foreign region (i.e., in a region outside of our home grid), let’s wear something — the foreign region will honor the request, ask for the item to our grid’s inventory service if it does not currently have a copy of it, and once it receives the requested item, it will send it to our viewer. Now let’s purge an item. The mechanism is the same: the region will ask our home inventory service to purge the item, and then send us an acknowledgement, so that the item will dissapear from our inventory.
What about trust in this case? Well, we are in a foreign region, right? This means that we are in a grid that is not our home grid. Who can tell us that the foreign grid is not operated by pirates, instead of by nice people? Since our inventory is being copied to the foreign region, how can we know that the foreign region operators aren’t using a modification of Opensim that copies all our inventory to their grid, full rights and everything, so that they can use it themselves, or resell it as if it was their own?
Obviously this would be a very bad thing. However, it becomes quickly apparent that in an open intergrid situation we can’t really assume that we know anything about the region we are teleporting to — Indeed there is a situation much worse than our inventory being simply copied: imagine that the region we are teleporting to is run not by thieves, but by evil griefers. Since our home inventory service has to honour purge requests sent from the foreign region, the region itself can send a set of purge requests and erase all our inventory!
Cristina Lopes indeed programmed an experimental region (called “Do Not Come Here” for reasons you’ll quickly understand) that does exactly this: it erases all your inventory, as a proof of concept of the security problems of the current hypergrid implementation. That’s why if you look at the list of public hypergrid nodes in the Opensim wiki you’ll find a cautionary text that says “For the time being, and until the security concerns are addressed, we advise you to be careful about who you link to.”
The solution: grider, and the safe hypegrid
What’s the solution to this problem? Well, at first glance it seems very easy: write a modified version of the Second Life viewer that interacts with the inventory by talking directly to our home grid inventory service instead of using the region we are in as a cache. This way, we avoid all the risks and the hypergrid becomes safe.
The problem with this approach, now, is not technical, but legal: the Second Life viewer was released as open source using a GPL license. Basically, this means that if you make a modification to the viewer, you have to make your modification public, and your modification has to have itself a GPL license or a license compatible with GPL. On the other hand, Opensim is using a BSD license; this means that everybody can take the Opensim source code, modify it (or not), brand it with another name, and sell it.
In practice, this creates the following situation: no person that has looked at the code for the viewer can develop for Opensim, because this would automatically change the license of Opensim code to GPL, which is incompatible with BSD.
But we have just said that we need a modification of the viewer, and the lead architect for hypergrid is Cristina Lopes, who is a core Opensim developer, and therefore she cannot look at the viewer code!
To overcome this problem, Cristina Lopes is developing Grider. Technically, Grider is a proxy: a program that sits between the viewer and the internet, intercepts the viewer requests for inventory, and translates these requests into the safe hypergrid (or hypergrid 2) protocol. This can be written without looking at the viewer code, only examining its behaviour, which avoids the license conflicts. If you look at your Opensim.ini (for a sufficiently advanced revision), you’ll find a section named [Hypergrid] with a single line that says
safemode = false
and the following comment “Keep it false for now. Making it true requires the use of a special client in order to access inventory”. This “special client” is Grider.
How does it work, in practice?
Grider is an early prototype, a proof-of-concept more than a finished product, so that when it becomes widely available it will most probably be very different from its current incarnation. Anyway, at the moment of this writing, Grider starts by asking for the path to your favourite viewer (say, the Second Life viewer, or the Hippo viewer), stores it for subsequent runs, and then starts that viewer. For the time being, a hack has to be used here: in the “First Name” field, you have to write your first name, followed by a period, followed by your second name (that would be “Zonja.Capalini” in my case); in the “Second Name” field, you’ll write the name of the destination grid, for example “osgrid.org”, or “condensationland.com:9000” (the port defaults to 8002 if it is not specified); finally, you’ll write your password as usual in the password field.
Remember that we are still using our viewer, but we have started Grider, that silently sits between the viewer and the internet. Since we have specified our avatar name and the grid we are connecting to, Grider knows where to log in, and the address of our home grid. From now on, every time we interact with our inventory, Grider will intercept the viewer’s instructions and translate them into the safe hypergrid protocol (e.g., it will talk to our grid’s inventory service, not to the region we are in). Very simple. We won’t notice anything different, but we’ll be safe!
A glimpse at the future
Hypergrid 2 decouples inventory handling from the regions, so that you can be in one grid and interact with your inventory, located in another grid. This seems to be the trend of thought in the development of Opensim: decoupling user authentication (i.e., log in services) from inventory management, region and asset management, messaging, etc., as to make all the services as independent as possible.
So that we can imagine a future in which we log in to the metaverse using our Google account, teleport to a region hosted by Amazon Cloud Computing services, have our friends managed by AIM, and store our inventory in our own PC, for example. And we’ll still be able to communicate, meet, build together, share, etc., with our friend, who may be using the same providers as we are, or completely different ones. We’ll be able to get almost (or completely) free, light-use regions from some providers, or host them ourselves in our home computer, or even in our laptop, and meet with some friends there, or hold meetings with some few people; on the other hand, several companies will offer “premium” regions, capable of holding hundreds of avatars simultaneously. We’ll have our inventory at home, or hosted by a provider, or both things at the same time. Companies selling inventory hosting services won’t necessarily be the same companies that sell regions, or user authentication services. We’ll have several avatars, as we now have several mail addresses; we’ll use some avatars for some purposes, and other avatars for some other purposes, as we currently do with email addresses. And we’ll be able to buy two copies of a nice dress with one of our avies, hosted at A.com, and send one copy to another of our avies, hosted at B.com… The possibilities are mind-boggling now (although most probably all of this will look ridiculously simple in a few years :-)) — and Hypergrid 2 is a first step in this direction, towards this exciting future.