Towards HG 2.0

I usually don’t write about the future, I prefer to write about things that are already done and working. But I’m going to make an exception, because people are starting to ask about configurations of the Hypergrid that pertain to the next level; we’re almost there, but not yet. I am going to give an overview of what’s in the works right now that will result in the next big bump in the HG number: the big two-point-oh.

As usual, some context first.

The very first version of the Hypergrid, HG 1.0, was done back at the end of 2008, and continued through 2009 and 2010. That first version was just an exercise in feasibility and in interacting with the opaque, black box viewer. Could I trick the viewer to think that it was still on the same grid while in reality sending the user to a different grid? — that was the humble goal of HG 1.0. HG 1.0 was not concerned with security at all, as the main goal was to figure out how to use the viewer in ways for which it had not be designed. Once I mastered the signaling of agent teleports, it was time to take the HG to next level: more security all around.

The next version was HG 1.5. The conceptual work for it started in early 2009, although the actual coding only happened much later. This was because in order to implement the Hypergrid as a collection of additional, optional services that don’t interfere with the simplest configuration, OpenSimulator itself had to be considerably refactored. That took a long time. HG1.5 came with OpenSim 0.7 in July of 2010. It featured identity security as well as a semi-secure (or semi-insecure, depending on whether you are an optimism or a pessimist) Hypergrid inventory. It also had all the right architecture for enabling HG Instant Message and Friends. That’s where we are right now.

So let me explain what we’re working on for HG 2.0


Hypergrid Inventory is going to be 100% secure and the Suitcase will finally be usable without external Web apps. This required some heavy hacking in order to understand how to further trick the viewer into submission (i.e. use it beyond its specs), but we did it. Here is what will happen. When a user goes out, her entire home inventory tree will be removed from the viewer and replaced with the Suitcase folder tree only. That’s the only portion of the user’s inventory that will be exposed to the outside and to the user while the user is hypergriding. That way, the user’s home inventory will be out of reach and completely protected. Once the user returns to the home grid, the Suitcase wannabe-root folder is replaced by the user’s real inventory tree again.

Depending on configuration, the Suitcase folder may or may not be available to the user when she is in her home grid. When it is available, it will be a regular folder under “My Inventory”; the user can then move stuff from/to the Suitcase to/from other folders using the viewer.  But some grids may not want their users to bring in stuff from the outside, they want to continue to segregate content, so availability of the Suitcase folder in the home grid will be configurable.


The appearance that a traveling user has may or may not be the same as the appearance that she had when she left the home grid. Again, this will be configurable. But the idea here is that  some grids don’t want to allow the export of appearance assets at all, so they may provide generic appearances to their traveling users, and dress them with their appearances when they come back. Other grids may not care about this, and appearance will be preserved.

User Access Control

There will be a means to specify several policies of access control: who can go out and where, who can come in and from where. These policies are based on several pieces of information about the users themselves and about their grids of origin.

So for example, it will be possible to specify that only users of a certain level can Hypergrid out, while others under that level can’t (a requirement often heard in educational settings). It will also be possible to specify a limited set of grids that the users can visit; or a set of grids that the users cannot visit.

On the receiving end, it will be possible to specify only a limited set of grids whose users are allowed in; or a set of grids whose users are not allowed in; or no foreigners allowed in at all.

Assets Access Control

There will be a means to specify whether the grid allows asset exports to other grids, and which grids, as a whole. HG 2.0 will not support the specification of fine-grained asset exports, i.e. I can’t say that this particular set of assets can go out, while that other can’t. This will require a means for people to be able to express that, and we don’t have that means yet.

What this amounts to is that the Hypergrid will be able to support different policies that better reflect different levels of comfort that people have regarding opening up their worlds. Grids that deal with protected content will be able to continue to protect that content while allowing their users to visit other grids, and even collect items there, and allowing foreign users to come in and mingle — without any asset ever being exported or imported from/into their main storage. Grids that deal with kids will be able to block them from hypergriding while allowing certain privileged staff to go out and get content and knowledge from other grids. Secretive grids will be able to prevent foreign visitors while allowing their users to go out. Grids can have only one or two regions available to foreigners, while the rest is off-limits. Communities can make up small networks of worlds that allow Hypergrid exchanges only among themselves. Etc.

I hope this clarifies where we’re going with the Hypergrid!

I know that the first question that everyone will ask is: when? My guess: sometime this summer, hopefully early.


5 replies on “Towards HG 2.0”

  1. Fleep Tuque says:

    Thanks for the overview, Diva, it’s super helpful to have a general roadmap of where you expect HG to go – and as always a million thanks for all your hard work to make it even possible! We non-coder types are eternally grateful! :)

  2. Gaga says:

    Thank you the insight into the plan for HG2, Diva. I do wonder though how the work Kitely is doing to enable hypergrid with their own security measures (respecting copy/transfer perms) will affect HG2?

    Also, presently, there is some concern that Inventory’s have been corrupted and content lost by HG travel so the advice has been not to use your main avatar. I assume you are aware of this problem and it will be fully addressed in HG2. Well, I hope it will anyway.

    Thank you anyway for the work you have done to make a connected and free Metaverse possible. It is greatly appreciated.


  3. Diva Canto says:

    Grids can apply whatever policies they want to their own content. If Kitely wants to let copy+transfer objects out, and only those, that’s fine and reasonable. Each grid can have their own policy, and that doesn’t conflict with anything else. There is no mandatory policy, by design, it’s a decentralized system.

    Inventory is never lost by HG travel, even now, unless the grids are misconfigured. The HG inventory server does not delete anything. The worst that can happen now is inventory items changing folders if ppl visit a grid with malicious server code.

    In any case, inventory in HG1.5 is still exposed to those kinds of risks; that’s what HG2.0 will eliminate. The new HG inventory service, together with a better manipulation of inventory in the viewer, will be bullet-proof. No items besides those in the suitcase can ever be accessed while hypergriding.

  4. Pathfinder says:

    Outstanding, Diva. Thank you again for all your work on this.

    And thanks for the historical background on previous versions of the Hypergrid. I learn something new every day!

  5. John Silver says:

    I wonder … at the moment during the startup of OpenSim it is possible to connect other grids by hypertext links by using method 2 via include / exclude lists. See also:

    I this file I only want to include the hypergrids that are aloud to connect to my own grid. All the other grids are excluded and blocked if they are not on this list.

    The list can easily maintained by an administrator following the discribed format. It would be nice if this option is made available. The mechanisme could be activate in the Robust.HG.ini file and can be done by simple include check when on the list. For closed grids within companies or educational institutes this can be a good expention of OpenSim and maybe easy to implement. Or am I wrong?

    with regards,

Comments are closed.