The History of Hypergrid Directories: A Single Point of Failure

This article is not intended to be overly critical of those various people who have generously put their time and effort into providing directories of Hypergrid locations, which must have been very considerable. The phrase “single point of failure” is a technical description and not a criticism or judgement. It is no small feat to put the server infrastructure and programming time into making this work and maintaining it over a period of time. As one who has operated servers, I understand that the personal circumstances of such volunteers change and resources such as time and finance for servers can be limited.

By way of comparison, a number of the original OpenSim developers have moved onto new projects, yet OpenSim is still releasing new versions. Why? Because there is not, in computing terms, a single point of failure that will cause things to fall over if those individuals or servers can no longer contribute. All of these directories depend on a single, privately maintained database even where the code itself has been open sourced, e.g. with code on GitHub developed by kidd piko (Zvi Ben Yaakov). This has recently had more downtime than ever before and appears to be unmaintained at present, for whatever reasons. [Ed.: in fact, I discover from kidd that the service needs a database sync but would then otherwise be functional, although the web site is not currently available.] Unfortunately, since Kidd put vast amounts of time into this development, all that fantastic effort now seems to be wasted [Ed.: but the situation is now under discussion since this was written.] because nobody else has put a system in place using this open source codebase. It was the most famous and widely used Hypergrid teleport network with its iconic Stargate styled gates.

Stargate out of order

Stargate out of order in Ocean Grid, January 2016. Will it work again? With existing or new code?

It was not the first, which was, defunct since about early 2013, if my records are correct. It seemed to survive a while but it was never clear how the database was being maintained or by whom. Most systems rely on the manual addition of regions either by an administrator or by grid owners, which may in some cases, e.g. Hyperica, be vetted by the grid owner.

Lately, iDreamsNet ceased to function, which was an easy to use system based on rezzing an item and then proceeding to a web page to register the region. Like Hyperica, it did not have an easy-to-use in-world directory, only one on the Web, but it was a great effort all the same.

Defunct iDreamsNet beacon

Defunct iDreamsNet beacon

The defunct iDreamsNet seems to have inspired the latest open source effort, OpenSimWorld, which is a brilliant combination of simple registration on the same principle as iDreamsNet with an easy-to-use in-world and out-of-world directory, like TheHyperGates except for the lack of the iconic Stargates – although there is nothing stopping you putting the HUD code in a Stargate and it will work in a similar way as its predecessor. (Maybe I will do this if TheHyperGates doesn’t come back on line soon. [Ed.: I have now used a modified HUD script in a telephone box because I wanted to keep the Stargate for its original purpose if at all possible.]) Being a HUD, the intention is that you wear it, which is another useful addition to the previous approach taken by TheHyperGates; however, you can just as easily rezz the script in an in-world object, or use the script both in a HUD and an in-world object too. You can only have one beacon script per region but the HUD script is not limited in the same way.

OpenSimWorld also shows you how many people are currently on line and orders the results accordingly: great for finding parties! I used the code from GitHub (which produces a prim like the one below, which I have framed in a sign with an added banner above) but you can also get a different design of beacon from the OpenSimWorld region on OSGrid. Finding people has hitherto been a major problem in OpenSim (and often in SL). It reported 30-40 people at any one time at LBSA Plaza on OSGrid (probably the most famous location in the OpenSim Hypergrid) over New Year 2016. Happy New Year, everybody!

OpenSimWorld directory on Ocean Grid

OpenSimWorld directory on Ocean Grid, Saturday 2 January 2016, 14:30 GMT

Clearly, these systems have been built on each other’s successes and evolved productively. The difficulty is that the database remains the single point of failure. If a single site goes down, the directory goes out of action entirely. I suggest that the next development would be to build a federated system with copies of the database that update each other, so if one breaks there can be a seamless (or at least simple) switchover to an alternative principle database, where perhaps the system records, e.g. in a notecard, the locations of active databases that are communicating with each other, i.e. that the administrator has registered with others, whether or not they are working, and then falls back to a different one and alerts the administrator if the main database stops working temporarily or permanently. One similar federated system in the system of PGP key servers, although that is only a general comparison of course.

It should be possible to re-use the open source code of either TheHyperGates or OpenSimWorld and add a federated database system underneath. It might even be possible to create a database standard that any and all systems could query with only relatively small changes to the code, making the user interface and underlying server code independent of each other, with a modular approach.

In the meantime, OpenSimWorld looks like a major success and I really hope it keeps going in the future.


The slow death of Viewer 1.x, the half-life of the hypergrid, and other stories

Despite the popularity of third-party viewers such as Phoenix (formerly Emerald) and the disastrous design and usability problems of Linden Viewer 2.0, it has now become clear that Viewer 1.x is dying a slow death. The final release of the Phoenix viewer is out, to be replaced by a new Firestorm viewer based on the 2.0 codebase, and there are similar plans for Imprudence to be replaced by the new Kokua viewer (whose name, I’m afraid, does not strike me as nearly as memorable – what’s wrong with Phoenix 2.0 and Imprudence 2.0 for names, rather than changing them just when they start to get well-known?)

This is, of course, a demonstration that the world of OpenSim grids, so dependent on the Linden codebase, is still very much semi-detached from development in SL, and interoperability will always remain a core issue.

One reason for this is mesh, coming soon (but we’re still not sure when) to a simulator near you. Look out, OpenSim and ModRex! Despite the latter’s support for mesh being far older than the Linden effort, ported back from RealXtend‘s version of the OpenSim codebase to a region module for OpenSim, it has never caught on. Although OpenSim developers seem to be working on mesh, it’s no longer clear if ModRex is the main plank of this effort. It still only works in standalone mode, not in grid mode. The pace of development on ModRex seems still to be incredibly slow, after an initial burst of activity, and it’s blog and web presence remains embryonic and dated.

The 1.x codebase can support some newer backported features such as Display Names (which is not likely to be complex code) but it will be increasingly difficult, and most likely impossible, to continue developing viewers that work for both OpenSim and SL without embracing the viewer 2.0 codebase. Incidentally, Display Names will not work on OpenSim, but apparently will on Aurora based-grids (see below). Hopefully, however, the terrible viewer  design will be completely ignored. Even the developer of Kirsten’s viewer, which rather slavishly avoids any affront to Linden Lab by providing direct support for OpenSim (which is a simple matter of using the open source grid manager code from the Hippo viewer), has been critical of the Viewer 2.0 design. I should say, in Kirsten’s defence, that it is not completely impossible to use the present version of the viewer with OpenSim.

Meanwhile, new forks of the OpenSim server codebase are appearing, notably Aurora, which provides a great deal of core functionality that users have been crying out for. The new Kokua Viewer (a separate project loosely associated with Aurora, previously known as Imprudence) will support some of these extra features. At present, things like profiles, groups, search and web interfaces have to be hacked together once per upgrade, and database changes leave all of these side projects struggling to keep up with the OpenSim codebase.

OpenSim developers, after their huge success with Hypergrid, have managed to undo their own work by fracturing the community into no less than three mutually incompatible and often unreliable versions of what is the most fundamental part of the open metaverse. At present, Hypergrid is barely working at all, and it is a major victory to teleport off one’s own servers. Yesterday I finally managed to reach OSGrid (though it’s misconfigured locally, so that one cannot leave) using a test grid running Aurora, although I cannot do so with any revision of OpenSim 0.7.1-dev on which it is based. Admittedly the latter is development code, but many grids are already running it, including OSGrid. People were astonished to see someone arrive from the outside: one said it had been a year since they had known it to be working! Obviously, some of the unreliability is down to local server configurations, which is an operational problem. But why keep breaking Hypergrid with every new release? Why does it have to be so hard? This is no way to help grow the open source metaverse.

It seems that the OpenSim developers do not seem to see the hypergrid as a priority even though it is what makes people compare OpenSim grids to the Web and its rich competitor SL to the once-mighty AOL. At present, documentation and communication about OpenSim remain amateur and patchy. Of course, the developers make the blinkered ideological claim that they are NOT a competitor to SL, but such claims are often made by those who are manifestly failing to capitalise on their obvious strategic advantages. However talented the OpenSim developers are, they are terrible salesmen. And they are convincing nobody. Their user base certainly is competing with SL, even if they personally, as developers, are not. Remember, the user is queen – or even king!

Get it together again! All this fine work needs a bit more coordination, no?