A bit over a month ago, Andabata Mandelbrot, addressing a Portuguese-speaking audience, launched an interesting challenge: let national OpenSim grid operators join forces together into a single OpenSim grid. Simple as that.
It shouldn’t come as a surprise for OpenSim users and operators. After all, isn’t “joining forces” what OpenSim is good at? I mean the ability to HyperGrid across grids, which works more and more flawlessly as time goes by and newer versions are released. These days, it’s so easy to get some clothes on one grid, then move to another, buy some shoes, return to your own grid… and suddenly you forgot where all the things in your inventory have come from: they might have come from dozens of different grids, and you’ll be able to mix and match them at will (assuming you have permissions for that), and not worry about anything else. Things like The HyperGates keep all the possible links between individual grids together.
Sounds fantastic! But there is a catch. Actually, there are several.
I want to be a big fish in a small pond!
For years, Second Life residents have complained how Linden Lab has mistreated them and how they managed their virtual world so badly. And then came OpenSimulator and LL’s feeble attempts of allowing teleporting to work across their own grid and other OpenSimulator — culminating in the standardised VWRAP IETF protocol, which, once defined, LL never bothered to implement it. OpenSim just ignored VWRAP and implemented Hypergrid teleporting instead — a much simpler (but less secure) way to accomplish pretty much the same thing.
Hypergrid teleporting comes standard with OpenSim. When it was released, it was seen as a blessing — now all of the myriad independent OpenSim grids would be interconnected and you would be able to register a user once, and travel across all OpenSim grids in existence. With more and more users leaving SL and joining OpenSim, soon — it was predicted — SL would be emptied out, remaining as the only unconnected grid in existence.
This was just wishful thinking, of course.
Soon commercial OpenSim grids were launched as well. For a much smaller monthly fee than what LL charged, they gave disgruntled ex-SL residents the opportunity to have their own regions, in a virtual world that was “almost” like the one they just left. “Almost” — because, well, there was not many content available, and furthermore, everybody was scattered across the thousands of independent grids. Thanks to Hypergrid teleporting, however, this allowed you to invite your friends to visit you on a commercial OpenSim grid… or not?
People quickly found out that the answer was “no”. The more successful commercial grids were all disconnected from the Hypergrid. In fact, as a commercial grid became more and more successful, they copied more and more Linden Lab’s attitude. Not only Hypergrid teleporting was out of the question, but also virtual money, instead of using a intergrid-wide system, was proprietary. And prices started to rise, too — soon grid operators found out that maintaining thousands of regions has a huge maintenance cost, and this had to be charged back to the users. So slowly, over the years, these grids would look more and more like Linden Lab’s own Second Life Grid: closed to the rest of the world, independent, with their own strict policies, and with their own virtual economy — the difference being that they looked like SL in 2004.
I’ve seen many of those commercial grids pop in existence, enjoy rapid growth, and then starting to “act like LL” over and over again. In fact, a few non-profit projects who had switched from SL to the commercial OpenSim grids complained about their attitude as well, and left… to create their own OpenSim grids in-house, completely disconnected from the world.
Thanks to the backup/restore tools now available on all Third-Party Viewers, transferring your own content from SL to OpenSim grids is now relatively easy to do (even if it takes a lot of time if you have huge inventories). Content creators soon started opening their shops on the OpenSim grids with a working economy. But, again, content creators hit the same problem. They could have their content on display on the largest commercial OpenSim grids, but would have to create logins for each and buy land in each — because they weren’t interconnected. Or they could rely on the thousands of Hypergrid-enabled grids with an intergrid commerce module, but which had far less users. It’s much harder to account for OpenSim usage outside the commercial grids (and the largest not-for-profit ones), since there are so many of them, but the short story is that the market size of OpenSim is tiny compared to Second Life (see these two articles from Maria Korolov). That doesn’t mean that there is no business there to be made: rather the contrary, there is also much less competition, so smaller content creators, finding no available niche on Second Life, might enjoy moderate success on OpenSim, where the competition is tiny. The problem is how to set up a shop to sell on all those disconnected grids. Hypergrid Business tracks the data for the 40 top OpenSim grids, few of which have more than 500 regions — meaning that content creators might have to open shops on most of them, to reach an active population of perhaps 2% of what Second Life has to offer. Nevertheless, OpenSim growth continues — mostly on very small grids — and even though users are lacking, the number of regions on OpenSim is impressive: around 20k compared to SL’s 30k. The difference, of course, is that all of SL’s 30k regions are accessible with the same avatar, while most of those 20k regions are spread across several grids (hundreds!) requiring different avatars. It’s a nightmare!
The sudden increase in tiny OpenSim grids (some of which allow HyperGrid teleporting) tends to support the trend for which I only have anedoctal evidence: as projects move from Second Life to a commercial OpenSim grid, they soon hit the limitations of those grids — lack of users, lack of content, lack of connectivity with other grids — and move towards “their own grid”. This is particularly true in the academic area, where educators initially prefer to place their projects on commercial grids, where they can get good technical support and forget about the hassle of setting up and maintaining the servers, but then, once they hit the limits of those grids, they prefer to push their content in-house to their own servers, acquiring somehow the required technical skills to run them (it’s easier on larger campuses, where colleages from the IT departments might be able to lend a hand).
So clearly if this is the way that OpenSim is going to grow in the future, it doesn’t look as a good alternative. It looks like the online world of the 1980s: lots of BBSes, but you had to login to each individually. Hypergrid teleporting is the equivalent of FidoNet in the 1980s — a way to get messages across different BBSes — but, like in the 1980s, not everybody is using it, and the larger the grid, the less likely it’s going to allow Hypergrid.
One login, many grids?
I personally expected Linden Lab to act as a “central hub” for all these tiny grids. The idea was that LL would act as a registration and validation centre, store most content, but charge interconnection fees with the independent OpenSim operators. This would allow growth to happen outside Second Life but keep Linden Lab as a very significant player in the field, dictating the rules, and making money from interconnection fees. In fact, that’s precisely the model adopted by the Internet’s Tier 1 carriers which sustained the commercial Internet from 1990 onwards, and it was thanks to that model that we have the Internet of today. But Linden Lab has shown no interest to replicate a model that we know that works well (after all, after 22 years, the Internet is still here, still growing, and still making Tier 1 carriers profitable). Instead, they prefer to leverage on their monopoly and patiently wait. In fact, their strategy doesn’t seem to be that far-fetched. Again, I can offer only anedoctal evidence, but it seems to happen more frequently: disgruntled residents leave SL and launch their own grid from home, because it’s so easy to do. Then they quickly figure out that they will receive no visitors that way, so they join an existing grid. Then a commercial grid will start some heavy advertising, and they move to that grid instead. Soon another commercial grid lures them with better technology and more users, and they start creating accounts everywhere. Finally, tired of the lack of interconnection, they fall back to their own grid (possibly hosted on an academic campus). But after all that constant switching, they get tired of the lack of interest… and return to Second Life, with a much smaller presence than initially, but at least a presence that has some chance of attracting visitors. While the number of people going “full circle” might not be huge, I get more and more reports of many similar cases.
So if LL is unwilling to act as a “central hub” of authentication… who will step in?
Here is where Andabata Mandelbrot’s idea comes to the rescue, but it requires a bit of explanation. Andabata was addressing mostly the academic population of Portugal who is actively using Second Life and, more and more, OpenSimulator for their projects. At first, the easiest way to get the ball rolling was simply to agree to Hypergrid-enable all the grids hosted on each university’s campus, and somehow have a website to list the active grids and their URIs.
But there is a catch. While each university grid is able to validate their own users, and, since they create the accounts, they know that these users are valid — they are either students, teachers, or researchers at the campus — the problem is when this grid is open to others. How can you know that an incoming Hypergrid user is actually a valid user? For universities, this often means knowing that only students, teachers, and researchers are supposed to be Hypergrid-jumping across the university grids, and the general public is left outwards (or restricted to certain public areas). It’s easy to do that with your own users, but how do you “control” users coming from foreign grids outside the campus?
Eduroam to the rescue. This problem is hardly new: it also exists when students and teachers wish to access network resources outside their own campus. With academics always on the move, teaching at different places or attending conferences around the world, the problem was how to give them easy access to a specific campus network without requiring them to remember millions of logins and passwords for each campus (and requiring to set up a user in advance). Eduroam provides a federated approach for giving network access (wi-fi or fixed) to uncountable researchers and students all over the world. The principle is similar to the mobile advertising we see about roaming using mobile phones, or, if you prefer, to the DNS system. Each university campus establishes its own wi-fi network with an Institutional Identity Server, and autheticates local users. If a user comes from another campus, then the request is first forwarded to a Federation (national) Server, which will redirect the authentication request to the Institutional Server on the external campus. Identity Servers are known by the Federation Server, but if the request comes from another country, then a Confederation (supernational) Server is contacted instead, and the request will trickle down to the other country’s national server, and finally to the campus’ Institutional Server. This takes far less time than it seems (the tree is just two levels deep).
Once authenticated, a user from any external campus can get wi-fi (or fixed network) access just like anyone else on that campus. It works rather seamlessly. Authentication is provided by RADIUS, a very popular and highly successful authentication method employed by most Internet Service Providers, and well-suited for roaming models. Eduroam is widespread in Europe but also available in a hundred or so institutions in the US and Canada, as well as in Australia, China and Japan.
The beauty of it is that authentication can be tied to an institution’s email address. Since the institution creates the email address for the student, teacher, or researcher, they can ensure that valid documentation has been provided for that person, and the Institutional Server acts as a guarantee that only valid members of that institution are granted access — either at their own campus, or world-wide on any Eduroam-connected campus. There is no leeway for forgeries or fake accounts — all users are always properly identified. If someone neglects their password, and it gets used by a hacker, then you know who is responsible! The worst that can happen is that this account gets black-balled until the institution behind that account investigates what happened; if they refuse to do so, they get black-balled in turn, and so forth. The net result is a world-wide wi-fi roaming network where the identity of each user is known, but each can freely use resources available elsewhere using a single account.
Of course, Eduroam is not only for wi-fi. You can build gateways to it allowing external campus users to access your campus’ resources as well. A silly example would be doing table reservations at the university cafeteria via the Web. Obviously, this would require a student or teacher to log in with their Eduroam account, and it would be pointless allowing external users to it. But a visiting teacher would definitely be interested in making reservations as well: so the website would simply accept their Eduroam account, and allow them to make reservations as long as they were being “tracked” in that campus. Once they move back to their “home” campus, the website would be not accessible any longer. While this example is rather stupid, there are actually a lot of similar services that are based on Eduroam authentication, allowing visiting Eduroam users to get full access to online services so long as they’re connected to that campus, just like the regular users.
What Andabata Mandelbrot was hinting at is that it would be nice to get the national Federation Server to accept Eduroam accounts as tokens to log in to OpenSimulator. This would require some code changes on the authentication modules, but the task is not an extraordinarily difficult one. SignpostMarv has been working on authentication on OpenSim (with the help of another developer he submitted a patch to OpenSim to get the weblogin API working, then put a login page on the login screen that would authenticate against the university’s login system [LDAP/ActiveDirectory- the same thing used for logging onto the university network machines] — if authentication was successful, he would check if the user existed in the OpenSim database; if it didn’t, the system would fire off an account creation via Diva’s wifi module [diva’s wifi browser interface wasn’t used, just the module], which happened all transparently to the user — at the end of all this you’d get a HTTP redirect using a secondlife URI for performing web login and the viewer would then login the user), and I’m sure that doing RADIUS authentication is not too hard to do. What requires mostly is a policy change at the national Federation Server which accepts authentication requests from OpenSim servers. With that and a bit of HyperGrid gluing, you could offer — at least for participating OpenSim grids in Portuguese universities — “avatar roaming services”, where your fully authenticated avatar could Hypergrid-jump from a university grid to a different university grid in complete safety — you would always know that any user on your grid would have been registered with an Eduroam server, and that the institution it comes from has all authentication data in storage. No more anonymous visitors to university grids!
Of course, the concept, once deployed and tested, could be expanded to any other Eduroam-connected university. All it would require is a similar policy change. Within a few years, and given the vast number of entities already connected to Eduroam, this could be the solid foundation for a future world-wide academic Hypergrid where all users are properly identified.
What about the rest of the world?
Eduroam only works for academia. Central to its philosophy is the idea that each school, college, university, or research centre has the technical means to implement the technology and the required administrative overhead to validate users and set them up with an account; Eduroam is based on mutual institutional trust, which is usually prevalent among academic institutions.
Outside the academic world, things are more tricky. It’s harder to get companies to agree on how they share data of their users. Either you push the burden upon government — another can of worms to be opened — or you have to create very strict protocols to ensure authentication integrity and mutual acceptance of credentials. In fact, that was the route taken by the VWRAP IETF, and which seemed to have stopped: the difficulties are similar to what happens with Certificate Authorities, for example. We are all aware of the nightmares of “rogue CAs” which “certify” users without any requirements whatsoever. It’s true that certificates can be revoked, but usually only after some serious harm has been done (VWRAP, for instance, also allows certificates to be revoked in case something goes wrong).
The current problem is who do you trust. When looking at the current OpenSim grid operators, it’s not really clear how they would act in case one of their users started misbehaving on foreign grids; that’s another good reason for disallowing Hypergrid teleport. Also, competition among commercial OpenSim operators is rather intense — each wants to become the next Linden Lab — and why should they trust each other? In fact, there is only one operator that might be viewed with universal trust, and that’s Linden Lab — the only one absolutely not interested in participating in such an endeavour.
But they might be “forced” to it. If a world-wide, Eduroam-based academic Hypergrid emerges, this can quickly become the standard way for users to join OpenSim. It even means that some exising OpenSim grids — like ScienceSim — might immediately join the Eduroam federation, as they’re already located on a university campus. Other OpenSim grids, even if more commercial, might get their main servers deployed inside academic institutions to benefit from Eduroam users; others still might try to establish relationships with academia just to be able to get new visitors that way. And some universities might even launch their own commercial OpenSim operator because they will have the advantage of being able to address a much larger community of users than “external”, non-academic OpenSim grid operators. If this gets some traction, this Eduroam-Hypergrid could start to become a serious “threat” to Linden Lab, pushing them to act as a central authentication hub as well. Or, since LL is so security-conscious, they might pick up their VWRAP development where they have left it in 2010, and implement it again — but only allow connections from Eduroam-based grids. Why should they do that? Well, under M Linden, LL pretty much excluded large-scale academic projects from Second Life, thanks to the end of the discounts and all sorts of special relationships they had forged with universities. So universities and their users are not LL’s market any more. On the other hand, Eduroam authentication is very strict and powerful, and, as such, quite safe — meaning that LL would not need to “fear” any potential threats coming from academic institutions, since all their users would be at least as well identified as LL’s own. Probably even better identified: LL’s identification is voluntary, while on Eduroam it takes a lot of administrative procedures to get you an account, namely, not only providing full ID and address, but also proof of being a student/teacher/researcher at a certain university. You cannot get accounts in any other way. This is far more than what LL requests from an user to establish a valid SL account.
Presently, all this is wishful thinking. There is no “national OpenSim grid” yet, either in Portugal or elsewhere. While theoretically Eduroam authentication could be deployed on a modified OpenSim server, to the best of my knowledge, this hasn’t been implemented yet. And even if it were, on a “test” Eduroam setup, it will require a lot of lobbying to get Portugal’s Federation Server to accept Eduroam authentication tokens for the OpenSim login procedure. And from that to a world-wide acceptance is a huge step. Nevertheless, the idea is sound.
So if you’re an active OpenSim developer at a Eduroam-connected university, you know what you have to do next 🙂 Start changing the OpenSim authentication code; convince your university to allow Eduroam authentication tokens to be accepted for OpenSim authentication; once that’s in place, get your university to talk to your country’s Federation Server to do the same. This might take some time, but it looks like the best way so far to give a lot of users the ability to safely “roam” across OpenSim grids, and start creating a real, federated Metaverse out of all those isolated grids out there.
And if you’re a commercial OpenSim grid operator, completely closed down to the outside world, think twice about your current policy. If you set up your own grid because you disagreed with LL’s policies, why are you emulating them? It’s pointless to lure users out of Second Life “gilded cage” just to place them inside a brand new gilded cage instead…
Update: SignpostMarv provided me with a thorough description of what his authentication ‘hack’ actually did. I’ve updated this article to reflect the conversation we had via IM, at his request.
