What is the Hypergrid?

The Hypergrid is a neural-interactive simulation, a computer generated dreamworld built to keep you under control.  It is the world that has been pulled over your eyes, to blind you from the truth.

The Hypergrid has you…

Or to put it another way :), the Hypergrid is a new core OpenSim network architecture which joins the existing standalone and grid architectures.  I’ve mentioned it before in various This Week In OpenSim Dev posts and there is a good OpenSim wiki page on it as well as a blog post by Rock.  However, I thought that I would give my own summary of it.  This is an extension of my original technical analysis of Diva’s initial Hypergrid patch as posted to the Opensim-dev mailing list.

No really, what is the Hypergrid?

Essentially, a Hypergrid is a confederation of OpenSim systems that have enabled the Hypergrid facility. Each user has a home grid or standalone where their user profile, avatar appearance and inventory is stored.  Possible homes range from a standalone on the user’s own machine up to a large OpenSim grid hosted by a third party.  Users can travel from their home to a different grid or standalone via a hyperlink (set up via some funky map and region handle manipulation).  When they arrive at the foreign grid, they carry with them the url of their home asset and inventory services. This mean that in the Hypergrid

1. If a user rezzes an object from their inventory, the assets for that object are fetched from the home asset service and permanently inserted into the foreign asset service. So when that user goes away or logs off, the assets are still available to be seen by everybody else.
2. If a user copies/takes an object from a foreign grid, then the relevant inventory and asset data gets sent to their home inventory and asset services.

In other words, the necessary information to rez inventory and avatar appearance is transparently passed between linked grids as necessary.  This allows a user to hop around different Hypergrid enabled grids and standalones as if they were travelling around a single system.

Hypergrid pros

Thus, on a conceptual level, some of the pros of the Hypergrid are:

• It effectively distributes asset and inventory load over multiple services on multiple grids. This is a really good alternative to scaling up a central service to internet scale.
• It allows grids to seamlessly link to others yet retain control over their own services.

Hypergrid cons

And the cons:

• In the Hypergrid, assets, including scripts, are liberally spread around grids.  If someone travels to your Hypergrid enabled OpenSim and acquires an object, then they get a copy of all those assets in their home services (which may be situated on their own machine).
• Regions must be manually linked and appear in a grid’s map. One can’t just enter an address in a url bar to go to another grid, the grid owner must set up the link. As far as I can see this is a limitation of what we have to work with in the Linden Labs Second Life client. There may be some arguments for restriction (you don’t want someone coming to your pg grid from an adult grid and depositing god knows what).
• Home services need to be exposed to foreign linked grids. So malicious grids could possibly fetch and put things they shouldn’t. There are already some proposals for dealing with this. However, this may also be another good argument for controlling who can link to you, for now.

Some current issues

I think there are some issues with the current Hypergrid code.  These aren’t fundamental architectural concerns.

1. Assets associated with worn attachments and appearance are not uploaded to a foreign grid from the home grid on teleport in. For other users without cache copies, such avatars will always appear gray and I don’t think that any attachments would appear.   This is fixable.
2. Prim inventory inspection does not go deep enough. As far as I can see, in the ‘asset mapper’ you look for contained textures when rezzing an item, but not any other contained assets (including contained objects, clothing, notecards, scripts, etc.). This will result in an incomplete rez. However, this is fixable. Indeed, I’ve already written all the code required to do this for OpenSim Archive support (OARs).

Summary

In my opinion, the Hypergrid is a very promising architectural direction for OpenSim. It moves from a system of centralized services to one a user can seamlessly navigate between many different grids whilst sourcing their appearance and inventory from their own home services.  This decentralized is a commonly hoped for change that I’ve written about previously, as have others.  Though there are quite a few problems to resolve yet (such as the short term technical ones that I’ve talked about, as well as more fundamental questions such as that of grid service security), I think that the Hypergrid has a lot of potential.

If you want to set up your own Hypergrid enabled OpenSim, there are instructions on the OpenSim wiki, as well as a list of Hypergrid enabled OpenSim instances.  You will need the owner’s permission to establish a link.  I believe that Wright Plaza on OSGrid is also Hypergrid enabled, though it isn’t yet listed.

Many thanks must go towards Diva (Christa Lopes) who did all the hard work in formulating the architecture and writing the code such that a patch could be accepted into OpenSim.  The OpenSim community (both developers and users) also deserves a great deal of thanks, since their hard work and enthusiasm was absolutely instrumental in proving that the concept was viable.

(The image used at the top of this post is licensed under Attribution-Share Alike 2.5 from the OpenSim wiki)