OpenSimulator - User contributions [en]

Grid List/Cyberlandia

2010-02-26T12:02:50Z

Carlosroundel:

__NOTOC__
{{Template:Quicklinks}}
<br />

<table border="1" cellpadding="5" cellspacing="0">
<tr>
<td>Name:</td><td>Cyberlandia<br>Italian Opensim Grid</td>
</tr>
<tr>
<td>Website:</td><td>http://www.cyberlandia.net (1)</td>
</tr>
<tr>
<td>Login URI:</td><td>-loginuri http://hypergrid.cyberlandia.net:8002</td>
</tr>
<tr>
<td>Wiki/Forum:</td><td>[http://www.cyberlandia.net/ Home]<br>[http://hypergrid.cyberlandia.net/redux/index.php?page=create&btn=7 Register an Avatar]</td>
</tr>
<tr>
<td>Approx # Regions</td><td>160</td>
</tr>
<tr>
<td>Approx # Users</td><td>+/- 600</td>
</tr>
<tr>
<td>Logins/day</td><td>~ 15</td>
</tr>
</table>

(1) The first Italian Grid. add your avatar or join your island(s) to the grid<br>
La Prima Grid Opensim collaborativa italiana, registra il tuo avatar o Aggiungi gratuitamente la Tua sim, grid totalmente creata e autogesti dagli utenti, totalmente abilitata hypergrid

Public Hypergrid Nodes

2010-02-06T19:50:45Z

Carlosroundel: /* Hypergrid-enabled sims */

{{Template:Quicklinks}}
<br />

__TOC__

== Hypergrid-enabled sims ==

The following is a list of hypergrid-ready nodes that you can use for testing your installation and for linking your world. Please add your public node here if you wish to help build a web of opensims!

For the time being, and until the security concerns are addressed, we advise you to be careful about who you link to.

<br>

{| border="1" cellspacing="0" cellpadding="5" align="center"
|-
! [[Hypergrid|link-region server and port]]
! Organization
! Description
! Grid Location
|-
| '''osl2.nac.uci.edu:9006'''
| University of California, Irvine
| The "UCI Welcome" region connected to OSGrid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine. You can link to it as a way to link to OSGrid.
| OSGrid is centered at 10,000, 10,000
|-
| '''osl3.nac.uci.edu:9000'''
| University of California, Irvine
| The "UC Irvine" region connected to OSGrid, neighboring Wright Plaza. You can link to it as a way to link to OSGrid.
| OSGrid is centered at 10,000, 10,000
|-
| '''ucigrid02.nacs.uci.edu:9000'''
| University of California, Irvine
| The UCI Grid
| UCIGrid is centered at 8,888, 8,888
|-
| '''ucigrid04.nacs.uci.edu:9003'''
| University of California, Irvine
| The UCI Grid, region "Gateway 3000". Link your lower-1,000's grid to this node in order to bridge to grids in the 10,000's.
| This node is positioned at 3,000, 3,000
|-
| '''ucigrid04.nacs.uci.edu:9007'''
| University of California, Irvine
| The UCI Grid, region "Gateway 7000". Link your 10,000's grid to this node in order to bridge to grids in the lower-1,000's.
| This node is positioned at 7,000, 7,000.
|-
| '''www.meanduland.com:9124'''
| Grid Meanduland
| [http://www.menduland.com], Meanduland - by Ayana and Frank Northmead. Residential grid and playground for couples. Quite, peaceful and fun. Regular live music concerts and coming soon - rpg's, adventure simulations, private beaches, sail boat racing, dune buggy racing, and much much more. All welcome, no membership or landownership requirements, you just need desire to have fun and be a good neighbor. Regions available at cost during Alpha and Beta development of OpenSim.
| Centered at 8000, 8000
|-
| '''hypergrid.cyberlandia.net:9100'''
| Cyberlandia
| The "Cyberlandia Gw" region. http://www.cyberlandia.net Metaverso italiano 3D, more to 250 region and 1000 users. You can link to it as a way to link to Cyberlandia.
| Cyberlandia is centered at ???
|-
| '''venezia.cyberlandia.net:9100'''
| Cyberlandia
| The "Osgrid Gw" region connected to Cyberlandia grid http://www.cyberlandia.net. Search on map "Cyberlandia grid" You can link to it as a way to link to OSGrid.
| OSGrid is centered at 10,000, 10,000
|-
| '''regions.ralf-haifisch.biz:9000:Sharkland Tropical 1'''
| Ralf Haifisch on osgrid
| The "Sharkland Tropical" region connected to OSGrid. German welcome aerea, Freebie aerea, region rental, pretty tropical regions
| Centered at 10000,10000
<br>

|-
| '''joomla-italia.net:9000'''
| Social Network Italia
| The "SNI City" region connected to SNI (Social Network Italia) grid http://www.opensim-italia.net. This grid is connected with Osgrid,Collateral World,Francogrid and Darwin
| Centered at ???
|-
| '''collateral.opensim-italia.net:9000'''
| Part of Social Network Italia
| Collateral World
| Centered at ???
|-
| '''88.191.79.199:9050'''
| Francogrid
| Francogrid node, connected to "City", behind the welcome land of Francogrid "Orion"
| Centered at 1000 1000
|-
| '''94.23.8.158:9300'''
| Le Monde de Darwin
| The Lost World of Darwin http://www.LeMondedeDarwin.com. [[Image:Hypergrid.jpg|200px]]
| Centered at 1000 1000
|-
| '''sg.k-grid.com:9000'''
| K-Grid
| The Kool grid for the Kool KidZ . Feel free to visit us. The main Gateway is located at 3700,3700 so take that in account before any HyperJump. Adress updated 02/07/09
| This node is located at 3700,3700
|-
| '''metropolis.hypergrid.org:9000'''
| METROPOLIS-Grid
| The Region "Center-World" connected to the METROPOLIS-Grid http://metropolis.hypergrid.org . German Grid with a lot of free Content and free SIM-hosting. Connected via HG to the most of the Grids listed here
| Centered at 7000,7000
|-
| '''ascent.bluewallgroup.com:9910'''
| BlueWall Information Technologies
| This region is in a good proximity @ (6000,6000) for intermediate jumps to OSGrid from grids in the (2000,2000) range, or any region within 4096 units. [[Image:Hypernaut 001.png|thumb|none|150px|Get your Hypernaut here :)]]
| Centered at 6000,6000
|-
| '''http://myopengrid.com:9005/'''
| '''MyOpenGrid'''
| Myopengrid is connected to osl2.nac.uci.edu "Osgrid Gateway" and 88.191.79.199 9050 "Franco Grid"
| Centered at 7000,7000
|-
| '''cuonsim1.de:9300'''
| Cuon-Grid
| Cuon-Grid is a little grid and has some Main Sims with linux themes, server are in Germany. To login in to the grid use this http://sim-linuxmain.org:8081/CuonGrid/index.html. There are free sims for testing.
| Centered at 10,000, 10,000
|-
| '''metaversesims.net:9000'''
| Metaverse Sims
| 6-region standalone hypergrid linked to several other grids.
| Centered at 9000, 9000
<br>

|-
| '''grid4us.net:9020'''
| Grid4Us
| Multi cultural Grid with 65 Regions and over 350 Users. Come,look and enjoy.
| Centered at 8500,8500
<br>

|-
| '''87.230.89.74:9000'''
| SCHWARZE WELT
| inworld location of www.schwarze-welle.de , the maybe biggest dark music streaming readio
| 100000 10000
<br>

|-
| '''peak.sciencesim.com:9001'''
| ScienceSim
| [http://www.sciencesim.com/ ScienceSim] is a virtual world created for the high performance computing community for scientific visualizations, a number of interesting real world terrains (Mt St Helens and Yellowstone Park) and some astronomical simulations. And some useful, BSD-licensed content.
| Centered at 10000,10000
|-
| '''alpha.bubblecloud.org:9000'''
| Bubble Cloud
| The alpha 00 is the entrance area to bubble cloud grid. Bubble cloud is test grid where anyone can experiment. If you build something please do it in medieval fantasy setting for others to enjoy.
| Centered at 10,000, 10,000
|-
| '''opensim.mydyn.de:9090'''
| OpenSIM.de Sim1
| [http://www.opensim.de OpenSim.de], 4 Server (Linux/Windows), hypergrided standalones, 16 Regions, German Users (Deutsche Benutzer), Live-Support, IRC-Gateway, Wiki, FAQ, Howto´s, Downloads. Connected to most of the Grids and some hypergrided standalones.
| Centered at 4400,4400
|-
| '''64.150.180.188:9031'''
| Virtual World Trade Center
| [http://PleasurePlanet.net], The VWTC. A repository for freebie items to share with the OS community. Weekly oar files will be made freely available on 4shared.com.
| VWTC is at 3003, 3003
|-
| '''jamland.de:9300'''
| Grid Jamland
| [http://Jamland.de], German Grid .. 9 regions with Sandbox (Jamland9) Fort (Jamland11) Schloss (Jamland6) Sahara (Jamland5) Office (Jamland2)
| Centered at 8000, 8000
|-
| '''condensationland.com:9000'''
| Zonja Capalini
| Condensation Land Grid, 5 regions and links to several other HG-enabled sims.
| Centered at 7789, 7789
|-
| '''condensationland.com:20000'''
| Zonja Capalini
| The Condensation Gateway region in OSGrid, statically hyperlinked to the Condensation Land Grid.
| Region at 3789,3789
|-
| '''66.240.232.94:9010'''
| Snoopy Pfeffer
| OSGrid, Samsara, freebie shopping region
| Centered at 10006, 9999
|-
| '''66.240.232.94:9011'''
| Snoopy Pfeffer
| OSGrid, Snoopies, dance club and event region
| Centered at 10005, 9999
|-
| '''twistedsky.net:9000'''
| Twisted Sky
| Welcome region on the Twisted Sky World Grid (at 998, 1000) - http://twistedsky.net
| Centered at 1000, 1000
|-
| '''www.xn--tln-tna.net:8002'''
| Tlön
| Tlön, Uqbar and Orbis Tertius - http://www.tlön.net (http://www.xn--tln-tna.net/)
| Centered at 7650, 7650
|-
| '''logicamp.dyndns.org:9300'''
| Logicamp
| [http://www.logicamp.com/ Logicamp] is a virtual world specialized in camp-site management and virtual tourism. You can visit it throughout our cable network.
|
|-
| '''yoursimspot.com:9000'''
| yoursimspot
| Wecome to our region yoursimspot [http://yoursimspot.com http://yoursimspot.com]
| centered at 1,000, 1,000
|
|-
| '''julpet.ath.cx:9020'''
| PMGrid
| PMGrid is a set of areas for grid development prior to implementation so there is no specific theme. Visit here and see a varied range of builds and perhaps get some ideas for yourself.[http://pmgrid.julpet.ath.cx http://pmgrid.julpet.ath.cx]
| centered at 7000, 7,000
|}

== External directories of Hypergrid-enabled sims ==

* [http://www.gridhop.net GridHop]

[[Category:Hypergrid]]

News

2009-06-18T17:38:50Z

Carlosroundel: /* Blogs */

{{Template:Quicklinks}}
__NOTOC__

==Project News==
===May 2009===
Starting in r9562 OpenSim has a set of new configuration variables that specify how services and service connectors are set up.

Please reference the [[Services_and_Service_Connectors_Configuration | Services and Service Connectors Configuration]] page for more information.

===April 2009===
* There is a current proposal to drop Visual Studio 2005 support in OpenSim by end of May. Visual Studio 2008 will still be supported. If you have strong opinions on the matter, use the [[Mailing_Lists|mailing lists]] to make your voice heard.

* We are experimenting with a feature suggestion tracker, visit [http://www.opensimulator.org/features/ opensimulator.org/features] to suggest new feature ideas.

==Press==
===September 2008===
*[http://www-03.ibm.com/press/us/en/pressrelease/25038.wss 03 Sep 2008 - Made in IBM Labs: IBM Moves Real-Time Communication and Collaboration Into 3-D (integrated with OpenSim)]
===February 2008===
* [http://www-03.ibm.com/press/us/en/pressrelease/23565.wss 21st Feb 2008 - Made in IBM Labs: IBM 3-D Data Centers Show Virtual Worlds Fit for Business]
* [http://www.realxtend.org/realxtend_opensim_release_15_02_2008.html 15th Feb 2008 - RealXtend joins OpenSim: Team up to make open source Virtual World standard]
* [http://www.ngigroup.com/jp/press/2008/02/001264.html 5th Feb 2008 - 3Di, Inc. Creates Voice Communication Function for Its Virtual World Application "Jin-sei"]
<cleanpage title=hide cats=hide />

==RSS Feeds==
<rss>http://planet.opensim.us/rss20.xml|max=5|short|filter=opensim</rss>
<rss>http://feeds.technorati.com/search/opensim?language=en|max=5|short</rss>
<rss>http://feeds.technorati.com/search/opensim?authority=n&language=pt|max=5|short</rss>
<rss>http://feeds.technorati.com/search/opensim?authority=n&language=es|max=5|short</rss>
<rss>http://feeds.technorati.com/search/opensim?authority=n&language=fr|max=5|short</rss>

==Blogs==
* [http://www.worldsimterra.com WorldSimTerra (Português, English, Español)]
* [http://www.adamfrisby.com/blog/2008/08/resources-for-running-your-own-opensim Adam's OpenSim resources blog post] - a list of resources for running OpenSim
* [http://rock-vacirca.blogspot.com Rock Vacirca's Blog] - lots of tutorials, not only on OpenSim, but on MySQL, Hippo, Second Inventory, etc
* [http://justincc.wordpress.com justincc's blog] - A blog with a weekly OpenSim development update and regular articles on various OpenSim topics.
* [http://lbsa71.net/category/opensim/ lbsa71.net] - tidbits from an OpenSim developer.
* [http://imohax.com Mo Hax] - posts and videos about OpenSim and Second Life from beginner perspective, focus on content previewing and educational use
* [http://www.metaverse3d.com/tag/opensim/ Metaverse3d] - French blog about metaverse and OpenSim.
* [http://www.subwereld.nl/ Subwereld] - A Dutch weblog about the OpenSimulator Project, the virtual world grids and OpenSim tools.
* [http://maxping.org/ Maxping] - A web magazine that writes about open source virtual worlds.
* [http://blog.cyberlandia.net/ Cyberlandia Blog] - Italian blog about Opensim, hypergrid and virtual worlds

HyperGrid Team

2009-05-12T07:56:34Z

Carlosroundel: /* Standalone HyperGrid Regions */

== What is the <nowiki>HyperGrid</nowiki> Team? ==
The <nowiki>HyperGrid Team</nowiki> are a pioneering group of [[Gridnaut|Gridnauts]] dedicated to establishing a network of [[HyperGrid_Regions|HyperGrid Regions]] spanning every Grid possible. Our collective goal is to create a true [[HyperGrid]] across the [[Metaverse|Metaverse]].

== Who is the HyperGrid Team? ==
The HyperGrid Team is made up of people who are excited about the endless possibilities of being able to TelePort from Grid to Grid at the click of a prim. The majority of the team are themselves owners of HyperGrid Regions.

=== Core Hypergrid Team ===

* Andreas mueller (Graphics/Web Designer)
* Bruce Patton (Builder/Scripter)
* Diva (Opensimulator HG Developer)
* eaglefx Binder (HG Jumper)
* GoldenHawk (Builder/Scripter)
* [[User:Mikebert |Mikebert M34]]
* Richardus Raymaker
* Tiffany Sicling (Builder)
* Warin Cascabel (Builder/Scripter)

=== Testers on Hypergrid Team ===
* Andreas mueller
* Bruce Patton
* eaglefx Binder
* Jos Joszpe
* Richardus Raymaker
* Tiffany Sicling
* Carlos Roundel (owner Cyberlandia hypergrided Grid)
* Your Name Here

== What are you doing? ==

=== Main ToDo List ===
* [[HyperGrid_Team/ToDo|HyperGrid Team Todo List]]
* [[HyperGrid_Team/HowTo|HyperGrid Install and Running]]

=== Current Projects ===
* [[HyperGrid_Team/Current_Projects/HyperGrid_Stargate|HyperGrid Stargate]]

=== Proposed Projects ===
* [[HyperGrid_Team/Proposed_Projects/HG_Stargate_Vendor|HG Stargate Vendor]]
* [[HyperGrid_Team/Proposed_Projects/HG_Health_Monitor|HG Health Monitor]]
* [[HyperGrid_Team/Proposed_Projects/Metaverse_Connection_Centers|Metaverse Connection Centers]]

== Press ==

[http://www.mariasworlds.com/2009/04/internet-history-made-today-travels-thorugh-the-stargate/ Travels through the Stargate from Marias World]

== Are you on IRC? ==
Yes, we are. You can find us on irc.freenode.net #hypergrid

== When/Where are the meetings? ==
The Team meets once a week on Wednesday at 21:00 (9 PM) UTC/GMT (http://wwp.greenwichmeantime.com/) or 13:00 PST Viewer time.

=== Upcoming Meetings ===

{| cellpadding="10"
!Date
!Agenda
!Location
!SLURL
!Team Member
!ToDo
!Chat Logs
|-
|May 13, 2009
|[[HyperGrid_Team/Agenda/2009.1305|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.1305|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.1305|Chat Logs]]
|-
|}

=== Previous Meetings ===

{| cellpadding="10"
!Date
!Agenda
!Location
!SLURL
!Team Member
!Todo
!Chat Logs
|-
|May 6, 2009
|[[HyperGrid_Team/Agenda/2009.0506|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.0506|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0506|Chat Logs]]
|This meeting was cancelled
|-
|-
|April 29, 2009
|[[HyperGrid_Team/Agenda/2009.0429|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.0429|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0429|Chat Logs]]
|-
|-
|April 22, 2009
|[[HyperGrid_Team/Agenda/2009.0422|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.0422|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0422|Chat Logs]]
|-
|-
|April 15, 2009
|[[HyperGrid_Team/Agenda/2009.0415|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
||[[HyperGrid_Team/ToDo/2009.0415|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0415|Chat Logs]]
|-
|April 8, 2009
|[[HyperGrid_Team/Agenda/2009.0408|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.0408|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0408|Chat Logs]]
|-
|April 1, 2009
|Agenda
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.0401|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0402|Chat Logs]]
|-
|March 25, 2009
|Agenda
|Wright Plaza
|
|
|
|[[HyperGrid_Team/Chat_Logs/2009.0325|Chat Logs]]
|}

== HyperGrid Team Related Web Resouces ==

=== Collaboration Sites ===

* http://www.hypergrids.org - Just new released
* http://www.opensim.de/doku.php?id=projekte:hypergrid - German users

== Some HyperGrid Regions on the Team ==

=== Standalone HyperGrid Regions ===
{| cellpadding="10"
| Jamland
| secondlife://jamland.de:9300/
| coords, x=8000, y=8000
|-
| Richardus's Hyper
| secondlife://osg.rigutech.nl:9000/
| coords, x=11109,y=11111
|-
| Sunred Hyper
| secondlife://hypergrid.sunredbeach.com:9000/
| coords, x=11111, y=11111
|-
| Metaverse Sims
| secondlife://metaversesims.net:9000/
| coords, x=9000, y=9000
|
|-
| OpenSIM.de / M34 Sim-1
| secondlife://opensim.mydyn.de:9090/
| coords, x=4400, y=4400
|
|-
| OpenSIM.de / M34 Sim-2
| secondlife://grid.mydyn.de:9190/
| coords, x=7000, y=7000
|
|-
| OpenSIM.de / M34 Sim-3
| secondlife://hypergrid.mydyn.de:9290/
| coords, x=11000, y=11000
|
|-
| Cyberlandia.net
| secondlife://grid.cyberlandia.net:9000/
| coords, x=1002, y=1000
|
|}

=== OSgrid HyperGrid Regions ===

{| cellpadding="10"
| Base Kix
| secondlife://basekix.rollin.com:9007/
| coords, x=?????, y=?????
|-
| Nibiru
| secondlife://vimana.dyndns.org:9000/
| coords, x=8000, y=8000
|-
| Sunred Gateway
| secondlife://217.157.61.105:9000/
| coords, x=9995, y=10006
|-
| UCI Welcome
| secondlife://osl2.nac.uci.edu:9006/
| coords, x=?, y=?
|}

=== MyOpenGrid HyperGrid Regions ===

{| cellpadding="10"
| Over Land
| secondlife://myopengrid.com:9005/
| coords, x=7001, y=7001
|
|
|}

=== Public Hypergrid Nodes ===

{| cellpadding="10"
| http://opensimulator.org/wiki/Public_Hypergrid_Nodes
|-
|}

{{Languages}}

[[Category:Help|Formatting]]

HyperGrid Team

2009-05-12T07:56:08Z

Carlosroundel: /* Standalone HyperGrid Regions */

== What is the <nowiki>HyperGrid</nowiki> Team? ==
The <nowiki>HyperGrid Team</nowiki> are a pioneering group of [[Gridnaut|Gridnauts]] dedicated to establishing a network of [[HyperGrid_Regions|HyperGrid Regions]] spanning every Grid possible. Our collective goal is to create a true [[HyperGrid]] across the [[Metaverse|Metaverse]].

== Who is the HyperGrid Team? ==
The HyperGrid Team is made up of people who are excited about the endless possibilities of being able to TelePort from Grid to Grid at the click of a prim. The majority of the team are themselves owners of HyperGrid Regions.

=== Core Hypergrid Team ===

* Andreas mueller (Graphics/Web Designer)
* Bruce Patton (Builder/Scripter)
* Diva (Opensimulator HG Developer)
* eaglefx Binder (HG Jumper)
* GoldenHawk (Builder/Scripter)
* [[User:Mikebert |Mikebert M34]]
* Richardus Raymaker
* Tiffany Sicling (Builder)
* Warin Cascabel (Builder/Scripter)

=== Testers on Hypergrid Team ===
* Andreas mueller
* Bruce Patton
* eaglefx Binder
* Jos Joszpe
* Richardus Raymaker
* Tiffany Sicling
* Carlos Roundel (owner Cyberlandia hypergrided Grid)
* Your Name Here

== What are you doing? ==

=== Main ToDo List ===
* [[HyperGrid_Team/ToDo|HyperGrid Team Todo List]]
* [[HyperGrid_Team/HowTo|HyperGrid Install and Running]]

=== Current Projects ===
* [[HyperGrid_Team/Current_Projects/HyperGrid_Stargate|HyperGrid Stargate]]

=== Proposed Projects ===
* [[HyperGrid_Team/Proposed_Projects/HG_Stargate_Vendor|HG Stargate Vendor]]
* [[HyperGrid_Team/Proposed_Projects/HG_Health_Monitor|HG Health Monitor]]
* [[HyperGrid_Team/Proposed_Projects/Metaverse_Connection_Centers|Metaverse Connection Centers]]

== Press ==

[http://www.mariasworlds.com/2009/04/internet-history-made-today-travels-thorugh-the-stargate/ Travels through the Stargate from Marias World]

== Are you on IRC? ==
Yes, we are. You can find us on irc.freenode.net #hypergrid

== When/Where are the meetings? ==
The Team meets once a week on Wednesday at 21:00 (9 PM) UTC/GMT (http://wwp.greenwichmeantime.com/) or 13:00 PST Viewer time.

=== Upcoming Meetings ===

{| cellpadding="10"
!Date
!Agenda
!Location
!SLURL
!Team Member
!ToDo
!Chat Logs
|-
|May 13, 2009
|[[HyperGrid_Team/Agenda/2009.1305|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.1305|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.1305|Chat Logs]]
|-
|}

=== Previous Meetings ===

{| cellpadding="10"
!Date
!Agenda
!Location
!SLURL
!Team Member
!Todo
!Chat Logs
|-
|May 6, 2009
|[[HyperGrid_Team/Agenda/2009.0506|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.0506|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0506|Chat Logs]]
|This meeting was cancelled
|-
|-
|April 29, 2009
|[[HyperGrid_Team/Agenda/2009.0429|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.0429|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0429|Chat Logs]]
|-
|-
|April 22, 2009
|[[HyperGrid_Team/Agenda/2009.0422|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.0422|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0422|Chat Logs]]
|-
|-
|April 15, 2009
|[[HyperGrid_Team/Agenda/2009.0415|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
||[[HyperGrid_Team/ToDo/2009.0415|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0415|Chat Logs]]
|-
|April 8, 2009
|[[HyperGrid_Team/Agenda/2009.0408|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.0408|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0408|Chat Logs]]
|-
|April 1, 2009
|Agenda
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.0401|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0402|Chat Logs]]
|-
|March 25, 2009
|Agenda
|Wright Plaza
|
|
|
|[[HyperGrid_Team/Chat_Logs/2009.0325|Chat Logs]]
|}

== HyperGrid Team Related Web Resouces ==

=== Collaboration Sites ===

* http://www.hypergrids.org - Just new released
* http://www.opensim.de/doku.php?id=projekte:hypergrid - German users

== Some HyperGrid Regions on the Team ==

=== Standalone HyperGrid Regions ===
{| cellpadding="10"
| Jamland
| secondlife://jamland.de:9300/
| coords, x=8000, y=8000
|-
| Richardus's Hyper
| secondlife://osg.rigutech.nl:9000/
| coords, x=11109,y=11111
|-
| Sunred Hyper
| secondlife://hypergrid.sunredbeach.com:9000/
| coords, x=11111, y=11111
|-
| Metaverse Sims
| secondlife://metaversesims.net:9000/
| coords, x=9000, y=9000
|
|-
| OpenSIM.de / M34 Sim-1
| secondlife://opensim.mydyn.de:9090/
| coords, x=4400, y=4400
|
|-
| OpenSIM.de / M34 Sim-2
| secondlife://grid.mydyn.de:9190/
| coords, x=7000, y=7000
|
|-
| OpenSIM.de / M34 Sim-3
| secondlife://hypergrid.mydyn.de:9290/
| coords, x=11000, y=11000
|
|
| Cyberlandia.net
| secondlife://grid.cyberlandia.net:9000/
| coords, x=1002, y=1000
|
|}

=== OSgrid HyperGrid Regions ===

{| cellpadding="10"
| Base Kix
| secondlife://basekix.rollin.com:9007/
| coords, x=?????, y=?????
|-
| Nibiru
| secondlife://vimana.dyndns.org:9000/
| coords, x=8000, y=8000
|-
| Sunred Gateway
| secondlife://217.157.61.105:9000/
| coords, x=9995, y=10006
|-
| UCI Welcome
| secondlife://osl2.nac.uci.edu:9006/
| coords, x=?, y=?
|}

=== MyOpenGrid HyperGrid Regions ===

{| cellpadding="10"
| Over Land
| secondlife://myopengrid.com:9005/
| coords, x=7001, y=7001
|
|
|}

=== Public Hypergrid Nodes ===

{| cellpadding="10"
| http://opensimulator.org/wiki/Public_Hypergrid_Nodes
|-
|}

{{Languages}}

[[Category:Help|Formatting]]

HyperGrid Team

2009-05-12T07:52:33Z

Carlosroundel: /* Testers on Hypergrid Team */

== What is the <nowiki>HyperGrid</nowiki> Team? ==
The <nowiki>HyperGrid Team</nowiki> are a pioneering group of [[Gridnaut|Gridnauts]] dedicated to establishing a network of [[HyperGrid_Regions|HyperGrid Regions]] spanning every Grid possible. Our collective goal is to create a true [[HyperGrid]] across the [[Metaverse|Metaverse]].

== Who is the HyperGrid Team? ==
The HyperGrid Team is made up of people who are excited about the endless possibilities of being able to TelePort from Grid to Grid at the click of a prim. The majority of the team are themselves owners of HyperGrid Regions.

=== Core Hypergrid Team ===

* Andreas mueller (Graphics/Web Designer)
* Bruce Patton (Builder/Scripter)
* Diva (Opensimulator HG Developer)
* eaglefx Binder (HG Jumper)
* GoldenHawk (Builder/Scripter)
* [[User:Mikebert |Mikebert M34]]
* Richardus Raymaker
* Tiffany Sicling (Builder)
* Warin Cascabel (Builder/Scripter)

=== Testers on Hypergrid Team ===
* Andreas mueller
* Bruce Patton
* eaglefx Binder
* Jos Joszpe
* Richardus Raymaker
* Tiffany Sicling
* Carlos Roundel (owner Cyberlandia hypergrided Grid)
* Your Name Here

== What are you doing? ==

=== Main ToDo List ===
* [[HyperGrid_Team/ToDo|HyperGrid Team Todo List]]
* [[HyperGrid_Team/HowTo|HyperGrid Install and Running]]

=== Current Projects ===
* [[HyperGrid_Team/Current_Projects/HyperGrid_Stargate|HyperGrid Stargate]]

=== Proposed Projects ===
* [[HyperGrid_Team/Proposed_Projects/HG_Stargate_Vendor|HG Stargate Vendor]]
* [[HyperGrid_Team/Proposed_Projects/HG_Health_Monitor|HG Health Monitor]]
* [[HyperGrid_Team/Proposed_Projects/Metaverse_Connection_Centers|Metaverse Connection Centers]]

== Press ==

[http://www.mariasworlds.com/2009/04/internet-history-made-today-travels-thorugh-the-stargate/ Travels through the Stargate from Marias World]

== Are you on IRC? ==
Yes, we are. You can find us on irc.freenode.net #hypergrid

== When/Where are the meetings? ==
The Team meets once a week on Wednesday at 21:00 (9 PM) UTC/GMT (http://wwp.greenwichmeantime.com/) or 13:00 PST Viewer time.

=== Upcoming Meetings ===

{| cellpadding="10"
!Date
!Agenda
!Location
!SLURL
!Team Member
!ToDo
!Chat Logs
|-
|May 13, 2009
|[[HyperGrid_Team/Agenda/2009.1305|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.1305|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.1305|Chat Logs]]
|-
|}

=== Previous Meetings ===

{| cellpadding="10"
!Date
!Agenda
!Location
!SLURL
!Team Member
!Todo
!Chat Logs
|-
|May 6, 2009
|[[HyperGrid_Team/Agenda/2009.0506|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.0506|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0506|Chat Logs]]
|This meeting was cancelled
|-
|-
|April 29, 2009
|[[HyperGrid_Team/Agenda/2009.0429|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.0429|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0429|Chat Logs]]
|-
|-
|April 22, 2009
|[[HyperGrid_Team/Agenda/2009.0422|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.0422|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0422|Chat Logs]]
|-
|-
|April 15, 2009
|[[HyperGrid_Team/Agenda/2009.0415|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
||[[HyperGrid_Team/ToDo/2009.0415|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0415|Chat Logs]]
|-
|April 8, 2009
|[[HyperGrid_Team/Agenda/2009.0408|Agenda]]
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.0408|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0408|Chat Logs]]
|-
|April 1, 2009
|Agenda
|Nibiru OSGrid
|secondlife://vimana.dyndns.org:9000/
|Tiffany Sicling
|[[HyperGrid_Team/ToDo/2009.0401|Todo]]
|[[HyperGrid_Team/Chat_Logs/2009.0402|Chat Logs]]
|-
|March 25, 2009
|Agenda
|Wright Plaza
|
|
|
|[[HyperGrid_Team/Chat_Logs/2009.0325|Chat Logs]]
|}

== HyperGrid Team Related Web Resouces ==

=== Collaboration Sites ===

* http://www.hypergrids.org - Just new released
* http://www.opensim.de/doku.php?id=projekte:hypergrid - German users

== Some HyperGrid Regions on the Team ==

=== Standalone HyperGrid Regions ===
{| cellpadding="10"
| Jamland
| secondlife://jamland.de:9300/
| coords, x=8000, y=8000
|-
| Richardus's Hyper
| secondlife://osg.rigutech.nl:9000/
| coords, x=11109,y=11111
|-
| Sunred Hyper
| secondlife://hypergrid.sunredbeach.com:9000/
| coords, x=11111, y=11111
|-
| Metaverse Sims
| secondlife://metaversesims.net:9000/
| coords, x=9000, y=9000
|
|-
| OpenSIM.de / M34 Sim-1
| secondlife://opensim.mydyn.de:9090/
| coords, x=4400, y=4400
|
|-
| OpenSIM.de / M34 Sim-2
| secondlife://grid.mydyn.de:9190/
| coords, x=7000, y=7000
|
|-
| OpenSIM.de / M34 Sim-3
| secondlife://hypergrid.mydyn.de:9290/
| coords, x=11000, y=11000
|
|}

=== OSgrid HyperGrid Regions ===

{| cellpadding="10"
| Base Kix
| secondlife://basekix.rollin.com:9007/
| coords, x=?????, y=?????
|-
| Nibiru
| secondlife://vimana.dyndns.org:9000/
| coords, x=8000, y=8000
|-
| Sunred Gateway
| secondlife://217.157.61.105:9000/
| coords, x=9995, y=10006
|-
| UCI Welcome
| secondlife://osl2.nac.uci.edu:9006/
| coords, x=?, y=?
|}

=== MyOpenGrid HyperGrid Regions ===

{| cellpadding="10"
| Over Land
| secondlife://myopengrid.com:9005/
| coords, x=7001, y=7001
|
|
|}

=== Public Hypergrid Nodes ===

{| cellpadding="10"
| http://opensimulator.org/wiki/Public_Hypergrid_Nodes
|-
|}

{{Languages}}

[[Category:Help|Formatting]]

Hypergrid

2009-01-02T18:50:52Z

Carlosroundel: /* Public Hypergrid Nodes */

==The OpenSim Hypergrid==

=== What is the hypergrid? ===


The hypergrid is an extension to opensim that allows you to link your opensim to other opensims on the internet, and that supports seamless agent transfers among those opensims. It can be used both in standalone mode and in grid mode. The hypergrid is effectively supporting the emergence of a Web of virtual worlds.

The basic idea for the hypergrid is that region/grid administrations can place hyperlinks on their map to hypergrided regions run by others. Once those hyperlinks are established, users interact with those regions in exactly the same way as they interact with local regions. Specifically, users can choose to teleport there. Once the user reaches the region behind the hyperlink, she is automatically interacting with a different virtual world without having to logout from the world where she came from, and while still having access to her inventory.

The hypergrid started as a GForge project, but it is now included in the standard distribution of OpenSim. To run your OpenSim instance in hypergrid mode, please see [[Hypergrid#Installing_and_Running_Hypergrid|Installing and Running]].

=== Virtual World Hyperlinks ===
[[image:hghyperlink.jpg|250px|thumb|A Virtual World Hyperlink]]

We're all familiar with hypertext links on the Web. But what is a virtual world hyperlink?

In the hypergrid model, we consider the 2D map of the virtual world as the equivalent of a web page. As such, a VW hyperlink is simply a region on that map.

The default model of opensim-based virtual worlds already supports this concept of hyperlink, to some extent. When you teleport from one region to another via the map, chances are you are migrating your agent into a different opensim server. This migration is a glorified "agent transfer" that also exists, in rudimentary form, on the web when hypertext links are followed. The default model, however, imposes two very strong constraints on these hyperlinks:
# The entire map of regions is controlled by a central service known as the grid service, whose job is to provide a uniform view of the world to all of its regions.
# The only agents that can be transferred are those pertaining to users known to another central service, the user service; if the incoming user is not on that service's database, the agent transfer doesn't go through.

The hypergrid simply removes these two constraints.

First, it allows individual opensim instances to add "neighbors" to their local map, shifting the control of the map down from the grid server to individual opensim instances (although hyperlinks can also be served by grid servers if grid admins so wish). In doing so, the world becomes a lot more interesting and varied. The map that you see in one opensim instance may be completely different from the map that you see after you teleport via an hyperlink. As an opensim administrator, you are free to define what other opensims you want to see on your map.

Second, it allows the transfer of agents pertaining to foreigner users, i.e. users who are registered elsewhere. Instead of assuming one central user service, the hypergrid assumes an arbitrarily large number of such services distributed all over the world. As such, when agents are transferred among hypergrided opensims, a lot more information is passed about the corresponding user. That information includes the collection of servers that the transferring user needs.

=== Usage Scenarios ===

The following are some usage scenarios. There isn't a clear separation between these scenarios, there's a large overlap between them. This is also not an exhaustive list. The purpose of these descriptions is to give you some starting ideas for how to use the hypergrid in practice. Please feel free to add other interesting scenarios to this list.

{| {{Prettytable}}
|-
|
[[image:topoA.jpg|400px|left]]
|
'''Personal Worlds'''

This first scenario pertains to standalone opensims. Normally, standalones are completely disconnected from the internet. However, when run in hypergrid mode, standalones become network-able. As such, you can run your own world in your own computer, and link your world to whoever you want. For example, you can link to your friends' hypergrided opensims and to hypergrid gateways in open grids such as OSGrid.

The great thing about this scenario is that all of your assets are stored on your computer, and not on somebody else's server. You can back them up using ordinary backend tools. The not so great thing about this scenario is that all of your assets are stored on your computer! If your disk goes berserk, you loose them. (so make sure you make external backups regularly)

|-
|
[[image:topoB.jpg|400px|left]]
|
'''Communities'''

This second scenario is about communities, broadly construed. The idea here is that a group of people come together to support a small community grid, i.e. a common world where shared activities take place. But at the same time, the members of the community maintain their own standalone worlds. The standalones link to the community grid, and the community grid may link back to the individual members' worlds and other places of interest.

The members' identities are probably the identities they have on their standalones, and their assets are also probably stored there. The assets present in the community regions, however, are stored on the grid asset server.

|-
|
[[image:topoC.jpg|400px|left]]
|
'''Grid Public Regions'''

Walled-gardens are here to stay, and they serve many useful purposes. There is a hybrid mode for the hypergrid that some walled-garden grid operators may be interested in supporting. In this hybrid mode, most opensim instances on the grid run in normal, wall-garden mode, so no foreign visitors are allowed there - technically it is impossible to reach them. However, a few opensim instances on that grid can run in hypergrid mode, so that foreign visitors are allowed. This way, there is a gateway for grid-local users and arbitrary visitors to meet. This is also a good strategy for attracting new users to the grid, since random users are able to visit those gateway regions without having to sign up for an account upfront.

This hybrid mode is very similar to what happens on the web. For example, anyone can visit Facebook's public pages without having to sign up for a Facebook account. However, only Facebook users can go further inside.

|-
|
[[image:topoD.jpg|400px|left]]
|
'''Level Games'''

The normal version of OpenSim enforces a common map for all the regions on a grid. The hypergrid removes that constraint. As such, it becomes easy to design VW games where the world looks different depending of where the player is.

|-
|}

== Security Concerns ==

There is a wide-spread assumption that open grids such as OSGrid and new forms of grids such as the hypergrid are inherently insecure, and that it will be impossible to develop a "goods-based" economy on top of them; only walled-gardens can be secured. This is both true and false. While it is true with the current state of things, open grids, whatever their form, can be made as secure as the web. The first step towards that is to define exactly what the security threats are, and how they affect (or not) open and closed grids. So, let's spell them out, and face them head-on. This will help put our feet on the ground so that we start developing appropriate solutions.

=== Malicious Clients ===

==== CopyBots ====

Everyone knows about the infamous [http://en.wikipedia.org/wiki/CopyBot CopyBot]. Using libraries such as [http://www.libsecondlife.org/wiki/Main_Page LibSL] (now known as OpenMetaverse) it is possible to develop clients for opensim servers that do unorthodox things such as bypassing the permissions system to copy people's assets. Bots written by griefers can do lots of other nasty things.

Malicious bots are a problem for all opensim administrators, including walled-garden grids. They can be prevented, to a certain extent, by exo-technical solutions such as Terms of Service and real-world lawsuits. Technically speaking, the only way to keep intruders out is to run opensim inside a firewall, pretty much like all other pieces of client/server software out there. If that's an acceptable solution for your case, you should do it.

Unfortunately firewalls also keep the public out, and most opensim operators, even the ones running walled-garden grids, want to reach out to the public. In this case, opensim operators may develop additional technical obstacles for bots, similar to those we see on the Web. For example, make sure agents are being run by real people by giving them a human-challenge during the login/TP process, etc.

Every obstacle to malicious clients lowers the risk of an intruder attack. However keep this in mind: no matter how many obstacles one builds, a sufficiently skilled and motivated attacker will be able to overcome them to penetrate opensims connected to the public internet. This affects hypergrid nodes as much as walled-garden grids. In fact, it's more pervasive than that: it affects '''all''' servers (opensim, web, etc.) connected to the public internet. Fighting malicious intruders is a fact of a connected world. Fortunately, those attacks don't happen very often, or the Web would have been dead by now.

==== Web Clients ====

CopyBots are the most well-known bots for opensim-based virtual worlds, but these virtual worlds are also susceptible to attacks by regular web clients. With the current state of things, it is actually easier to copy assets with a web-based client than with a libsl-based one. The weakness is that asset servers are connected to the public internet, and the protocol for interacting with them is public.

OpenSim has some minimal guards in place to fence against these kinds of attacks. Specifically, when the inventory server receives a request for an item, it checks the session identifier of the requester. Web clients aren't logged in, so they are refused service. I don't want to expand much more on this, so not to make life easy for attackers, but let's just say that opensim has the necessary mechanisms in place to fence off web-based attackers.

=== Malicious Hosts ===

==== Actively Malicious Hosts ====

The new security threat introduced by openness, one that does not exist in closed grids, is the possibility of a user to visit a region that is running malicious code. In the current state of opensim, a malicious host can do serious damage to the user's assets. Let's see how.

Assume you have your assets in your hypergrided-standalone opensim, and you go visit another opensim that happens to be running malicious code. Here is a non-exhaustive list of vulnerabilities that you are exposed to:

* The host has your session id, so it can request your inventory items on your behalf and store copies in its local asset server. To add insult to injury, a malicious host could simply wipe out your inventory after having copied it.
* Even if the malicious host doesn't access your items by itself, every time you access items in your inventory while you are in that region, those items are cached in the region's local cache, and can be stored persistently by the malicious host.

Malicious hosts can do a lot more damage, but those two are enough to illustrate this new kind of vulnerability affecting open grids. Note that this affects all open grids, i.e. those where arbitrary people can plug-in their opensims, and not just the hypergrid.

Fortunately, there is a family of simple solutions to this problem that can be summarized as "protecting you from yourself." That proposal is described [[Hypergrid Inventory Access|here]].

==== Piracy ====

A second new security threat affecting open grids is one pertaining to commerce of virtual goods. Suppose you put something out for sale on your hypergrided opensim. A foreign user comes and buys it. What that really means is that that user will physically get a copy of the assets moved to his/her asset server, which is different from your asset server. The permissions will be whatever you define them to be, and using the regular VW client, that user can only do what you defined he/she should could do with the object, as usual. However, if the user has direct backend access to the asset and inventory servers, that person can simply modify the permissions on his/her copy. This is commonly known as '''piracy'''. (This is also a problem with programmers who have direct access to the cache that their client keeps; in this case, the only thing that needs to be done to enable piracy is for the user to actually see a texture/animation/in-world object. This does NOT allow scripts to be copied, though, since the script is only interpreted on the server and is never sent for interpretation by the client.)

This situation is the kernel of the belief that open grids are hopeless for a virtual-goods economy. DRM discussion aside, maybe they are hopeless. But then, everyone thought the web was hopeless for selling music, and look at the success of iTunes in spite of all the piracy that still exists out there. Who will be the equivalent of iTunes for virtual hair, skin and clothes?

== Hypergrid Implementation ==

=== Hyperlinks and Agent Transfers ===

When you establish a link between your opensim and another, a message is sent out to that other opensim requesting information about it; the required information includes the network information of that opensim host, and the coordinates of its first region on its local grid in the form of a region handle. For example, suppose you are linking node X.com:9000, placing it in your local map at 900, 900. That opensim runs one or more regions that likely are not in 900, 900 on their own map; suppose the first region of that opensim is at 1100, 1100. From your point of view, it doesn't matter what those other coordinates are, and you don't need to know -- that's the key to being able to decentralize the "world" as given by a 2D map; you want to place it in your map at 900, 900. The "true" position of that simulator only matters for the LL viewer, when there are teleports between your world and that other opensim. This mapping between coordinate systems is the essence of hyperlinks for opensim; it's one simple but critical thing that the hypergrid implementation does. The mapping happens on the TeleportFinish event; instead of sending the local coordinates to the viewer, the hypergrid teleport wrapper sends the remote coordinates.

When an agent teleports through that hyperlink the following happens. First, before InformRegionOfChildAgent, the local opensim notifies the remote opensim of this foreign user via the "expect_hg_user" method. That message sends along the addresses of all the servers that this user uses, i.e. user, inventory and asset servers. The remote opensim places an entry for that user in its local user profile cache but not in its user database; the foreign user information is non-persistent. After that, the teleport process is exactly the same as the normal teleport process; the only difference is that the region handles are switched between the remote region's hyperlink position on the local grid and its actual position on its grid.

In summary, the two new concepts introduced by the hypergrid are the concept of an hyperlink and the concept of a "local user" vs. "foreign user".

=== Inventory Access ===

Inventory access from abroad is done by wrapping the existing scene-inventory interactions with additional code that gets or posts inventory assets from/to the user's asset server. When inventory is accessed, the hypergrid wrapper checks if the user is foreign and, if she is, the wrapper simply brings the necessary assets from the user's asset server to the local asset cache and server; from then on, the wrapper passes the control to the existing inventory access functions. When something is added to inventory, the hypergrid wrapper is notified via an event, and posts the assets to the user's asset server. A cache of the exchanged item identifiers is maintained so that they aren't brought back over and over again.

The result is that hypergrided opensim instances end up interacting with several asset servers, instead of just one. That interaction is implemented in a straightforward manner by instantiating several GridAssetClient objects, instead of just one.

=== The Hypergrid Namespace ===

Currently, the hypergrid is implemented outside of the OpenSim namespace, so that there is complete separation between what already exists and this new behavior. It has its own namespace, HyperGrid. In it, there are 4 sub-namespaces that follow directly the software architecture of OpenSim, namely:

* '''HyperGrid.Framework''' extends OpenSim.Framework in the following manner:
** HGUserProfileData extends UserProfileData by introducing information about the user's "home", namely the home address, port and remoting port. The user's home is not that user's user service; it's the opensim that the user has defined to be her home. This is necessary for supporting the home jump (Ctrl-Shift-H).
** HGNetworkServersInfo follows the spirit of NetworkServersInfo, although it neither extends it nor uses it. For now, it's a utility class whose two main functions are to convert domain names of servers to IP addresses, and to uniformly provide the answer to the question bool IsLocalUser(...).

* '''HyperGrid.Environment''' extends OpenSim.Region.Environment.Scenes in the following manner:
** HGSceneCommunicationService extends SceneCommunicationService, overriding RequestTeleportToLocation. There are two very small but critical changes to the base method: (a) on the TeleportFinish event, we switch the region handles when the destination region is an hyperlink; (b) the connections at the end are always closed for hyperlink TPs.
** HGScene extends Scene, overriding TeleportClientHome(...). The only change to the base method is to stay away from the user server, for now, because the user service is still not completely wrapped up for foreign users. Once the user service is properly wrapped up, this class will become unnecessary.
** HGScene.Inventory is a partial class of HGScene, just like what happens in the OpenSim framework. This part of HGScene overrides some inventory-scene interaction methods, so that assets are fetched/posted from/to the user's asset server. Once that extra fetching/posting is done, these methods simply pass the ball to the base methods.
** HGAssetMapper: this is a new class specific to the hypergrid that manages the fetching and posting of assets between foreign regions where the user is and the user's asset server.

* '''HyperGrid.Protocol''' is a mashup of OpenSim.Region.Communications.*. This is the place where most of the hypergrid extension lies. One of the reasons for this is that the hypergrid communications part is doing one additional thing: it is making standalones network-able.
** HGCommunicationsStandalone extends CommuniationsLocal. Just as its base, it is a hub for the several network services available in standalone mode. The main difference is that those services are extensions of what's in OpenSim.
** HGCommunicationsGridMode extends CommunicationsManager directly. Again, it's a hub for the network services available in grid mode, those services being extensions of OpenSim.
** The cluster HGGridServices (superclass), HGGridServicesStandalone and HGGridServicesGridMode (subclasses) implements the OpenSim interfaces IGridServices and IInterRegionCommunications. The 2 subclasses are wrappers for LocalBackEndServices and OGS1GridServices, respectively. There is one common pattern throughout these classes: check if the region to talk to is an hyperlink; if it's not, simply delegate the work to LocalBackEndServices/OGS1GridServices; if it is, push the work to the base class HGGridServices. HGGridServices, in turn, does the management of hyperlink regions, and defines two additional pieces of inter-region protocol:
*** region_uuid: for linking regions
*** expect_hg_user: similar to the existing expect_user interface, but with a lot more information about the user being passed around, namely all the user's servers (inventory, asset, user, home, etc.)
** HGInventoryService extends LocalInventoryService and implements ISecureInventoryService. This class is the most obvious mashup of the pack, mixing local service access for standalone users and remote inventory access for when users are out and about. Right now, there is a fair amount of selective copy-and-paste, to stay away from the ugliness coming from OGS1InventoryService and OGS1SecureInventoryService. HGInventoryService is always a ISecureInventoryService. Its methods all follow the same pattern: check if the user is a local standalone user; if it is, pass the work to the base method (in LocalInventoryService); if it's not perform secure remote access.
** HGUserServices wraps OSG1UserServices, but it's not functional yet.

* '''HyperGrid.Modules''' is a collection of 3 region modules:
** HGWorldMapModule extends WorldMapModule. It reuses almost everything from the base class. The only small change is in RequestMapBlocks, where it tries to send Offline mapblocks to the client.
** HGStandaloneInventoryService and HGStandaloneAssetService do what their names say. They are region modules that allow access to inventory and assets for standalones, when the standalone user is out and about. In spirit, there is a lot in common between these modules and the REST inventory/asset plugin. Unfortunately, that plugin could not be used because it defines a completely different interface than that used by existing inventory and asset servers, and the access for the hypergrid must use a consistent interface.

=== Class Diagram ===

[[image:HypergridImplementation.jpg|600px|center|(Click on the image to enlarge)]]

== Installing and Running Hypergrid ==

=== Installing ===

# Checkout OpenSim, prebuild and build as normal.
# Make the following changes to your OpenSim.ini:
#* The map: '''WorldMapModule = "HGWorldMap" ''' If you didn't have this setting in your original OpenSim.ini, make sure you place it under the [Startup] section.
#* If you're running your opensim in grid mode with the UGAIM servers on other machines, you're done. If you're running in standalone and you want it to be network-able, or if you have your grid on loopback (127.0.0.1) change all the [Network] server addresses to <nowiki>"http://<external_host_name>:<http_port>"</nowiki>. See below.
# Run opensim like this: <nowiki>[mono] OpenSim.exe -hypergrid=true</nowiki>. To make sure the hypergrid is running type this on your console: '''link-region'''. If you don't hear anything back, the hypergrid is not properly installed.

Here is an example of the Network settings for a standalone:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:9300
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:9300
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:9300
inventory_server_url = http://example.com:9300

Here is an example of the Network settings for a grided opensim:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:8001
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:8002
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:8003
inventory_server_url = http://example.com:8004

'''Important Note'''

Make sure you have a 'home' set. If your home region doesn't exist, the hyperlink TPs may not work. To set your home, go to one of your local regions and "Set Home" from the viewer.

=== Linking regions ===

On the console, type for example:

link-region <Xloc> <Yloc> osl2.nac.uci.edu 9006 OSGrid Gateway

* Use Xloc and Yloc that make sense to your world, i.e. close to your regions, but not adjacent.
* replace osl2.nac.uci.edu and 9006 with the domain name / ip address and the port of the region you want to link to

'''Important Note'''

Due to a viewer [https://jira.secondlife.com/browse/SVC-2941 bug], you can only TP between regions that are no more than 4096 cells apart in any dimension. What this means in practice is that if you want to link to OSGrid, you must have your own regions reachable from the (10,000; 10,000) point on the map, which is where OSGrid is centered. Place your regions somewhere in the 8,000s or the 12,000s.

== Public Hypergrid Nodes ==

The following is a list of hypergrid-ready nodes that you can use for testing your installation and for linking your world. Please add your public node here if you wish to help build a web of opensims!

For the time being, and until the security concerns described above are addressed, we advise you to be careful about who you link to.

* '''osl2.nac.uci.edu 9006'''
The "UCI Welcome" region connected to OSGrid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine. You can link to it as a way to link to OSGrid.

* '''ucigrid02.nacs.uci.edu 9000'''
A region in the UCI Grid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine.

* '''grid.cyberlandia.net 9000'''
The "Cyberlandia Gw" region. http://www.cyberlandia.net Metaverso italiano 3D, more to 250 region and 1000 users. You can link to it as a way to link to Cyberlandia.

* '''hypergrid.cyberlandia.net 9000'''
The "Osgrid Gw" region connected to Cyberlandia grid http://www.cyberlandia.net. Search on map "Cyberlandia grid" You can link to it as a way to link to OSGrid.

* '''joomla-italia.net 9000
The "SNI City" region connected to SNI (Social Network Italia) grid http://www.opensim-italia.net. This grid is connected with Osgrid,Collateral World,Francogrid and Darwin

* '''collateral.opensim-italia.net 9000
The "Collateral" region connected to Collateral World Grid http://collateral.opensim-italia.net. This grid is connected with Social Network Italia, Osgrid and Francogrid '''[This grid is temporarily offline for maintenance]'''

* '''88.191.79.199 9050'''
Francogrid node, connected to "City", behind the welcome land of Francogrid "Orion"

* '''94.23.8.158 9999'''
Le Monde de Darwin node, The Lost of Darwin http://www.LeMondedeDarwin.com
----
[[Image:hypergrid.jpg]]
----

* '''grid.k-grid.com 9000'''
K-grid, [http://k-grid.com the Kool grid for the Kool KidZ] . Feel free to visit us. The main Gateway is located at 3700,3700 so take that in account before any HyperJump

* '''metropolis.hypergrid.org 9000'''
The Region "Center-World" (at 1000:1000) connected to the METROPOLIS-Grid http://metropolis.hypergrid.org . German Grid with a lot of free Content and free SIM-hosting. Connected via HG to the most of the Grids listed here.

* '''ascent.bluewallgroup.com 9910'''
This region is in a good proximity @ (6000,6000) for intermediate jumps to OSGrid from grids in the (2000,2000) range, or any region within 4096 units. [[Image:Hypernaut 001.png|150px|none|thumb|Get your Hypernaut here :)]]

* '''sim.thestudyofracialism.org 9000'''
TSOR1 is a stand-alone 2-region sim (at 8000,8000). It connects via HG to most of the other sites listed here. Although currently sparse, the sim is eventually intended for an SL discussion-group's migration from SL to OS.

* '''http://myopengrid.com 9000'''
Myopengrid is connected to osl2.nac.uci.edu "Osgrid Gateway" our regions are at (7000,7000).

* '''cuonsim1.de 9300'''
Cuon-Grid is a little grid and has some Main Sims with linux themes, Regions are at (10000,10000),server are in Germany.

* '''metaversesims.net 9014'''
Standalone mode - 6 regions at (9000,9000) - linked to the grids shown below
----
[[Image:Mtvs09010101.jpg]]
----

Hypergrid

2009-01-01T10:06:15Z

Carlosroundel: /* Public Hypergrid Nodes */

==The OpenSim Hypergrid==

=== What is the hypergrid? ===


The hypergrid is an extension to opensim that allows you to link your opensim to other opensims on the internet, and that supports seamless agent transfers among those opensims. It can be used both in standalone mode and in grid mode. The hypergrid is effectively supporting the emergence of a Web of virtual worlds.

The basic idea for the hypergrid is that region/grid administrations can place hyperlinks on their map to hypergrided regions run by others. Once those hyperlinks are established, users interact with those regions in exactly the same way as they interact with local regions. Specifically, users can choose to teleport there. Once the user reaches the region behind the hyperlink, she is automatically interacting with a different virtual world without having to logout from the world where she came from, and while still having access to her inventory.

The hypergrid started as a GForge project, but it is now included in the standard distribution of OpenSim. To run your OpenSim instance in hypergrid mode, please see [[Hypergrid#Installing_and_Running_Hypergrid|Installing and Running]].

=== Virtual World Hyperlinks ===
[[image:hghyperlink.jpg|250px|thumb|A Virtual World Hyperlink]]

We're all familiar with hypertext links on the Web. But what is a virtual world hyperlink?

In the hypergrid model, we consider the 2D map of the virtual world as the equivalent of a web page. As such, a VW hyperlink is simply a region on that map.

The default model of opensim-based virtual worlds already supports this concept of hyperlink, to some extent. When you teleport from one region to another via the map, chances are you are migrating your agent into a different opensim server. This migration is a glorified "agent transfer" that also exists, in rudimentary form, on the web when hypertext links are followed. The default model, however, imposes two very strong constraints on these hyperlinks:
# The entire map of regions is controlled by a central service known as the grid service, whose job is to provide a uniform view of the world to all of its regions.
# The only agents that can be transferred are those pertaining to users known to another central service, the user service; if the incoming user is not on that service's database, the agent transfer doesn't go through.

The hypergrid simply removes these two constraints.

First, it allows individual opensim instances to add "neighbors" to their local map, shifting the control of the map down from the grid server to individual opensim instances (although hyperlinks can also be served by grid servers if grid admins so wish). In doing so, the world becomes a lot more interesting and varied. The map that you see in one opensim instance may be completely different from the map that you see after you teleport via an hyperlink. As an opensim administrator, you are free to define what other opensims you want to see on your map.

Second, it allows the transfer of agents pertaining to foreigner users, i.e. users who are registered elsewhere. Instead of assuming one central user service, the hypergrid assumes an arbitrarily large number of such services distributed all over the world. As such, when agents are transferred among hypergrided opensims, a lot more information is passed about the corresponding user. That information includes the collection of servers that the transferring user needs.

=== Usage Scenarios ===

The following are some usage scenarios. There isn't a clear separation between these scenarios, there's a large overlap between them. This is also not an exhaustive list. The purpose of these descriptions is to give you some starting ideas for how to use the hypergrid in practice. Please feel free to add other interesting scenarios to this list.

{| {{Prettytable}}
|-
|
[[image:topoA.jpg|400px|left]]
|
'''Personal Worlds'''

This first scenario pertains to standalone opensims. Normally, standalones are completely disconnected from the internet. However, when run in hypergrid mode, standalones become network-able. As such, you can run your own world in your own computer, and link your world to whoever you want. For example, you can link to your friends' hypergrided opensims and to hypergrid gateways in open grids such as OSGrid.

The great thing about this scenario is that all of your assets are stored on your computer, and not on somebody else's server. You can back them up using ordinary backend tools. The not so great thing about this scenario is that all of your assets are stored on your computer! If your disk goes berserk, you loose them. (so make sure you make external backups regularly)

|-
|
[[image:topoB.jpg|400px|left]]
|
'''Communities'''

This second scenario is about communities, broadly construed. The idea here is that a group of people come together to support a small community grid, i.e. a common world where shared activities take place. But at the same time, the members of the community maintain their own standalone worlds. The standalones link to the community grid, and the community grid may link back to the individual members' worlds and other places of interest.

The members' identities are probably the identities they have on their standalones, and their assets are also probably stored there. The assets present in the community regions, however, are stored on the grid asset server.

|-
|
[[image:topoC.jpg|400px|left]]
|
'''Grid Public Regions'''

Walled-gardens are here to stay, and they serve many useful purposes. There is a hybrid mode for the hypergrid that some walled-garden grid operators may be interested in supporting. In this hybrid mode, most opensim instances on the grid run in normal, wall-garden mode, so no foreign visitors are allowed there - technically it is impossible to reach them. However, a few opensim instances on that grid can run in hypergrid mode, so that foreign visitors are allowed. This way, there is a gateway for grid-local users and arbitrary visitors to meet. This is also a good strategy for attracting new users to the grid, since random users are able to visit those gateway regions without having to sign up for an account upfront.

This hybrid mode is very similar to what happens on the web. For example, anyone can visit Facebook's public pages without having to sign up for a Facebook account. However, only Facebook users can go further inside.

|-
|
[[image:topoD.jpg|400px|left]]
|
'''Level Games'''

The normal version of OpenSim enforces a common map for all the regions on a grid. The hypergrid removes that constraint. As such, it becomes easy to design VW games where the world looks different depending of where the player is.

|-
|}

== Security Concerns ==

There is a wide-spread assumption that open grids such as OSGrid and new forms of grids such as the hypergrid are inherently insecure, and that it will be impossible to develop a "goods-based" economy on top of them; only walled-gardens can be secured. This is both true and false. While it is true with the current state of things, open grids, whatever their form, can be made as secure as the web. The first step towards that is to define exactly what the security threats are, and how they affect (or not) open and closed grids. So, let's spell them out, and face them head-on. This will help put our feet on the ground so that we start developing appropriate solutions.

=== Malicious Clients ===

==== CopyBots ====

Everyone knows about the infamous [http://en.wikipedia.org/wiki/CopyBot CopyBot]. Using libraries such as [http://www.libsecondlife.org/wiki/Main_Page LibSL] (now known as OpenMetaverse) it is possible to develop clients for opensim servers that do unorthodox things such as bypassing the permissions system to copy people's assets. Bots written by griefers can do lots of other nasty things.

Malicious bots are a problem for all opensim administrators, including walled-garden grids. They can be prevented, to a certain extent, by exo-technical solutions such as Terms of Service and real-world lawsuits. Technically speaking, the only way to keep intruders out is to run opensim inside a firewall, pretty much like all other pieces of client/server software out there. If that's an acceptable solution for your case, you should do it.

Unfortunately firewalls also keep the public out, and most opensim operators, even the ones running walled-garden grids, want to reach out to the public. In this case, opensim operators may develop additional technical obstacles for bots, similar to those we see on the Web. For example, make sure agents are being run by real people by giving them a human-challenge during the login/TP process, etc.

Every obstacle to malicious clients lowers the risk of an intruder attack. However keep this in mind: no matter how many obstacles one builds, a sufficiently skilled and motivated attacker will be able to overcome them to penetrate opensims connected to the public internet. This affects hypergrid nodes as much as walled-garden grids. In fact, it's more pervasive than that: it affects '''all''' servers (opensim, web, etc.) connected to the public internet. Fighting malicious intruders is a fact of a connected world. Fortunately, those attacks don't happen very often, or the Web would have been dead by now.

==== Web Clients ====

CopyBots are the most well-known bots for opensim-based virtual worlds, but these virtual worlds are also susceptible to attacks by regular web clients. With the current state of things, it is actually easier to copy assets with a web-based client than with a libsl-based one. The weakness is that asset servers are connected to the public internet, and the protocol for interacting with them is public.

OpenSim has some minimal guards in place to fence against these kinds of attacks. Specifically, when the inventory server receives a request for an item, it checks the session identifier of the requester. Web clients aren't logged in, so they are refused service. I don't want to expand much more on this, so not to make life easy for attackers, but let's just say that opensim has the necessary mechanisms in place to fence off web-based attackers.

=== Malicious Hosts ===

==== Actively Malicious Hosts ====

The new security threat introduced by openness, one that does not exist in closed grids, is the possibility of a user to visit a region that is running malicious code. In the current state of opensim, a malicious host can do serious damage to the user's assets. Let's see how.

Assume you have your assets in your hypergrided-standalone opensim, and you go visit another opensim that happens to be running malicious code. Here is a non-exhaustive list of vulnerabilities that you are exposed to:

* The host has your session id, so it can request your inventory items on your behalf and store copies in its local asset server. To add insult to injury, a malicious host could simply wipe out your inventory after having copied it.
* Even if the malicious host doesn't access your items by itself, every time you access items in your inventory while you are in that region, those items are cached in the region's local cache, and can be stored persistently by the malicious host.

Malicious hosts can do a lot more damage, but those two are enough to illustrate this new kind of vulnerability affecting open grids. Note that this affects all open grids, i.e. those where arbitrary people can plug-in their opensims, and not just the hypergrid.

Fortunately, there is a family of simple solutions to this problem that can be summarized as "protecting you from yourself." That proposal is described [[Hypergrid Inventory Access|here]].

==== Piracy ====

A second new security threat affecting open grids is one pertaining to commerce of virtual goods. Suppose you put something out for sale on your hypergrided opensim. A foreign user comes and buys it. What that really means is that that user will physically get a copy of the assets moved to his/her asset server, which is different from your asset server. The permissions will be whatever you define them to be, and using the regular VW client, that user can only do what you defined he/she should could do with the object, as usual. However, if the user has direct backend access to the asset and inventory servers, that person can simply modify the permissions on his/her copy. This is commonly known as '''piracy'''. (This is also a problem with programmers who have direct access to the cache that their client keeps; in this case, the only thing that needs to be done to enable piracy is for the user to actually see a texture/animation/in-world object. This does NOT allow scripts to be copied, though, since the script is only interpreted on the server and is never sent for interpretation by the client.)

This situation is the kernel of the belief that open grids are hopeless for a virtual-goods economy. DRM discussion aside, maybe they are hopeless. But then, everyone thought the web was hopeless for selling music, and look at the success of iTunes in spite of all the piracy that still exists out there. Who will be the equivalent of iTunes for virtual hair, skin and clothes?

== Hypergrid Implementation ==

=== Hyperlinks and Agent Transfers ===

When you establish a link between your opensim and another, a message is sent out to that other opensim requesting information about it; the required information includes the network information of that opensim host, and the coordinates of its first region on its local grid in the form of a region handle. For example, suppose you are linking node X.com:9000, placing it in your local map at 900, 900. That opensim runs one or more regions that likely are not in 900, 900 on their own map; suppose the first region of that opensim is at 1100, 1100. From your point of view, it doesn't matter what those other coordinates are, and you don't need to know -- that's the key to being able to decentralize the "world" as given by a 2D map; you want to place it in your map at 900, 900. The "true" position of that simulator only matters for the LL viewer, when there are teleports between your world and that other opensim. This mapping between coordinate systems is the essence of hyperlinks for opensim; it's one simple but critical thing that the hypergrid implementation does. The mapping happens on the TeleportFinish event; instead of sending the local coordinates to the viewer, the hypergrid teleport wrapper sends the remote coordinates.

When an agent teleports through that hyperlink the following happens. First, before InformRegionOfChildAgent, the local opensim notifies the remote opensim of this foreign user via the "expect_hg_user" method. That message sends along the addresses of all the servers that this user uses, i.e. user, inventory and asset servers. The remote opensim places an entry for that user in its local user profile cache but not in its user database; the foreign user information is non-persistent. After that, the teleport process is exactly the same as the normal teleport process; the only difference is that the region handles are switched between the remote region's hyperlink position on the local grid and its actual position on its grid.

In summary, the two new concepts introduced by the hypergrid are the concept of an hyperlink and the concept of a "local user" vs. "foreign user".

=== Inventory Access ===

Inventory access from abroad is done by wrapping the existing scene-inventory interactions with additional code that gets or posts inventory assets from/to the user's asset server. When inventory is accessed, the hypergrid wrapper checks if the user is foreign and, if she is, the wrapper simply brings the necessary assets from the user's asset server to the local asset cache and server; from then on, the wrapper passes the control to the existing inventory access functions. When something is added to inventory, the hypergrid wrapper is notified via an event, and posts the assets to the user's asset server. A cache of the exchanged item identifiers is maintained so that they aren't brought back over and over again.

The result is that hypergrided opensim instances end up interacting with several asset servers, instead of just one. That interaction is implemented in a straightforward manner by instantiating several GridAssetClient objects, instead of just one.

=== The Hypergrid Namespace ===

Currently, the hypergrid is implemented outside of the OpenSim namespace, so that there is complete separation between what already exists and this new behavior. It has its own namespace, HyperGrid. In it, there are 4 sub-namespaces that follow directly the software architecture of OpenSim, namely:

* '''HyperGrid.Framework''' extends OpenSim.Framework in the following manner:
** HGUserProfileData extends UserProfileData by introducing information about the user's "home", namely the home address, port and remoting port. The user's home is not that user's user service; it's the opensim that the user has defined to be her home. This is necessary for supporting the home jump (Ctrl-Shift-H).
** HGNetworkServersInfo follows the spirit of NetworkServersInfo, although it neither extends it nor uses it. For now, it's a utility class whose two main functions are to convert domain names of servers to IP addresses, and to uniformly provide the answer to the question bool IsLocalUser(...).

* '''HyperGrid.Environment''' extends OpenSim.Region.Environment.Scenes in the following manner:
** HGSceneCommunicationService extends SceneCommunicationService, overriding RequestTeleportToLocation. There are two very small but critical changes to the base method: (a) on the TeleportFinish event, we switch the region handles when the destination region is an hyperlink; (b) the connections at the end are always closed for hyperlink TPs.
** HGScene extends Scene, overriding TeleportClientHome(...). The only change to the base method is to stay away from the user server, for now, because the user service is still not completely wrapped up for foreign users. Once the user service is properly wrapped up, this class will become unnecessary.
** HGScene.Inventory is a partial class of HGScene, just like what happens in the OpenSim framework. This part of HGScene overrides some inventory-scene interaction methods, so that assets are fetched/posted from/to the user's asset server. Once that extra fetching/posting is done, these methods simply pass the ball to the base methods.
** HGAssetMapper: this is a new class specific to the hypergrid that manages the fetching and posting of assets between foreign regions where the user is and the user's asset server.

* '''HyperGrid.Protocol''' is a mashup of OpenSim.Region.Communications.*. This is the place where most of the hypergrid extension lies. One of the reasons for this is that the hypergrid communications part is doing one additional thing: it is making standalones network-able.
** HGCommunicationsStandalone extends CommuniationsLocal. Just as its base, it is a hub for the several network services available in standalone mode. The main difference is that those services are extensions of what's in OpenSim.
** HGCommunicationsGridMode extends CommunicationsManager directly. Again, it's a hub for the network services available in grid mode, those services being extensions of OpenSim.
** The cluster HGGridServices (superclass), HGGridServicesStandalone and HGGridServicesGridMode (subclasses) implements the OpenSim interfaces IGridServices and IInterRegionCommunications. The 2 subclasses are wrappers for LocalBackEndServices and OGS1GridServices, respectively. There is one common pattern throughout these classes: check if the region to talk to is an hyperlink; if it's not, simply delegate the work to LocalBackEndServices/OGS1GridServices; if it is, push the work to the base class HGGridServices. HGGridServices, in turn, does the management of hyperlink regions, and defines two additional pieces of inter-region protocol:
*** region_uuid: for linking regions
*** expect_hg_user: similar to the existing expect_user interface, but with a lot more information about the user being passed around, namely all the user's servers (inventory, asset, user, home, etc.)
** HGInventoryService extends LocalInventoryService and implements ISecureInventoryService. This class is the most obvious mashup of the pack, mixing local service access for standalone users and remote inventory access for when users are out and about. Right now, there is a fair amount of selective copy-and-paste, to stay away from the ugliness coming from OGS1InventoryService and OGS1SecureInventoryService. HGInventoryService is always a ISecureInventoryService. Its methods all follow the same pattern: check if the user is a local standalone user; if it is, pass the work to the base method (in LocalInventoryService); if it's not perform secure remote access.
** HGUserServices wraps OSG1UserServices, but it's not functional yet.

* '''HyperGrid.Modules''' is a collection of 3 region modules:
** HGWorldMapModule extends WorldMapModule. It reuses almost everything from the base class. The only small change is in RequestMapBlocks, where it tries to send Offline mapblocks to the client.
** HGStandaloneInventoryService and HGStandaloneAssetService do what their names say. They are region modules that allow access to inventory and assets for standalones, when the standalone user is out and about. In spirit, there is a lot in common between these modules and the REST inventory/asset plugin. Unfortunately, that plugin could not be used because it defines a completely different interface than that used by existing inventory and asset servers, and the access for the hypergrid must use a consistent interface.

=== Class Diagram ===

[[image:HypergridImplementation.jpg|600px|center|(Click on the image to enlarge)]]

== Installing and Running Hypergrid ==

=== Installing ===

# Checkout OpenSim, prebuild and build as normal.
# Make the following changes to your OpenSim.ini:
#* The map: '''WorldMapModule = "HGWorldMap" ''' If you didn't have this setting in your original OpenSim.ini, make sure you place it under the [Startup] section.
#* If you're running your opensim in grid mode with the UGAIM servers on other machines, you're done. If you're running in standalone and you want it to be network-able, or if you have your grid on loopback (127.0.0.1) change all the [Network] server addresses to <nowiki>"http://<external_host_name>:<http_port>"</nowiki>. See below.
# Run opensim like this: <nowiki>[mono] OpenSim.exe -hypergrid=true</nowiki>. To make sure the hypergrid is running type this on your console: '''link-region'''. If you don't hear anything back, the hypergrid is not properly installed.

Here is an example of the Network settings for a standalone:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:9300
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:9300
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:9300
inventory_server_url = http://example.com:9300

Here is an example of the Network settings for a grided opensim:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:8001
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:8002
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:8003
inventory_server_url = http://example.com:8004

'''Important Note'''

Make sure you have a 'home' set. If your home region doesn't exist, the hyperlink TPs may not work. To set your home, go to one of your local regions and "Set Home" from the viewer.

=== Linking regions ===

On the console, type for example:

link-region <Xloc> <Yloc> osl2.nac.uci.edu 9006 OSGrid Gateway

* Use Xloc and Yloc that make sense to your world, i.e. close to your regions, but not adjacent.
* replace osl2.nac.uci.edu and 9006 with the domain name / ip address and the port of the region you want to link to

'''Important Note'''

Due to a viewer [https://jira.secondlife.com/browse/SVC-2941 bug], you can only TP between regions that are no more than 4096 cells apart in any dimension. What this means in practice is that if you want to link to OSGrid, you must have your own regions reachable from the (10,000; 10,000) point on the map, which is where OSGrid is centered. Place your regions somewhere in the 8,000s or the 12,000s.

== Public Hypergrid Nodes ==

The following is a list of hypergrid-ready nodes that you can use for testing your installation and for linking your world. Please add your public node here if you wish to help build a web of opensims!

For the time being, and until the security concerns described above are addressed, we advise you to be careful about who you link to.

* '''osl2.nac.uci.edu 9006'''
The "UCI Welcome" region connected to OSGrid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine. You can link to it as a way to link to OSGrid.

* '''ucigrid02.nacs.uci.edu 9000'''
A region in the UCI Grid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine.

* '''grid.cyberlandia.net 9000'''
The "Cyberlandia Gw" region. http://www.cyberlandia.net Metaverso italiano 3D, more to 250 region and 1000 users. You can link to it as a way to link to Cyberlandia.

* '''hypergrid.cyberlandia.net 9300'''
The "Osgrid Gw" region connected to Cyberlandia grid http://www.cyberlandia.net. Search on map "Cyberlandia grid" You can link to it as a way to link to OSGrid.

* '''joomla-italia.net 9000
The "SNI City" region connected to SNI (Social Network Italia) grid http://www.opensim-italia.net. This grid is connected with Osgrid,Collateral World,Francogrid and Darwin

* '''collateral.opensim-italia.net 9000
The "Collateral" region connected to Collateral World Grid http://collateral.opensim-italia.net. This grid is connected with Social Network Italia, Osgrid and Francogrid '''[This grid is temporarily offline for maintenance]'''

* '''88.191.79.199 9050'''
Francogrid node, connected to "City", behind the welcome land of Francogrid "Orion"

* '''94.23.8.158 9999'''
Le Monde de Darwin node, The Lost of Darwin http://www.LeMondedeDarwin.com
----
[[Image:hypergrid.jpg]]
----

* '''grid.k-grid.com 9000'''
K-grid, [http://k-grid.com the Kool grid for the Kool KidZ] . Feel free to visit us. The main Gateway is located at 3700,3700 so take that in account before any HyperJump

* '''metropolis.hypergrid.org 9000'''
The Region "Center-World" (at 1000:1000) connected to the METROPOLIS-Grid http://metropolis.hypergrid.org . German Grid with a lot of free Content and free SIM-hosting. Connected via HG to the most of the Grids listed here.

* '''ascent.bluewallgroup.com 9910'''
This region is in a good proximity @ (6000,6000) for intermediate jumps to OSGrid from grids in the (2000,2000) range, or any region within 4096 units. [[Image:Hypernaut 001.png|150px|none|thumb|Get your Hypernaut here :)]]

* '''sim.thestudyofracialism.org 9000'''
TSOR1 is a stand-alone 2-region sim (at 8000,8000). It connects via HG to most of the other sites listed here. Although currently sparse, the sim is eventually intended for an SL discussion-group's migration from SL to OS.

* '''http://myopengrid.com 9000'''
Myopengrid is connected to osl2.nac.uci.edu "Osgrid Gateway" our regions are at (7000,7000).

* '''sim-linuxmain.org 9300'''
Cuon-Grid is a little grid and has some Main Sims with linux themes, Regions are at (10000,10000),server are in Germany.

* '''metaversesims.net 9010'''
Standalone mode - 6 regions at (9000,9000) - linked to the grids shown below
----
[[Image:metaversesims.jpg]]
----

Hypergrid

2008-12-31T13:03:54Z

Carlosroundel: /* Public Hypergrid Nodes */

==The OpenSim Hypergrid==

=== What is the hypergrid? ===


The hypergrid is an extension to opensim that allows you to link your opensim to other opensims on the internet, and that supports seamless agent transfers among those opensims. It can be used both in standalone mode and in grid mode. The hypergrid is effectively supporting the emergence of a Web of virtual worlds.

The basic idea for the hypergrid is that region/grid administrations can place hyperlinks on their map to hypergrided regions run by others. Once those hyperlinks are established, users interact with those regions in exactly the same way as they interact with local regions. Specifically, users can choose to teleport there. Once the user reaches the region behind the hyperlink, she is automatically interacting with a different virtual world without having to logout from the world where she came from, and while still having access to her inventory.

The hypergrid started as a GForge project, but it is now included in the standard distribution of OpenSim. To run your OpenSim instance in hypergrid mode, please see [[Hypergrid#Installing_and_Running_Hypergrid|Installing and Running]].

=== Virtual World Hyperlinks ===
[[image:hghyperlink.jpg|250px|thumb|A Virtual World Hyperlink]]

We're all familiar with hypertext links on the Web. But what is a virtual world hyperlink?

In the hypergrid model, we consider the 2D map of the virtual world as the equivalent of a web page. As such, a VW hyperlink is simply a region on that map.

The default model of opensim-based virtual worlds already supports this concept of hyperlink, to some extent. When you teleport from one region to another via the map, chances are you are migrating your agent into a different opensim server. This migration is a glorified "agent transfer" that also exists, in rudimentary form, on the web when hypertext links are followed. The default model, however, imposes two very strong constraints on these hyperlinks:
# The entire map of regions is controlled by a central service known as the grid service, whose job is to provide a uniform view of the world to all of its regions.
# The only agents that can be transferred are those pertaining to users known to another central service, the user service; if the incoming user is not on that service's database, the agent transfer doesn't go through.

The hypergrid simply removes these two constraints.

First, it allows individual opensim instances to add "neighbors" to their local map, shifting the control of the map down from the grid server to individual opensim instances (although hyperlinks can also be served by grid servers if grid admins so wish). In doing so, the world becomes a lot more interesting and varied. The map that you see in one opensim instance may be completely different from the map that you see after you teleport via an hyperlink. As an opensim administrator, you are free to define what other opensims you want to see on your map.

Second, it allows the transfer of agents pertaining to foreigner users, i.e. users who are registered elsewhere. Instead of assuming one central user service, the hypergrid assumes an arbitrarily large number of such services distributed all over the world. As such, when agents are transferred among hypergrided opensims, a lot more information is passed about the corresponding user. That information includes the collection of servers that the transferring user needs.

=== Usage Scenarios ===

The following are some usage scenarios. There isn't a clear separation between these scenarios, there's a large overlap between them. This is also not an exhaustive list. The purpose of these descriptions is to give you some starting ideas for how to use the hypergrid in practice. Please feel free to add other interesting scenarios to this list.

{| {{Prettytable}}
|-
|
[[image:topoA.jpg|400px|left]]
|
'''Personal Worlds'''

This first scenario pertains to standalone opensims. Normally, standalones are completely disconnected from the internet. However, when run in hypergrid mode, standalones become network-able. As such, you can run your own world in your own computer, and link your world to whoever you want. For example, you can link to your friends' hypergrided opensims and to hypergrid gateways in open grids such as OSGrid.

The great thing about this scenario is that all of your assets are stored on your computer, and not on somebody else's server. You can back them up using ordinary backend tools. The not so great thing about this scenario is that all of your assets are stored on your computer! If your disk goes berserk, you loose them. (so make sure you make external backups regularly)

|-
|
[[image:topoB.jpg|400px|left]]
|
'''Communities'''

This second scenario is about communities, broadly construed. The idea here is that a group of people come together to support a small community grid, i.e. a common world where shared activities take place. But at the same time, the members of the community maintain their own standalone worlds. The standalones link to the community grid, and the community grid may link back to the individual members' worlds and other places of interest.

The members' identities are probably the identities they have on their standalones, and their assets are also probably stored there. The assets present in the community regions, however, are stored on the grid asset server.

|-
|
[[image:topoC.jpg|400px|left]]
|
'''Grid Public Regions'''

Walled-gardens are here to stay, and they serve many useful purposes. There is a hybrid mode for the hypergrid that some walled-garden grid operators may be interested in supporting. In this hybrid mode, most opensim instances on the grid run in normal, wall-garden mode, so no foreign visitors are allowed there - technically it is impossible to reach them. However, a few opensim instances on that grid can run in hypergrid mode, so that foreign visitors are allowed. This way, there is a gateway for grid-local users and arbitrary visitors to meet. This is also a good strategy for attracting new users to the grid, since random users are able to visit those gateway regions without having to sign up for an account upfront.

This hybrid mode is very similar to what happens on the web. For example, anyone can visit Facebook's public pages without having to sign up for a Facebook account. However, only Facebook users can go further inside.

|-
|
[[image:topoD.jpg|400px|left]]
|
'''Level Games'''

The normal version of OpenSim enforces a common map for all the regions on a grid. The hypergrid removes that constraint. As such, it becomes easy to design VW games where the world looks different depending of where the player is.

|-
|}

== Security Concerns ==

There is a wide-spread assumption that open grids such as OSGrid and new forms of grids such as the hypergrid are inherently insecure, and that it will be impossible to develop a "goods-based" economy on top of them; only walled-gardens can be secured. This is both true and false. While it is true with the current state of things, open grids, whatever their form, can be made as secure as the web. The first step towards that is to define exactly what the security threats are, and how they affect (or not) open and closed grids. So, let's spell them out, and face them head-on. This will help put our feet on the ground so that we start developing appropriate solutions.

=== Malicious Clients ===

==== CopyBots ====

Everyone knows about the infamous [http://en.wikipedia.org/wiki/CopyBot CopyBot]. Using libraries such as [http://www.libsecondlife.org/wiki/Main_Page LibSL] (now known as OpenMetaverse) it is possible to develop clients for opensim servers that do unorthodox things such as bypassing the permissions system to copy people's assets. Bots written by griefers can do lots of other nasty things.

Malicious bots are a problem for all opensim administrators, including walled-garden grids. They can be prevented, to a certain extent, by exo-technical solutions such as Terms of Service and real-world lawsuits. Technically speaking, the only way to keep intruders out is to run opensim inside a firewall, pretty much like all other pieces of client/server software out there. If that's an acceptable solution for your case, you should do it.

Unfortunately firewalls also keep the public out, and most opensim operators, even the ones running walled-garden grids, want to reach out to the public. In this case, opensim operators may develop additional technical obstacles for bots, similar to those we see on the Web. For example, make sure agents are being run by real people by giving them a human-challenge during the login/TP process, etc.

Every obstacle to malicious clients lowers the risk of an intruder attack. However keep this in mind: no matter how many obstacles one builds, a sufficiently skilled and motivated attacker will be able to overcome them to penetrate opensims connected to the public internet. This affects hypergrid nodes as much as walled-garden grids. In fact, it's more pervasive than that: it affects '''all''' servers (opensim, web, etc.) connected to the public internet. Fighting malicious intruders is a fact of a connected world. Fortunately, those attacks don't happen very often, or the Web would have been dead by now.

==== Web Clients ====

CopyBots are the most well-known bots for opensim-based virtual worlds, but these virtual worlds are also susceptible to attacks by regular web clients. With the current state of things, it is actually easier to copy assets with a web-based client than with a libsl-based one. The weakness is that asset servers are connected to the public internet, and the protocol for interacting with them is public.

OpenSim has some minimal guards in place to fence against these kinds of attacks. Specifically, when the inventory server receives a request for an item, it checks the session identifier of the requester. Web clients aren't logged in, so they are refused service. I don't want to expand much more on this, so not to make life easy for attackers, but let's just say that opensim has the necessary mechanisms in place to fence off web-based attackers.

=== Malicious Hosts ===

==== Actively Malicious Hosts ====

The new security threat introduced by openness, one that does not exist in closed grids, is the possibility of a user to visit a region that is running malicious code. In the current state of opensim, a malicious host can do serious damage to the user's assets. Let's see how.

Assume you have your assets in your hypergrided-standalone opensim, and you go visit another opensim that happens to be running malicious code. Here is a non-exhaustive list of vulnerabilities that you are exposed to:

* The host has your session id, so it can request your inventory items on your behalf and store copies in its local asset server. To add insult to injury, a malicious host could simply wipe out your inventory after having copied it.
* Even if the malicious host doesn't access your items by itself, every time you access items in your inventory while you are in that region, those items are cached in the region's local cache, and can be stored persistently by the malicious host.

Malicious hosts can do a lot more damage, but those two are enough to illustrate this new kind of vulnerability affecting open grids. Note that this affects all open grids, i.e. those where arbitrary people can plug-in their opensims, and not just the hypergrid.

Fortunately, there is a family of simple solutions to this problem that can be summarized as "protecting you from yourself." That proposal is described [[Hypergrid Inventory Access|here]].

==== Piracy ====

A second new security threat affecting open grids is one pertaining to commerce of virtual goods. Suppose you put something out for sale on your hypergrided opensim. A foreign user comes and buys it. What that really means is that that user will physically get a copy of the assets moved to his/her asset server, which is different from your asset server. The permissions will be whatever you define them to be, and using the regular VW client, that user can only do what you defined he/she should could do with the object, as usual. However, if the user has direct backend access to the asset and inventory servers, that person can simply modify the permissions on his/her copy. This is commonly known as '''piracy'''. (This is also a problem with programmers who have direct access to the cache that their client keeps; in this case, the only thing that needs to be done to enable piracy is for the user to actually see a texture/animation/in-world object. This does NOT allow scripts to be copied, though, since the script is only interpreted on the server and is never sent for interpretation by the client.)

This situation is the kernel of the belief that open grids are hopeless for a virtual-goods economy. DRM discussion aside, maybe they are hopeless. But then, everyone thought the web was hopeless for selling music, and look at the success of iTunes in spite of all the piracy that still exists out there. Who will be the equivalent of iTunes for virtual hair, skin and clothes?

== Hypergrid Implementation ==

=== Hyperlinks and Agent Transfers ===

When you establish a link between your opensim and another, a message is sent out to that other opensim requesting information about it; the required information includes the network information of that opensim host, and the coordinates of its first region on its local grid in the form of a region handle. For example, suppose you are linking node X.com:9000, placing it in your local map at 900, 900. That opensim runs one or more regions that likely are not in 900, 900 on their own map; suppose the first region of that opensim is at 1100, 1100. From your point of view, it doesn't matter what those other coordinates are, and you don't need to know -- that's the key to being able to decentralize the "world" as given by a 2D map; you want to place it in your map at 900, 900. The "true" position of that simulator only matters for the LL viewer, when there are teleports between your world and that other opensim. This mapping between coordinate systems is the essence of hyperlinks for opensim; it's one simple but critical thing that the hypergrid implementation does. The mapping happens on the TeleportFinish event; instead of sending the local coordinates to the viewer, the hypergrid teleport wrapper sends the remote coordinates.

When an agent teleports through that hyperlink the following happens. First, before InformRegionOfChildAgent, the local opensim notifies the remote opensim of this foreign user via the "expect_hg_user" method. That message sends along the addresses of all the servers that this user uses, i.e. user, inventory and asset servers. The remote opensim places an entry for that user in its local user profile cache but not in its user database; the foreign user information is non-persistent. After that, the teleport process is exactly the same as the normal teleport process; the only difference is that the region handles are switched between the remote region's hyperlink position on the local grid and its actual position on its grid.

In summary, the two new concepts introduced by the hypergrid are the concept of an hyperlink and the concept of a "local user" vs. "foreign user".

=== Inventory Access ===

Inventory access from abroad is done by wrapping the existing scene-inventory interactions with additional code that gets or posts inventory assets from/to the user's asset server. When inventory is accessed, the hypergrid wrapper checks if the user is foreign and, if she is, the wrapper simply brings the necessary assets from the user's asset server to the local asset cache and server; from then on, the wrapper passes the control to the existing inventory access functions. When something is added to inventory, the hypergrid wrapper is notified via an event, and posts the assets to the user's asset server. A cache of the exchanged item identifiers is maintained so that they aren't brought back over and over again.

The result is that hypergrided opensim instances end up interacting with several asset servers, instead of just one. That interaction is implemented in a straightforward manner by instantiating several GridAssetClient objects, instead of just one.

=== The Hypergrid Namespace ===

Currently, the hypergrid is implemented outside of the OpenSim namespace, so that there is complete separation between what already exists and this new behavior. It has its own namespace, HyperGrid. In it, there are 4 sub-namespaces that follow directly the software architecture of OpenSim, namely:

* '''HyperGrid.Framework''' extends OpenSim.Framework in the following manner:
** HGUserProfileData extends UserProfileData by introducing information about the user's "home", namely the home address, port and remoting port. The user's home is not that user's user service; it's the opensim that the user has defined to be her home. This is necessary for supporting the home jump (Ctrl-Shift-H).
** HGNetworkServersInfo follows the spirit of NetworkServersInfo, although it neither extends it nor uses it. For now, it's a utility class whose two main functions are to convert domain names of servers to IP addresses, and to uniformly provide the answer to the question bool IsLocalUser(...).

* '''HyperGrid.Environment''' extends OpenSim.Region.Environment.Scenes in the following manner:
** HGSceneCommunicationService extends SceneCommunicationService, overriding RequestTeleportToLocation. There are two very small but critical changes to the base method: (a) on the TeleportFinish event, we switch the region handles when the destination region is an hyperlink; (b) the connections at the end are always closed for hyperlink TPs.
** HGScene extends Scene, overriding TeleportClientHome(...). The only change to the base method is to stay away from the user server, for now, because the user service is still not completely wrapped up for foreign users. Once the user service is properly wrapped up, this class will become unnecessary.
** HGScene.Inventory is a partial class of HGScene, just like what happens in the OpenSim framework. This part of HGScene overrides some inventory-scene interaction methods, so that assets are fetched/posted from/to the user's asset server. Once that extra fetching/posting is done, these methods simply pass the ball to the base methods.
** HGAssetMapper: this is a new class specific to the hypergrid that manages the fetching and posting of assets between foreign regions where the user is and the user's asset server.

* '''HyperGrid.Protocol''' is a mashup of OpenSim.Region.Communications.*. This is the place where most of the hypergrid extension lies. One of the reasons for this is that the hypergrid communications part is doing one additional thing: it is making standalones network-able.
** HGCommunicationsStandalone extends CommuniationsLocal. Just as its base, it is a hub for the several network services available in standalone mode. The main difference is that those services are extensions of what's in OpenSim.
** HGCommunicationsGridMode extends CommunicationsManager directly. Again, it's a hub for the network services available in grid mode, those services being extensions of OpenSim.
** The cluster HGGridServices (superclass), HGGridServicesStandalone and HGGridServicesGridMode (subclasses) implements the OpenSim interfaces IGridServices and IInterRegionCommunications. The 2 subclasses are wrappers for LocalBackEndServices and OGS1GridServices, respectively. There is one common pattern throughout these classes: check if the region to talk to is an hyperlink; if it's not, simply delegate the work to LocalBackEndServices/OGS1GridServices; if it is, push the work to the base class HGGridServices. HGGridServices, in turn, does the management of hyperlink regions, and defines two additional pieces of inter-region protocol:
*** region_uuid: for linking regions
*** expect_hg_user: similar to the existing expect_user interface, but with a lot more information about the user being passed around, namely all the user's servers (inventory, asset, user, home, etc.)
** HGInventoryService extends LocalInventoryService and implements ISecureInventoryService. This class is the most obvious mashup of the pack, mixing local service access for standalone users and remote inventory access for when users are out and about. Right now, there is a fair amount of selective copy-and-paste, to stay away from the ugliness coming from OGS1InventoryService and OGS1SecureInventoryService. HGInventoryService is always a ISecureInventoryService. Its methods all follow the same pattern: check if the user is a local standalone user; if it is, pass the work to the base method (in LocalInventoryService); if it's not perform secure remote access.
** HGUserServices wraps OSG1UserServices, but it's not functional yet.

* '''HyperGrid.Modules''' is a collection of 3 region modules:
** HGWorldMapModule extends WorldMapModule. It reuses almost everything from the base class. The only small change is in RequestMapBlocks, where it tries to send Offline mapblocks to the client.
** HGStandaloneInventoryService and HGStandaloneAssetService do what their names say. They are region modules that allow access to inventory and assets for standalones, when the standalone user is out and about. In spirit, there is a lot in common between these modules and the REST inventory/asset plugin. Unfortunately, that plugin could not be used because it defines a completely different interface than that used by existing inventory and asset servers, and the access for the hypergrid must use a consistent interface.

=== Class Diagram ===

[[image:HypergridImplementation.jpg|600px|center|(Click on the image to enlarge)]]

== Installing and Running Hypergrid ==

=== Installing ===

# Checkout OpenSim, prebuild and build as normal.
# Make the following changes to your OpenSim.ini:
#* The map: '''WorldMapModule = "HGWorldMap" ''' If you didn't have this setting in your original OpenSim.ini, make sure you place it under the [Startup] section.
#* If you're running your opensim in grid mode with the UGAIM servers on other machines, you're done. If you're running in standalone and you want it to be network-able, or if you have your grid on loopback (127.0.0.1) change all the [Network] server addresses to <nowiki>"http://<external_host_name>:<http_port>"</nowiki>. See below.
# Run opensim like this: <nowiki>[mono] OpenSim.exe -hypergrid=true</nowiki>. To make sure the hypergrid is running type this on your console: '''link-region'''. If you don't hear anything back, the hypergrid is not properly installed.

Here is an example of the Network settings for a standalone:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:9300
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:9300
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:9300
inventory_server_url = http://example.com:9300

Here is an example of the Network settings for a grided opensim:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:8001
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:8002
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:8003
inventory_server_url = http://example.com:8004

'''Important Note'''

Make sure you have a 'home' set. If your home region doesn't exist, the hyperlink TPs may not work. To set your home, go to one of your local regions and "Set Home" from the viewer.

=== Linking regions ===

On the console, type for example:

link-region <Xloc> <Yloc> osl2.nac.uci.edu 9006 OSGrid Gateway

* Use Xloc and Yloc that make sense to your world, i.e. close to your regions, but not adjacent.
* replace osl2.nac.uci.edu and 9006 with the domain name / ip address and the port of the region you want to link to

'''Important Note'''

Due to a viewer [https://jira.secondlife.com/browse/SVC-2941 bug], you can only TP between regions that are no more than 4096 cells apart in any dimension. What this means in practice is that if you want to link to OSGrid, you must have your own regions reachable from the (10,000; 10,000) point on the map, which is where OSGrid is centered. Place your regions somewhere in the 8,000s or the 12,000s.

== Public Hypergrid Nodes ==

The following is a list of hypergrid-ready nodes that you can use for testing your installation and for linking your world. Please add your public node here if you wish to help build a web of opensims!

For the time being, and until the security concerns described above are addressed, we advise you to be careful about who you link to.

* '''osl2.nac.uci.edu 9006'''
The "UCI Welcome" region connected to OSGrid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine. You can link to it as a way to link to OSGrid.

* '''ucigrid02.nacs.uci.edu 9000'''
A region in the UCI Grid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine.

* '''grid.cyberlandia.net 9000'''
The "Cyberlandia Gw" region connected to OSGrid. Search on Osgrid map "cyberlandia grid" Is link to cyberlandia Italian Opensim grid. You can link to it as a way to link to Cyberlandia.

* '''hypergrid.cyberlandia.net 9300'''
The "Osgrid Gw" region connected to Cyberlandia grid http://www.cyberlandia.net. Search on map "Osgrid grid" You can link to it as a way to link to OSGrid.

* '''joomla-italia.net 9000
The "SNI City" region connected to SNI (Social Network Italia) grid http://www.opensim-italia.net. This grid is connected with Osgrid,Collateral World,Francogrid and Darwin

* '''collateral.opensim-italia.net 9000
The "Collateral" region connected to Collateral World Grid http://collateral.opensim-italia.net. This grid is connected with Social Network Italia, Osgrid and Francogrid '''[This grid is temporarily offline for maintenance]'''

* '''88.191.79.199 9050'''
Francogrid node, connected to "City", behind the welcome land of Francogrid "Orion"

* '''94.23.8.158 9999'''
Le Monde de Darwin node, The Lost of Darwin http://www.LeMondedeDarwin.com
----
[[Image:hypergrid.jpg]]
----

* '''grid.k-grid.com 9000'''
K-grid, [http://k-grid.com the Kool grid for the Kool KidZ] . Feel free to visit us. The main Gateway is located at 3700,3700 so take that in account before any HyperJump

* '''metropolis.hypergrid.org 9000'''
The Region "Center-World" (at 1000:1000) connected to the METROPOLIS-Grid http://metropolis.hypergrid.org . German Grid with a lot of free Content and free SIM-hosting. Connected via HG to the most of the Grids listed here.

* '''ascent.bluewallgroup.com 9910'''
This region is in a good proximity @ (6000,6000) for intermediate jumps to OSGrid from grids in the (2000,2000) range, or any region within 4096 units. [[Image:Hypernaut 001.png|150px|none|thumb|Get your Hypernaut here :)]]

* '''sim.thestudyofracialism.org 9000'''
TSOR1 is a stand-alone 2-region sim (at 8000,8000). It connects via HG to most of the other sites listed here. Although currently sparse, the sim is eventually intended for an SL discussion-group's migration from SL to OS.

* '''http://myopengrid.com 9000'''
Myopengrid is connected to osl2.nac.uci.edu "Osgrid Gateway" our regions are at (7000,7000).

* '''sim-linuxmain.org 9300'''
Cuon-Grid is a little grid and has some Main Sims with linux themes, Regions are at (10000,10000),server are in Germany.

Hypergrid

2008-11-26T09:32:48Z

Carlosroundel: /* Public Hypergrid Nodes */

==The OpenSim Hypergrid==

=== What is the hypergrid? ===


The hypergrid is an extension to opensim that allows you to link your opensim to other opensims on the internet, and that supports seamless agent transfers among those opensims. It can be used both in standalone mode and in grid mode. The hypergrid is effectively supporting the emergence of a Web of virtual worlds.

The basic idea for the hypergrid is that region/grid administrations can place hyperlinks on their map to hypergrided regions run by others. Once those hyperlinks are established, users interact with those regions in exactly the same way as they interact with local regions. Specifically, users can choose to teleport there. Once the user reaches the region behind the hyperlink, she is automatically interacting with a different virtual world without having to logout from the world where she came from, and while still having access to her inventory.

The hypergrid started as a GForge project, but it is now included in the standard distribution of OpenSim. To run your OpenSim instance in hypergrid mode, please see [[Hypergrid#Installing_and_Running_Hypergrid|Installing and Running]].

=== Virtual World Hyperlinks ===
[[image:hghyperlink.jpg|250px|thumb|A Virtual World Hyperlink]]

We're all familiar with hypertext links on the Web. But what is a virtual world hyperlink?

In the hypergrid model, we consider the 2D map of the virtual world as the equivalent of a web page. As such, a VW hyperlink is simply a region on that map.

The default model of opensim-based virtual worlds already supports this concept of hyperlink, to some extent. When you teleport from one region to another via the map, chances are you are migrating your agent into a different opensim server. This migration is a glorified "agent transfer" that also exists, in rudimentary form, on the web when hypertext links are followed. The default model, however, imposes two very strong constraints on these hyperlinks:
# The entire map of regions is controlled by a central service known as the grid service, whose job is to provide a uniform view of the world to all of its regions.
# The only agents that can be transferred are those pertaining to users known to another central service, the user service; if the incoming user is not on that service's database, the agent transfer doesn't go through.

The hypergrid simply removes these two constraints.

First, it allows individual opensim instances to add "neighbors" to their local map, shifting the control of the map down from the grid server to individual opensim instances (although hyperlinks can also be served by grid servers if grid admins so wish). In doing so, the world becomes a lot more interesting and varied. The map that you see in one opensim instance may be completely different from the map that you see after you teleport via an hyperlink. As an opensim administrator, you are free to define what other opensims you want to see on your map.

Second, it allows the transfer of agents pertaining to foreigner users, i.e. users who are registered elsewhere. Instead of assuming one central user service, the hypergrid assumes an arbitrarily large number of such services distributed all over the world. As such, when agents are transferred among hypergrided opensims, a lot more information is passed about the corresponding user. That information includes the collection of servers that the transferring user needs.

=== Usage Scenarios ===

The following are some usage scenarios. There isn't a clear separation between these scenarios, there's a large overlap between them. This is also not an exhaustive list. The purpose of these descriptions is to give you some starting ideas for how to use the hypergrid in practice. Please feel free to add other interesting scenarios to this list.

{| {{Prettytable}}
|-
|
[[image:topoA.jpg|400px|left]]
|
'''Personal Worlds'''

This first scenario pertains to standalone opensims. Normally, standalones are completely disconnected from the internet. However, when run in hypergrid mode, standalones become network-able. As such, you can run your own world in your own computer, and link your world to whoever you want. For example, you can link to your friends' hypergrided opensims and to hypergrid gateways in open grids such as OSGrid.

The great thing about this scenario is that all of your assets are stored on your computer, and not on somebody else's server. You can back them up using ordinary backend tools. The not so great thing about this scenario is that all of your assets are stored on your computer! If your disk goes berserk, you loose them. (so make sure you make external backups regularly)

|-
|
[[image:topoB.jpg|400px|left]]
|
'''Communities'''

This second scenario is about communities, broadly construed. The idea here is that a group of people come together to support a small community grid, i.e. a common world where shared activities take place. But at the same time, the members of the community maintain their own standalone worlds. The standalones link to the community grid, and the community grid may link back to the individual members' worlds and other places of interest.

The members' identities are probably the identities they have on their standalones, and their assets are also probably stored there. The assets present in the community regions, however, are stored on the grid asset server.

|-
|
[[image:topoC.jpg|400px|left]]
|
'''Grid Public Regions'''

Walled-gardens are here to stay, and they serve many useful purposes. There is a hybrid mode for the hypergrid that some walled-garden grid operators may be interested in supporting. In this hybrid mode, most opensim instances on the grid run in normal, wall-garden mode, so no foreign visitors are allowed there - technically it is impossible to reach them. However, a few opensim instances on that grid can run in hypergrid mode, so that foreign visitors are allowed. This way, there is a gateway for grid-local users and arbitrary visitors to meet. This is also a good strategy for attracting new users to the grid, since random users are able to visit those gateway regions without having to sign up for an account upfront.

This hybrid mode is very similar to what happens on the web. For example, anyone can visit Facebook's public pages without having to sign up for a Facebook account. However, only Facebook users can go further inside.

|-
|
[[image:topoD.jpg|400px|left]]
|
'''Level Games'''

The normal version of OpenSim enforces a common map for all the regions on a grid. The hypergrid removes that constraint. As such, it becomes easy to design VW games where the world looks different depending of where the player is.

|-
|}

== Security Concerns ==

There is a wide-spread assumption that open grids such as OSGrid and new forms of grids such as the hypergrid are inherently insecure, and that it will be impossible to develop a "goods-based" economy on top of them; only walled-gardens can be secured. This is both true and false. While it is true with the current state of things, open grids, whatever their form, can be made as secure as the web. The first step towards that is to define exactly what the security threats are, and how they affect (or not) open and closed grids. So, let's spell them out, and face them head-on. This will help put our feet on the ground so that we start developing appropriate solutions.

=== Malicious Clients ===

==== CopyBots ====

Everyone knows about the infamous [http://en.wikipedia.org/wiki/CopyBot CopyBot]. Using libraries such as [http://www.libsecondlife.org/wiki/Main_Page LibSL] (now known as OpenMetaverse) it is possible to develop clients for opensim servers that do unorthodox things such as bypassing the permissions system to copy people's assets. Bots written by griefers can do lots of other nasty things.

Malicious bots are a problem for all opensim administrators, including walled-garden grids. They can be prevented, to a certain extent, by exo-technical solutions such as Terms of Service and real-world lawsuits. Technically speaking, the only way to keep intruders out is to run opensim inside a firewall, pretty much like all other pieces of client/server software out there. If that's an acceptable solution for your case, you should do it.

Unfortunately firewalls also keep the public out, and most opensim operators, even the ones running walled-garden grids, want to reach out to the public. In this case, opensim operators may develop additional technical obstacles for bots, similar to those we see on the Web. For example, make sure agents are being run by real people by giving them a human-challenge during the login/TP process, etc.

Every obstacle to malicious clients lowers the risk of an intruder attack. However keep this in mind: no matter how many obstacles one builds, a sufficiently skilled and motivated attacker will be able to overcome them to penetrate opensims connected to the public internet. This affects hypergrid nodes as much as walled-garden grids. In fact, it's more pervasive than that: it affects '''all''' servers (opensim, web, etc.) connected to the public internet. Fighting malicious intruders is a fact of a connected world. Fortunately, those attacks don't happen very often, or the Web would have been dead by now.

==== Web Clients ====

CopyBots are the most well-known bots for opensim-based virtual worlds, but these virtual worlds are also susceptible to attacks by regular web clients. With the current state of things, it is actually easier to copy assets with a web-based client than with a libsl-based one. The weakness is that asset servers are connected to the public internet, and the protocol for interacting with them is public.

OpenSim has some minimal guards in place to fence against these kinds of attacks. Specifically, when the inventory server receives a request for an item, it checks the session identifier of the requester. Web clients aren't logged in, so they are refused service. I don't want to expand much more on this, so not to make life easy for attackers, but let's just say that opensim has the necessary mechanisms in place to fence off web-based attackers.

=== Malicious Hosts ===

==== Actively Malicious Hosts ====

The new security threat introduced by openness, one that does not exist in closed grids, is the possibility of a user to visit a region that is running malicious code. In the current state of opensim, a malicious host can do serious damage to the user's assets. Let's see how.

Assume you have your assets in your hypergrided-standalone opensim, and you go visit another opensim that happens to be running malicious code. Here is a non-exhaustive list of vulnerabilities that you are exposed to:

* The host has your session id, so it can request your inventory items on your behalf and store copies in its local asset server. To add insult to injury, a malicious host could simply wipe out your inventory after having copied it.
* Even if the malicious host doesn't access your items by itself, every time you access items in your inventory while you are in that region, those items are cached in the region's local cache, and can be stored persistently by the malicious host.

Malicious hosts can do a lot more damage, but those two are enough to illustrate this new kind of vulnerability affecting open grids. Note that this affects all open grids, i.e. those where arbitrary people can plug-in their opensims, and not just the hypergrid.

Fortunately, there is a family of simple solutions to this problem that can be summarized as "protecting you from yourself." That proposal is described [[Hypergrid Inventory Access|here]].

==== Piracy ====

A second new security threat affecting open grids is one pertaining to commerce of virtual goods. Suppose you put something out for sale on your hypergrided opensim. A foreign user comes and buys it. What that really means is that that user will physically get a copy of the assets moved to his/her asset server, which is different from your asset server. The permissions will be whatever you define them to be, and using the regular VW client, that user can only do what you defined he/she should could do with the object, as usual. However, if the user has direct backend access to the asset and inventory servers, that person can simply modify the permissions on his/her copy. This is commonly known as '''piracy'''.

This situation is the kernel of the belief that open grids are hopeless for a virtual-goods economy. DRM discussion aside, maybe they are hopeless. But then, everyone thought the web was hopeless for selling music, and look at the success of iTunes in spite of all the piracy that still exists out there. Who will be the equivalent of iTunes for virtual hair, skin and clothes?

== Hypergrid Implementation ==

=== Hyperlinks and Agent Transfers ===

When you establish a link between your opensim and another, a message is sent out to that other opensim requesting information about it; the required information includes the network information of that opensim host, and the coordinates of its first region on its local grid in the form of a region handle. For example, suppose you are linking node X.com:9000, placing it in your local map at 900, 900. That opensim runs one or more regions that likely are not in 900, 900 on their own map; suppose the first region of that opensim is at 1100, 1100. From your point of view, it doesn't matter what those other coordinates are, and you don't need to know -- that's the key to being able to decentralize the "world" as given by a 2D map; you want to place it in your map at 900, 900. The "true" position of that simulator only matters for the LL viewer, when there are teleports between your world and that other opensim. This mapping between coordinate systems is the essence of hyperlinks for opensim; it's one simple but critical thing that the hypergrid implementation does. The mapping happens on the TeleportFinish event; instead of sending the local coordinates to the viewer, the hypergrid teleport wrapper sends the remote coordinates.

When an agent teleports through that hyperlink the following happens. First, before InformRegionOfChildAgent, the local opensim notifies the remote opensim of this foreign user via the "expect_hg_user" method. That message sends along the addresses of all the servers that this user uses, i.e. user, inventory and asset servers. The remote opensim places an entry for that user in its local user profile cache but not in its user database; the foreign user information is non-persistent. After that, the teleport process is exactly the same as the normal teleport process; the only difference is that the region handles are switched between the remote region's hyperlink position on the local grid and its actual position on its grid.

In summary, the two new concepts introduced by the hypergrid are the concept of an hyperlink and the concept of a "local user" vs. "foreign user".

=== Inventory Access ===

Inventory access from abroad is done by wrapping the existing scene-inventory interactions with additional code that gets or posts inventory assets from/to the user's asset server. When inventory is accessed, the hypergrid wrapper checks if the user is foreign and, if she is, the wrapper simply brings the necessary assets from the user's asset server to the local asset cache and server; from then on, the wrapper passes the control to the existing inventory access functions. When something is added to inventory, the hypergrid wrapper is notified via an event, and posts the assets to the user's asset server. A cache of the exchanged item identifiers is maintained so that they aren't brought back over and over again.

The result is that hypergrided opensim instances end up interacting with several asset servers, instead of just one. That interaction is implemented in a straightforward manner by instantiating several GridAssetClient objects, instead of just one.

=== The Hypergrid Namespace ===

Currently, the hypergrid is implemented outside of the OpenSim namespace, so that there is complete separation between what already exists and this new behavior. It has its own namespace, HyperGrid. In it, there are 4 sub-namespaces that follow directly the software architecture of OpenSim, namely:

* '''HyperGrid.Framework''' extends OpenSim.Framework in the following manner:
** HGUserProfileData extends UserProfileData by introducing information about the user's "home", namely the home address, port and remoting port. The user's home is not that user's user service; it's the opensim that the user has defined to be her home. This is necessary for supporting the home jump (Ctrl-Shift-H).
** HGNetworkServersInfo follows the spirit of NetworkServersInfo, although it neither extends it nor uses it. For now, it's a utility class whose two main functions are to convert domain names of servers to IP addresses, and to uniformly provide the answer to the question bool IsLocalUser(...).

* '''HyperGrid.Environment''' extends OpenSim.Region.Environment.Scenes in the following manner:
** HGSceneCommunicationService extends SceneCommunicationService, overriding RequestTeleportToLocation. There are two very small but critical changes to the base method: (a) on the TeleportFinish event, we switch the region handles when the destination region is an hyperlink; (b) the connections at the end are always closed for hyperlink TPs.
** HGScene extends Scene, overriding TeleportClientHome(...). The only change to the base method is to stay away from the user server, for now, because the user service is still not completely wrapped up for foreign users. Once the user service is properly wrapped up, this class will become unnecessary.
** HGScene.Inventory is a partial class of HGScene, just like what happens in the OpenSim framework. This part of HGScene overrides some inventory-scene interaction methods, so that assets are fetched/posted from/to the user's asset server. Once that extra fetching/posting is done, these methods simply pass the ball to the base methods.
** HGAssetMapper: this is a new class specific to the hypergrid that manages the fetching and posting of assets between foreign regions where the user is and the user's asset server.

* '''HyperGrid.Protocol''' is a mashup of OpenSim.Region.Communications.*. This is the place where most of the hypergrid extension lies. One of the reasons for this is that the hypergrid communications part is doing one additional thing: it is making standalones network-able.
** HGCommunicationsStandalone extends CommuniationsLocal. Just as its base, it is a hub for the several network services available in standalone mode. The main difference is that those services are extensions of what's in OpenSim.
** HGCommunicationsGridMode extends CommunicationsManager directly. Again, it's a hub for the network services available in grid mode, those services being extensions of OpenSim.
** The cluster HGGridServices (superclass), HGGridServicesStandalone and HGGridServicesGridMode (subclasses) implements the OpenSim interfaces IGridServices and IInterRegionCommunications. The 2 subclasses are wrappers for LocalBackEndServices and OGS1GridServices, respectively. There is one common pattern throughout these classes: check if the region to talk to is an hyperlink; if it's not, simply delegate the work to LocalBackEndServices/OGS1GridServices; if it is, push the work to the base class HGGridServices. HGGridServices, in turn, does the management of hyperlink regions, and defines two additional pieces of inter-region protocol:
*** region_uuid: for linking regions
*** expect_hg_user: similar to the existing expect_user interface, but with a lot more information about the user being passed around, namely all the user's servers (inventory, asset, user, home, etc.)
** HGInventoryService extends LocalInventoryService and implements ISecureInventoryService. This class is the most obvious mashup of the pack, mixing local service access for standalone users and remote inventory access for when users are out and about. Right now, there is a fair amount of selective copy-and-paste, to stay away from the ugliness coming from OGS1InventoryService and OGS1SecureInventoryService. HGInventoryService is always a ISecureInventoryService. Its methods all follow the same pattern: check if the user is a local standalone user; if it is, pass the work to the base method (in LocalInventoryService); if it's not perform secure remote access.
** HGUserServices wraps OSG1UserServices, but it's not functional yet.

* '''HyperGrid.Modules''' is a collection of 3 region modules:
** HGWorldMapModule extends WorldMapModule. It reuses almost everything from the base class. The only small change is in RequestMapBlocks, where it tries to send Offline mapblocks to the client.
** HGStandaloneInventoryService and HGStandaloneAssetService do what their names say. They are region modules that allow access to inventory and assets for standalones, when the standalone user is out and about. In spirit, there is a lot in common between these modules and the REST inventory/asset plugin. Unfortunately, that plugin could not be used because it defines a completely different interface than that used by existing inventory and asset servers, and the access for the hypergrid must use a consistent interface.

=== Class Diagram ===

[[image:HypergridImplementation.jpg|600px|center|(Click on the image to enlarge)]]

== Installing and Running Hypergrid ==

=== Installing ===

# Checkout OpenSim, prebuild and build as normal.
# Make the following changes to your OpenSim.ini:
#* The map: '''WorldMapModule = "HGWorldMap" ''' If you didn't have this setting in your original OpenSim.ini, make sure you place it under the [Startup] section.
#* If you're running your opensim in grid mode with the UGAIM servers on other machines, you're done. If you're running in standalone and you want it to be network-able, or if you have your grid on loopback (127.0.0.1) change all the [Network] server addresses to <nowiki>"http://<external_host_name>:<http_port>"</nowiki>. See below.
# Run opensim like this: <nowiki>[mono] OpenSim.exe -hypergrid=true</nowiki>. To make sure the hypergrid is running type this on your console: '''link-region'''. If you don't hear anything back, the hypergrid is not properly installed.

Here is an example of the Network settings for a standalone:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:9300
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:9300
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:9300
inventory_server_url = http://example.com:9300

Here is an example of the Network settings for a grided opensim:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:8001
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:8002
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:8003
inventory_server_url = http://example.com:8004

'''Important Note'''

Make sure you have a 'home' set. If your home region doesn't exist, the hyperlink TPs may not work. To set your home, go to one of your local regions and "Set Home" from the viewer.

=== Linking regions ===

On the console, type for example:

link-region <Xloc> <Yloc> osl2.nac.uci.edu 9006 OSGrid Gateway

* Use Xloc and Yloc that make sense to your world, i.e. close to your regions, but not adjacent.
* replace osl2.nac.uci.edu and 9006 with the domain name / ip address and the port of the region you want to link to

'''Important Note'''

Due to a viewer [https://jira.secondlife.com/browse/SVC-2941 bug], you can only TP between regions that are no more than 4096 cells apart in any dimension. What this means in practice is that if you want to link to OSGrid, you must have your own regions reachable from the (10,000; 10,000) point on the map, which is where OSGrid is centered. Place your regions somewhere in the 8,000s or the 12,000s.

== Public Hypergrid Nodes ==

The following is a list of hypergrid-ready nodes that you can use for testing your installation and for linking your world. Please add your public node here if you wish to help build a web of opensims!

For the time being, and until the security concerns described above are addressed, we advise you to be careful about who you link to.

* '''osl2.nac.uci.edu 9006'''
The "UCI Welcome" region connected to OSGrid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine. You can link to it as a way to link to OSGrid.

* '''ucigrid02.nacs.uci.edu 9000'''
A region in the UCI Grid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine.

* '''hypergrid.cyberlandia.net 9000'''
The "Cyberlandia Gw" region connected to OSGrid. Search on map "cyberlandia grid" Is link to cyberlandia Italian Opensim grid. You can link to it as a way to link to Cyberlandia.

* '''hypergrid.cyberlandia.net 9300'''
The "Osgrid Gw" region connected to Cyberlandia grid http://www.cyberlandia.net. Search on map "Osgrid grid" You can link to it as a way to link to OSGrid.

Hypergrid

2008-11-26T09:31:22Z

Carlosroundel: /* Public Hypergrid Nodes */

==The OpenSim Hypergrid==

=== What is the hypergrid? ===


The hypergrid is an extension to opensim that allows you to link your opensim to other opensims on the internet, and that supports seamless agent transfers among those opensims. It can be used both in standalone mode and in grid mode. The hypergrid is effectively supporting the emergence of a Web of virtual worlds.

The basic idea for the hypergrid is that region/grid administrations can place hyperlinks on their map to hypergrided regions run by others. Once those hyperlinks are established, users interact with those regions in exactly the same way as they interact with local regions. Specifically, users can choose to teleport there. Once the user reaches the region behind the hyperlink, she is automatically interacting with a different virtual world without having to logout from the world where she came from, and while still having access to her inventory.

The hypergrid started as a GForge project, but it is now included in the standard distribution of OpenSim. To run your OpenSim instance in hypergrid mode, please see [[Hypergrid#Installing_and_Running_Hypergrid|Installing and Running]].

=== Virtual World Hyperlinks ===
[[image:hghyperlink.jpg|250px|thumb|A Virtual World Hyperlink]]

We're all familiar with hypertext links on the Web. But what is a virtual world hyperlink?

In the hypergrid model, we consider the 2D map of the virtual world as the equivalent of a web page. As such, a VW hyperlink is simply a region on that map.

The default model of opensim-based virtual worlds already supports this concept of hyperlink, to some extent. When you teleport from one region to another via the map, chances are you are migrating your agent into a different opensim server. This migration is a glorified "agent transfer" that also exists, in rudimentary form, on the web when hypertext links are followed. The default model, however, imposes two very strong constraints on these hyperlinks:
# The entire map of regions is controlled by a central service known as the grid service, whose job is to provide a uniform view of the world to all of its regions.
# The only agents that can be transferred are those pertaining to users known to another central service, the user service; if the incoming user is not on that service's database, the agent transfer doesn't go through.

The hypergrid simply removes these two constraints.

First, it allows individual opensim instances to add "neighbors" to their local map, shifting the control of the map down from the grid server to individual opensim instances (although hyperlinks can also be served by grid servers if grid admins so wish). In doing so, the world becomes a lot more interesting and varied. The map that you see in one opensim instance may be completely different from the map that you see after you teleport via an hyperlink. As an opensim administrator, you are free to define what other opensims you want to see on your map.

Second, it allows the transfer of agents pertaining to foreigner users, i.e. users who are registered elsewhere. Instead of assuming one central user service, the hypergrid assumes an arbitrarily large number of such services distributed all over the world. As such, when agents are transferred among hypergrided opensims, a lot more information is passed about the corresponding user. That information includes the collection of servers that the transferring user needs.

=== Usage Scenarios ===

The following are some usage scenarios. There isn't a clear separation between these scenarios, there's a large overlap between them. This is also not an exhaustive list. The purpose of these descriptions is to give you some starting ideas for how to use the hypergrid in practice. Please feel free to add other interesting scenarios to this list.

{| {{Prettytable}}
|-
|
[[image:topoA.jpg|400px|left]]
|
'''Personal Worlds'''

This first scenario pertains to standalone opensims. Normally, standalones are completely disconnected from the internet. However, when run in hypergrid mode, standalones become network-able. As such, you can run your own world in your own computer, and link your world to whoever you want. For example, you can link to your friends' hypergrided opensims and to hypergrid gateways in open grids such as OSGrid.

The great thing about this scenario is that all of your assets are stored on your computer, and not on somebody else's server. You can back them up using ordinary backend tools. The not so great thing about this scenario is that all of your assets are stored on your computer! If your disk goes berserk, you loose them. (so make sure you make external backups regularly)

|-
|
[[image:topoB.jpg|400px|left]]
|
'''Communities'''

This second scenario is about communities, broadly construed. The idea here is that a group of people come together to support a small community grid, i.e. a common world where shared activities take place. But at the same time, the members of the community maintain their own standalone worlds. The standalones link to the community grid, and the community grid may link back to the individual members' worlds and other places of interest.

The members' identities are probably the identities they have on their standalones, and their assets are also probably stored there. The assets present in the community regions, however, are stored on the grid asset server.

|-
|
[[image:topoC.jpg|400px|left]]
|
'''Grid Public Regions'''

Walled-gardens are here to stay, and they serve many useful purposes. There is a hybrid mode for the hypergrid that some walled-garden grid operators may be interested in supporting. In this hybrid mode, most opensim instances on the grid run in normal, wall-garden mode, so no foreign visitors are allowed there - technically it is impossible to reach them. However, a few opensim instances on that grid can run in hypergrid mode, so that foreign visitors are allowed. This way, there is a gateway for grid-local users and arbitrary visitors to meet. This is also a good strategy for attracting new users to the grid, since random users are able to visit those gateway regions without having to sign up for an account upfront.

This hybrid mode is very similar to what happens on the web. For example, anyone can visit Facebook's public pages without having to sign up for a Facebook account. However, only Facebook users can go further inside.

|-
|
[[image:topoD.jpg|400px|left]]
|
'''Level Games'''

The normal version of OpenSim enforces a common map for all the regions on a grid. The hypergrid removes that constraint. As such, it becomes easy to design VW games where the world looks different depending of where the player is.

|-
|}

== Security Concerns ==

There is a wide-spread assumption that open grids such as OSGrid and new forms of grids such as the hypergrid are inherently insecure, and that it will be impossible to develop a "goods-based" economy on top of them; only walled-gardens can be secured. This is both true and false. While it is true with the current state of things, open grids, whatever their form, can be made as secure as the web. The first step towards that is to define exactly what the security threats are, and how they affect (or not) open and closed grids. So, let's spell them out, and face them head-on. This will help put our feet on the ground so that we start developing appropriate solutions.

=== Malicious Clients ===

==== CopyBots ====

Everyone knows about the infamous [http://en.wikipedia.org/wiki/CopyBot CopyBot]. Using libraries such as [http://www.libsecondlife.org/wiki/Main_Page LibSL] (now known as OpenMetaverse) it is possible to develop clients for opensim servers that do unorthodox things such as bypassing the permissions system to copy people's assets. Bots written by griefers can do lots of other nasty things.

Malicious bots are a problem for all opensim administrators, including walled-garden grids. They can be prevented, to a certain extent, by exo-technical solutions such as Terms of Service and real-world lawsuits. Technically speaking, the only way to keep intruders out is to run opensim inside a firewall, pretty much like all other pieces of client/server software out there. If that's an acceptable solution for your case, you should do it.

Unfortunately firewalls also keep the public out, and most opensim operators, even the ones running walled-garden grids, want to reach out to the public. In this case, opensim operators may develop additional technical obstacles for bots, similar to those we see on the Web. For example, make sure agents are being run by real people by giving them a human-challenge during the login/TP process, etc.

Every obstacle to malicious clients lowers the risk of an intruder attack. However keep this in mind: no matter how many obstacles one builds, a sufficiently skilled and motivated attacker will be able to overcome them to penetrate opensims connected to the public internet. This affects hypergrid nodes as much as walled-garden grids. In fact, it's more pervasive than that: it affects '''all''' servers (opensim, web, etc.) connected to the public internet. Fighting malicious intruders is a fact of a connected world. Fortunately, those attacks don't happen very often, or the Web would have been dead by now.

==== Web Clients ====

CopyBots are the most well-known bots for opensim-based virtual worlds, but these virtual worlds are also susceptible to attacks by regular web clients. With the current state of things, it is actually easier to copy assets with a web-based client than with a libsl-based one. The weakness is that asset servers are connected to the public internet, and the protocol for interacting with them is public.

OpenSim has some minimal guards in place to fence against these kinds of attacks. Specifically, when the inventory server receives a request for an item, it checks the session identifier of the requester. Web clients aren't logged in, so they are refused service. I don't want to expand much more on this, so not to make life easy for attackers, but let's just say that opensim has the necessary mechanisms in place to fence off web-based attackers.

=== Malicious Hosts ===

==== Actively Malicious Hosts ====

The new security threat introduced by openness, one that does not exist in closed grids, is the possibility of a user to visit a region that is running malicious code. In the current state of opensim, a malicious host can do serious damage to the user's assets. Let's see how.

Assume you have your assets in your hypergrided-standalone opensim, and you go visit another opensim that happens to be running malicious code. Here is a non-exhaustive list of vulnerabilities that you are exposed to:

* The host has your session id, so it can request your inventory items on your behalf and store copies in its local asset server. To add insult to injury, a malicious host could simply wipe out your inventory after having copied it.
* Even if the malicious host doesn't access your items by itself, every time you access items in your inventory while you are in that region, those items are cached in the region's local cache, and can be stored persistently by the malicious host.

Malicious hosts can do a lot more damage, but those two are enough to illustrate this new kind of vulnerability affecting open grids. Note that this affects all open grids, i.e. those where arbitrary people can plug-in their opensims, and not just the hypergrid.

Fortunately, there is a family of simple solutions to this problem that can be summarized as "protecting you from yourself." That proposal is described [[Hypergrid Inventory Access|here]].

==== Piracy ====

A second new security threat affecting open grids is one pertaining to commerce of virtual goods. Suppose you put something out for sale on your hypergrided opensim. A foreign user comes and buys it. What that really means is that that user will physically get a copy of the assets moved to his/her asset server, which is different from your asset server. The permissions will be whatever you define them to be, and using the regular VW client, that user can only do what you defined he/she should could do with the object, as usual. However, if the user has direct backend access to the asset and inventory servers, that person can simply modify the permissions on his/her copy. This is commonly known as '''piracy'''.

This situation is the kernel of the belief that open grids are hopeless for a virtual-goods economy. DRM discussion aside, maybe they are hopeless. But then, everyone thought the web was hopeless for selling music, and look at the success of iTunes in spite of all the piracy that still exists out there. Who will be the equivalent of iTunes for virtual hair, skin and clothes?

== Hypergrid Implementation ==

=== Hyperlinks and Agent Transfers ===

When you establish a link between your opensim and another, a message is sent out to that other opensim requesting information about it; the required information includes the network information of that opensim host, and the coordinates of its first region on its local grid in the form of a region handle. For example, suppose you are linking node X.com:9000, placing it in your local map at 900, 900. That opensim runs one or more regions that likely are not in 900, 900 on their own map; suppose the first region of that opensim is at 1100, 1100. From your point of view, it doesn't matter what those other coordinates are, and you don't need to know -- that's the key to being able to decentralize the "world" as given by a 2D map; you want to place it in your map at 900, 900. The "true" position of that simulator only matters for the LL viewer, when there are teleports between your world and that other opensim. This mapping between coordinate systems is the essence of hyperlinks for opensim; it's one simple but critical thing that the hypergrid implementation does. The mapping happens on the TeleportFinish event; instead of sending the local coordinates to the viewer, the hypergrid teleport wrapper sends the remote coordinates.

When an agent teleports through that hyperlink the following happens. First, before InformRegionOfChildAgent, the local opensim notifies the remote opensim of this foreign user via the "expect_hg_user" method. That message sends along the addresses of all the servers that this user uses, i.e. user, inventory and asset servers. The remote opensim places an entry for that user in its local user profile cache but not in its user database; the foreign user information is non-persistent. After that, the teleport process is exactly the same as the normal teleport process; the only difference is that the region handles are switched between the remote region's hyperlink position on the local grid and its actual position on its grid.

In summary, the two new concepts introduced by the hypergrid are the concept of an hyperlink and the concept of a "local user" vs. "foreign user".

=== Inventory Access ===

Inventory access from abroad is done by wrapping the existing scene-inventory interactions with additional code that gets or posts inventory assets from/to the user's asset server. When inventory is accessed, the hypergrid wrapper checks if the user is foreign and, if she is, the wrapper simply brings the necessary assets from the user's asset server to the local asset cache and server; from then on, the wrapper passes the control to the existing inventory access functions. When something is added to inventory, the hypergrid wrapper is notified via an event, and posts the assets to the user's asset server. A cache of the exchanged item identifiers is maintained so that they aren't brought back over and over again.

The result is that hypergrided opensim instances end up interacting with several asset servers, instead of just one. That interaction is implemented in a straightforward manner by instantiating several GridAssetClient objects, instead of just one.

=== The Hypergrid Namespace ===

Currently, the hypergrid is implemented outside of the OpenSim namespace, so that there is complete separation between what already exists and this new behavior. It has its own namespace, HyperGrid. In it, there are 4 sub-namespaces that follow directly the software architecture of OpenSim, namely:

* '''HyperGrid.Framework''' extends OpenSim.Framework in the following manner:
** HGUserProfileData extends UserProfileData by introducing information about the user's "home", namely the home address, port and remoting port. The user's home is not that user's user service; it's the opensim that the user has defined to be her home. This is necessary for supporting the home jump (Ctrl-Shift-H).
** HGNetworkServersInfo follows the spirit of NetworkServersInfo, although it neither extends it nor uses it. For now, it's a utility class whose two main functions are to convert domain names of servers to IP addresses, and to uniformly provide the answer to the question bool IsLocalUser(...).

* '''HyperGrid.Environment''' extends OpenSim.Region.Environment.Scenes in the following manner:
** HGSceneCommunicationService extends SceneCommunicationService, overriding RequestTeleportToLocation. There are two very small but critical changes to the base method: (a) on the TeleportFinish event, we switch the region handles when the destination region is an hyperlink; (b) the connections at the end are always closed for hyperlink TPs.
** HGScene extends Scene, overriding TeleportClientHome(...). The only change to the base method is to stay away from the user server, for now, because the user service is still not completely wrapped up for foreign users. Once the user service is properly wrapped up, this class will become unnecessary.
** HGScene.Inventory is a partial class of HGScene, just like what happens in the OpenSim framework. This part of HGScene overrides some inventory-scene interaction methods, so that assets are fetched/posted from/to the user's asset server. Once that extra fetching/posting is done, these methods simply pass the ball to the base methods.
** HGAssetMapper: this is a new class specific to the hypergrid that manages the fetching and posting of assets between foreign regions where the user is and the user's asset server.

* '''HyperGrid.Protocol''' is a mashup of OpenSim.Region.Communications.*. This is the place where most of the hypergrid extension lies. One of the reasons for this is that the hypergrid communications part is doing one additional thing: it is making standalones network-able.
** HGCommunicationsStandalone extends CommuniationsLocal. Just as its base, it is a hub for the several network services available in standalone mode. The main difference is that those services are extensions of what's in OpenSim.
** HGCommunicationsGridMode extends CommunicationsManager directly. Again, it's a hub for the network services available in grid mode, those services being extensions of OpenSim.
** The cluster HGGridServices (superclass), HGGridServicesStandalone and HGGridServicesGridMode (subclasses) implements the OpenSim interfaces IGridServices and IInterRegionCommunications. The 2 subclasses are wrappers for LocalBackEndServices and OGS1GridServices, respectively. There is one common pattern throughout these classes: check if the region to talk to is an hyperlink; if it's not, simply delegate the work to LocalBackEndServices/OGS1GridServices; if it is, push the work to the base class HGGridServices. HGGridServices, in turn, does the management of hyperlink regions, and defines two additional pieces of inter-region protocol:
*** region_uuid: for linking regions
*** expect_hg_user: similar to the existing expect_user interface, but with a lot more information about the user being passed around, namely all the user's servers (inventory, asset, user, home, etc.)
** HGInventoryService extends LocalInventoryService and implements ISecureInventoryService. This class is the most obvious mashup of the pack, mixing local service access for standalone users and remote inventory access for when users are out and about. Right now, there is a fair amount of selective copy-and-paste, to stay away from the ugliness coming from OGS1InventoryService and OGS1SecureInventoryService. HGInventoryService is always a ISecureInventoryService. Its methods all follow the same pattern: check if the user is a local standalone user; if it is, pass the work to the base method (in LocalInventoryService); if it's not perform secure remote access.
** HGUserServices wraps OSG1UserServices, but it's not functional yet.

* '''HyperGrid.Modules''' is a collection of 3 region modules:
** HGWorldMapModule extends WorldMapModule. It reuses almost everything from the base class. The only small change is in RequestMapBlocks, where it tries to send Offline mapblocks to the client.
** HGStandaloneInventoryService and HGStandaloneAssetService do what their names say. They are region modules that allow access to inventory and assets for standalones, when the standalone user is out and about. In spirit, there is a lot in common between these modules and the REST inventory/asset plugin. Unfortunately, that plugin could not be used because it defines a completely different interface than that used by existing inventory and asset servers, and the access for the hypergrid must use a consistent interface.

=== Class Diagram ===

[[image:HypergridImplementation.jpg|600px|center|(Click on the image to enlarge)]]

== Installing and Running Hypergrid ==

=== Installing ===

# Checkout OpenSim, prebuild and build as normal.
# Make the following changes to your OpenSim.ini:
#* The map: '''WorldMapModule = "HGWorldMap" ''' If you didn't have this setting in your original OpenSim.ini, make sure you place it under the [Startup] section.
#* If you're running your opensim in grid mode with the UGAIM servers on other machines, you're done. If you're running in standalone and you want it to be network-able, or if you have your grid on loopback (127.0.0.1) change all the [Network] server addresses to <nowiki>"http://<external_host_name>:<http_port>"</nowiki>. See below.
# Run opensim like this: <nowiki>[mono] OpenSim.exe -hypergrid=true</nowiki>. To make sure the hypergrid is running type this on your console: '''link-region'''. If you don't hear anything back, the hypergrid is not properly installed.

Here is an example of the Network settings for a standalone:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:9300
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:9300
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:9300
inventory_server_url = http://example.com:9300

Here is an example of the Network settings for a grided opensim:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:8001
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:8002
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:8003
inventory_server_url = http://example.com:8004

'''Important Note'''

Make sure you have a 'home' set. If your home region doesn't exist, the hyperlink TPs may not work. To set your home, go to one of your local regions and "Set Home" from the viewer.

=== Linking regions ===

On the console, type for example:

link-region <Xloc> <Yloc> osl2.nac.uci.edu 9006 OSGrid Gateway

* Use Xloc and Yloc that make sense to your world, i.e. close to your regions, but not adjacent.
* replace osl2.nac.uci.edu and 9006 with the domain name / ip address and the port of the region you want to link to

'''Important Note'''

Due to a viewer [https://jira.secondlife.com/browse/SVC-2941 bug], you can only TP between regions that are no more than 4096 cells apart in any dimension. What this means in practice is that if you want to link to OSGrid, you must have your own regions reachable from the (10,000; 10,000) point on the map, which is where OSGrid is centered. Place your regions somewhere in the 8,000s or the 12,000s.

== Public Hypergrid Nodes ==

The following is a list of hypergrid-ready nodes that you can use for testing your installation and for linking your world. Please add your public node here if you wish to help build a web of opensims!

For the time being, and until the security concerns described above are addressed, we advise you to be careful about who you link to.

* '''osl2.nac.uci.edu 9006'''
The "UCI Welcome" region connected to OSGrid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine. You can link to it as a way to link to OSGrid.

* '''ucigrid02.nacs.uci.edu 9000'''
A region in the UCI Grid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine.

* '''hypergrid.cyberlandia.net 9000'''
The "Cyberlandia Gw" region connected to OSGrid. Search on map "cyberlandia grid" Is link to cyberlandia Italian Opensim grid. You can link to it as a way to link to Cyberlandia.

* '''hypergrid.cyberlandia.net 9300'''
The "Osgrid Gw" region connected to Cyberlandia grid http://www.cyberlandia.net. Search on map "Osgrid grid" You can link to it as a way to link to OSGrid.

Hypergrid

2008-11-26T09:28:49Z

Carlosroundel: /* Public Hypergrid Nodes */

==The OpenSim Hypergrid==

=== What is the hypergrid? ===


The hypergrid is an extension to opensim that allows you to link your opensim to other opensims on the internet, and that supports seamless agent transfers among those opensims. It can be used both in standalone mode and in grid mode. The hypergrid is effectively supporting the emergence of a Web of virtual worlds.

The basic idea for the hypergrid is that region/grid administrations can place hyperlinks on their map to hypergrided regions run by others. Once those hyperlinks are established, users interact with those regions in exactly the same way as they interact with local regions. Specifically, users can choose to teleport there. Once the user reaches the region behind the hyperlink, she is automatically interacting with a different virtual world without having to logout from the world where she came from, and while still having access to her inventory.

The hypergrid started as a GForge project, but it is now included in the standard distribution of OpenSim. To run your OpenSim instance in hypergrid mode, please see [[Hypergrid#Installing_and_Running_Hypergrid|Installing and Running]].

=== Virtual World Hyperlinks ===
[[image:hghyperlink.jpg|250px|thumb|A Virtual World Hyperlink]]

We're all familiar with hypertext links on the Web. But what is a virtual world hyperlink?

In the hypergrid model, we consider the 2D map of the virtual world as the equivalent of a web page. As such, a VW hyperlink is simply a region on that map.

The default model of opensim-based virtual worlds already supports this concept of hyperlink, to some extent. When you teleport from one region to another via the map, chances are you are migrating your agent into a different opensim server. This migration is a glorified "agent transfer" that also exists, in rudimentary form, on the web when hypertext links are followed. The default model, however, imposes two very strong constraints on these hyperlinks:
# The entire map of regions is controlled by a central service known as the grid service, whose job is to provide a uniform view of the world to all of its regions.
# The only agents that can be transferred are those pertaining to users known to another central service, the user service; if the incoming user is not on that service's database, the agent transfer doesn't go through.

The hypergrid simply removes these two constraints.

First, it allows individual opensim instances to add "neighbors" to their local map, shifting the control of the map down from the grid server to individual opensim instances (although hyperlinks can also be served by grid servers if grid admins so wish). In doing so, the world becomes a lot more interesting and varied. The map that you see in one opensim instance may be completely different from the map that you see after you teleport via an hyperlink. As an opensim administrator, you are free to define what other opensims you want to see on your map.

Second, it allows the transfer of agents pertaining to foreigner users, i.e. users who are registered elsewhere. Instead of assuming one central user service, the hypergrid assumes an arbitrarily large number of such services distributed all over the world. As such, when agents are transferred among hypergrided opensims, a lot more information is passed about the corresponding user. That information includes the collection of servers that the transferring user needs.

=== Usage Scenarios ===

The following are some usage scenarios. There isn't a clear separation between these scenarios, there's a large overlap between them. This is also not an exhaustive list. The purpose of these descriptions is to give you some starting ideas for how to use the hypergrid in practice. Please feel free to add other interesting scenarios to this list.

{| {{Prettytable}}
|-
|
[[image:topoA.jpg|400px|left]]
|
'''Personal Worlds'''

This first scenario pertains to standalone opensims. Normally, standalones are completely disconnected from the internet. However, when run in hypergrid mode, standalones become network-able. As such, you can run your own world in your own computer, and link your world to whoever you want. For example, you can link to your friends' hypergrided opensims and to hypergrid gateways in open grids such as OSGrid.

The great thing about this scenario is that all of your assets are stored on your computer, and not on somebody else's server. You can back them up using ordinary backend tools. The not so great thing about this scenario is that all of your assets are stored on your computer! If your disk goes berserk, you loose them. (so make sure you make external backups regularly)

|-
|
[[image:topoB.jpg|400px|left]]
|
'''Communities'''

This second scenario is about communities, broadly construed. The idea here is that a group of people come together to support a small community grid, i.e. a common world where shared activities take place. But at the same time, the members of the community maintain their own standalone worlds. The standalones link to the community grid, and the community grid may link back to the individual members' worlds and other places of interest.

The members' identities are probably the identities they have on their standalones, and their assets are also probably stored there. The assets present in the community regions, however, are stored on the grid asset server.

|-
|
[[image:topoC.jpg|400px|left]]
|
'''Grid Public Regions'''

Walled-gardens are here to stay, and they serve many useful purposes. There is a hybrid mode for the hypergrid that some walled-garden grid operators may be interested in supporting. In this hybrid mode, most opensim instances on the grid run in normal, wall-garden mode, so no foreign visitors are allowed there - technically it is impossible to reach them. However, a few opensim instances on that grid can run in hypergrid mode, so that foreign visitors are allowed. This way, there is a gateway for grid-local users and arbitrary visitors to meet. This is also a good strategy for attracting new users to the grid, since random users are able to visit those gateway regions without having to sign up for an account upfront.

This hybrid mode is very similar to what happens on the web. For example, anyone can visit Facebook's public pages without having to sign up for a Facebook account. However, only Facebook users can go further inside.

|-
|
[[image:topoD.jpg|400px|left]]
|
'''Level Games'''

The normal version of OpenSim enforces a common map for all the regions on a grid. The hypergrid removes that constraint. As such, it becomes easy to design VW games where the world looks different depending of where the player is.

|-
|}

== Security Concerns ==

There is a wide-spread assumption that open grids such as OSGrid and new forms of grids such as the hypergrid are inherently insecure, and that it will be impossible to develop a "goods-based" economy on top of them; only walled-gardens can be secured. This is both true and false. While it is true with the current state of things, open grids, whatever their form, can be made as secure as the web. The first step towards that is to define exactly what the security threats are, and how they affect (or not) open and closed grids. So, let's spell them out, and face them head-on. This will help put our feet on the ground so that we start developing appropriate solutions.

=== Malicious Clients ===

==== CopyBots ====

Everyone knows about the infamous [http://en.wikipedia.org/wiki/CopyBot CopyBot]. Using libraries such as [http://www.libsecondlife.org/wiki/Main_Page LibSL] (now known as OpenMetaverse) it is possible to develop clients for opensim servers that do unorthodox things such as bypassing the permissions system to copy people's assets. Bots written by griefers can do lots of other nasty things.

Malicious bots are a problem for all opensim administrators, including walled-garden grids. They can be prevented, to a certain extent, by exo-technical solutions such as Terms of Service and real-world lawsuits. Technically speaking, the only way to keep intruders out is to run opensim inside a firewall, pretty much like all other pieces of client/server software out there. If that's an acceptable solution for your case, you should do it.

Unfortunately firewalls also keep the public out, and most opensim operators, even the ones running walled-garden grids, want to reach out to the public. In this case, opensim operators may develop additional technical obstacles for bots, similar to those we see on the Web. For example, make sure agents are being run by real people by giving them a human-challenge during the login/TP process, etc.

Every obstacle to malicious clients lowers the risk of an intruder attack. However keep this in mind: no matter how many obstacles one builds, a sufficiently skilled and motivated attacker will be able to overcome them to penetrate opensims connected to the public internet. This affects hypergrid nodes as much as walled-garden grids. In fact, it's more pervasive than that: it affects '''all''' servers (opensim, web, etc.) connected to the public internet. Fighting malicious intruders is a fact of a connected world. Fortunately, those attacks don't happen very often, or the Web would have been dead by now.

==== Web Clients ====

CopyBots are the most well-known bots for opensim-based virtual worlds, but these virtual worlds are also susceptible to attacks by regular web clients. With the current state of things, it is actually easier to copy assets with a web-based client than with a libsl-based one. The weakness is that asset servers are connected to the public internet, and the protocol for interacting with them is public.

OpenSim has some minimal guards in place to fence against these kinds of attacks. Specifically, when the inventory server receives a request for an item, it checks the session identifier of the requester. Web clients aren't logged in, so they are refused service. I don't want to expand much more on this, so not to make life easy for attackers, but let's just say that opensim has the necessary mechanisms in place to fence off web-based attackers.

=== Malicious Hosts ===

==== Actively Malicious Hosts ====

The new security threat introduced by openness, one that does not exist in closed grids, is the possibility of a user to visit a region that is running malicious code. In the current state of opensim, a malicious host can do serious damage to the user's assets. Let's see how.

Assume you have your assets in your hypergrided-standalone opensim, and you go visit another opensim that happens to be running malicious code. Here is a non-exhaustive list of vulnerabilities that you are exposed to:

* The host has your session id, so it can request your inventory items on your behalf and store copies in its local asset server. To add insult to injury, a malicious host could simply wipe out your inventory after having copied it.
* Even if the malicious host doesn't access your items by itself, every time you access items in your inventory while you are in that region, those items are cached in the region's local cache, and can be stored persistently by the malicious host.

Malicious hosts can do a lot more damage, but those two are enough to illustrate this new kind of vulnerability affecting open grids. Note that this affects all open grids, i.e. those where arbitrary people can plug-in their opensims, and not just the hypergrid.

Fortunately, there is a family of simple solutions to this problem that can be summarized as "protecting you from yourself." That proposal is described [[Hypergrid Inventory Access|here]].

==== Piracy ====

A second new security threat affecting open grids is one pertaining to commerce of virtual goods. Suppose you put something out for sale on your hypergrided opensim. A foreign user comes and buys it. What that really means is that that user will physically get a copy of the assets moved to his/her asset server, which is different from your asset server. The permissions will be whatever you define them to be, and using the regular VW client, that user can only do what you defined he/she should could do with the object, as usual. However, if the user has direct backend access to the asset and inventory servers, that person can simply modify the permissions on his/her copy. This is commonly known as '''piracy'''.

This situation is the kernel of the belief that open grids are hopeless for a virtual-goods economy. DRM discussion aside, maybe they are hopeless. But then, everyone thought the web was hopeless for selling music, and look at the success of iTunes in spite of all the piracy that still exists out there. Who will be the equivalent of iTunes for virtual hair, skin and clothes?

== Hypergrid Implementation ==

=== Hyperlinks and Agent Transfers ===

When you establish a link between your opensim and another, a message is sent out to that other opensim requesting information about it; the required information includes the network information of that opensim host, and the coordinates of its first region on its local grid in the form of a region handle. For example, suppose you are linking node X.com:9000, placing it in your local map at 900, 900. That opensim runs one or more regions that likely are not in 900, 900 on their own map; suppose the first region of that opensim is at 1100, 1100. From your point of view, it doesn't matter what those other coordinates are, and you don't need to know -- that's the key to being able to decentralize the "world" as given by a 2D map; you want to place it in your map at 900, 900. The "true" position of that simulator only matters for the LL viewer, when there are teleports between your world and that other opensim. This mapping between coordinate systems is the essence of hyperlinks for opensim; it's one simple but critical thing that the hypergrid implementation does. The mapping happens on the TeleportFinish event; instead of sending the local coordinates to the viewer, the hypergrid teleport wrapper sends the remote coordinates.

When an agent teleports through that hyperlink the following happens. First, before InformRegionOfChildAgent, the local opensim notifies the remote opensim of this foreign user via the "expect_hg_user" method. That message sends along the addresses of all the servers that this user uses, i.e. user, inventory and asset servers. The remote opensim places an entry for that user in its local user profile cache but not in its user database; the foreign user information is non-persistent. After that, the teleport process is exactly the same as the normal teleport process; the only difference is that the region handles are switched between the remote region's hyperlink position on the local grid and its actual position on its grid.

In summary, the two new concepts introduced by the hypergrid are the concept of an hyperlink and the concept of a "local user" vs. "foreign user".

=== Inventory Access ===

Inventory access from abroad is done by wrapping the existing scene-inventory interactions with additional code that gets or posts inventory assets from/to the user's asset server. When inventory is accessed, the hypergrid wrapper checks if the user is foreign and, if she is, the wrapper simply brings the necessary assets from the user's asset server to the local asset cache and server; from then on, the wrapper passes the control to the existing inventory access functions. When something is added to inventory, the hypergrid wrapper is notified via an event, and posts the assets to the user's asset server. A cache of the exchanged item identifiers is maintained so that they aren't brought back over and over again.

The result is that hypergrided opensim instances end up interacting with several asset servers, instead of just one. That interaction is implemented in a straightforward manner by instantiating several GridAssetClient objects, instead of just one.

=== The Hypergrid Namespace ===

Currently, the hypergrid is implemented outside of the OpenSim namespace, so that there is complete separation between what already exists and this new behavior. It has its own namespace, HyperGrid. In it, there are 4 sub-namespaces that follow directly the software architecture of OpenSim, namely:

* '''HyperGrid.Framework''' extends OpenSim.Framework in the following manner:
** HGUserProfileData extends UserProfileData by introducing information about the user's "home", namely the home address, port and remoting port. The user's home is not that user's user service; it's the opensim that the user has defined to be her home. This is necessary for supporting the home jump (Ctrl-Shift-H).
** HGNetworkServersInfo follows the spirit of NetworkServersInfo, although it neither extends it nor uses it. For now, it's a utility class whose two main functions are to convert domain names of servers to IP addresses, and to uniformly provide the answer to the question bool IsLocalUser(...).

* '''HyperGrid.Environment''' extends OpenSim.Region.Environment.Scenes in the following manner:
** HGSceneCommunicationService extends SceneCommunicationService, overriding RequestTeleportToLocation. There are two very small but critical changes to the base method: (a) on the TeleportFinish event, we switch the region handles when the destination region is an hyperlink; (b) the connections at the end are always closed for hyperlink TPs.
** HGScene extends Scene, overriding TeleportClientHome(...). The only change to the base method is to stay away from the user server, for now, because the user service is still not completely wrapped up for foreign users. Once the user service is properly wrapped up, this class will become unnecessary.
** HGScene.Inventory is a partial class of HGScene, just like what happens in the OpenSim framework. This part of HGScene overrides some inventory-scene interaction methods, so that assets are fetched/posted from/to the user's asset server. Once that extra fetching/posting is done, these methods simply pass the ball to the base methods.
** HGAssetMapper: this is a new class specific to the hypergrid that manages the fetching and posting of assets between foreign regions where the user is and the user's asset server.

* '''HyperGrid.Protocol''' is a mashup of OpenSim.Region.Communications.*. This is the place where most of the hypergrid extension lies. One of the reasons for this is that the hypergrid communications part is doing one additional thing: it is making standalones network-able.
** HGCommunicationsStandalone extends CommuniationsLocal. Just as its base, it is a hub for the several network services available in standalone mode. The main difference is that those services are extensions of what's in OpenSim.
** HGCommunicationsGridMode extends CommunicationsManager directly. Again, it's a hub for the network services available in grid mode, those services being extensions of OpenSim.
** The cluster HGGridServices (superclass), HGGridServicesStandalone and HGGridServicesGridMode (subclasses) implements the OpenSim interfaces IGridServices and IInterRegionCommunications. The 2 subclasses are wrappers for LocalBackEndServices and OGS1GridServices, respectively. There is one common pattern throughout these classes: check if the region to talk to is an hyperlink; if it's not, simply delegate the work to LocalBackEndServices/OGS1GridServices; if it is, push the work to the base class HGGridServices. HGGridServices, in turn, does the management of hyperlink regions, and defines two additional pieces of inter-region protocol:
*** region_uuid: for linking regions
*** expect_hg_user: similar to the existing expect_user interface, but with a lot more information about the user being passed around, namely all the user's servers (inventory, asset, user, home, etc.)
** HGInventoryService extends LocalInventoryService and implements ISecureInventoryService. This class is the most obvious mashup of the pack, mixing local service access for standalone users and remote inventory access for when users are out and about. Right now, there is a fair amount of selective copy-and-paste, to stay away from the ugliness coming from OGS1InventoryService and OGS1SecureInventoryService. HGInventoryService is always a ISecureInventoryService. Its methods all follow the same pattern: check if the user is a local standalone user; if it is, pass the work to the base method (in LocalInventoryService); if it's not perform secure remote access.
** HGUserServices wraps OSG1UserServices, but it's not functional yet.

* '''HyperGrid.Modules''' is a collection of 3 region modules:
** HGWorldMapModule extends WorldMapModule. It reuses almost everything from the base class. The only small change is in RequestMapBlocks, where it tries to send Offline mapblocks to the client.
** HGStandaloneInventoryService and HGStandaloneAssetService do what their names say. They are region modules that allow access to inventory and assets for standalones, when the standalone user is out and about. In spirit, there is a lot in common between these modules and the REST inventory/asset plugin. Unfortunately, that plugin could not be used because it defines a completely different interface than that used by existing inventory and asset servers, and the access for the hypergrid must use a consistent interface.

=== Class Diagram ===

[[image:HypergridImplementation.jpg|600px|center|(Click on the image to enlarge)]]

== Installing and Running Hypergrid ==

=== Installing ===

# Checkout OpenSim, prebuild and build as normal.
# Make the following changes to your OpenSim.ini:
#* The map: '''WorldMapModule = "HGWorldMap" ''' If you didn't have this setting in your original OpenSim.ini, make sure you place it under the [Startup] section.
#* If you're running your opensim in grid mode with the UGAIM servers on other machines, you're done. If you're running in standalone and you want it to be network-able, or if you have your grid on loopback (127.0.0.1) change all the [Network] server addresses to <nowiki>"http://<external_host_name>:<http_port>"</nowiki>. See below.
# Run opensim like this: <nowiki>[mono] OpenSim.exe -hypergrid=true</nowiki>. To make sure the hypergrid is running type this on your console: '''link-region'''. If you don't hear anything back, the hypergrid is not properly installed.

Here is an example of the Network settings for a standalone:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:9300
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:9300
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:9300
inventory_server_url = http://example.com:9300

Here is an example of the Network settings for a grided opensim:

[Network]
http_listener_port = 9300
remoting_listener_port = 9895

grid_server_url = http://example.com:8001
grid_send_key = null
grid_recv_key = null

user_server_url = http://example.com:8002
user_send_key = null
user_recv_key = null

asset_server_url = http://example.com:8003
inventory_server_url = http://example.com:8004

'''Important Note'''

Make sure you have a 'home' set. If your home region doesn't exist, the hyperlink TPs may not work. To set your home, go to one of your local regions and "Set Home" from the viewer.

=== Linking regions ===

On the console, type for example:

link-region <Xloc> <Yloc> osl2.nac.uci.edu 9006 OSGrid Gateway

* Use Xloc and Yloc that make sense to your world, i.e. close to your regions, but not adjacent.
* replace osl2.nac.uci.edu and 9006 with the domain name / ip address and the port of the region you want to link to

'''Important Note'''

Due to a viewer [https://jira.secondlife.com/browse/SVC-2941 bug], you can only TP between regions that are no more than 4096 cells apart in any dimension. What this means in practice is that if you want to link to OSGrid, you must have your own regions reachable from the (10,000; 10,000) point on the map, which is where OSGrid is centered. Place your regions somewhere in the 8,000s or the 12,000s.

== Public Hypergrid Nodes ==

The following is a list of hypergrid-ready nodes that you can use for testing your installation and for linking your world. Please add your public node here if you wish to help build a web of opensims!

For the time being, and until the security concerns described above are addressed, we advise you to be careful about who you link to.

* '''osl2.nac.uci.edu 9006'''
The "UCI Welcome" region connected to OSGrid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine. You can link to it as a way to link to OSGrid.

* '''ucigrid02.nacs.uci.edu 9000'''
A region in the UCI Grid. It is run by Diva (Crista Lopes) on a machine owned by the University of California, Irvine.

* '''hypergrid.cyberlandia.net 9000'''
The "Cyberlandia Gw" region connected to OSGrid. Search on map "cyberlandia grid" Is link to cyberlandia Italian Opensim grid

* '''hypergrid.cyberlandia.net 9300'''
The "Osgrid Gw" region connected to Cyberlandia grid http://www.cyberlandia.net. Search on map "Osgrid grid" You can link to it as a way to link to OSGrid.

Development Team

2008-07-01T09:00:15Z

Carlosroundel: /* Additional Developers/Testers/Contributors */

== Active OpenSim Core Developers ==
These people have commit access to our central SVN server and are regular contributors to the codebase.

(please add in as much info as you like for your name)

<table border="1" cellpadding="2" cellspacing="0" class="sortable">
<tr>
<th>Photo </th>
<th>IRC Nick </th>
<th>Name</th>
<th>SL Avatar</th>
<th>Other Grid</th>
<th>Time Zone<br>(UTC)</th>
<th>Org</th>
<th>Areas of Interest</th>
</tr>
<tr>
<td />
<td>[[User:MW / Michael Wright |MW / Michael Wright ]]</td>
<td>Darren</td>
<td>Wright Juran</td>
<td></td>
<td>0</td>
<td>Tribal Media AB</td>
<td>everything</td>
</tr>
<tr>
<td />
<td>[[User:Adam Frisby|Adam Frisby]]</td>
<td>Adam Frisby</td>
<td>Adam Zaius</td>
<td></td>
<td>+8</td>
<td>DeepThink Pty Ltd</td>
<td>Terrain, Performance</td>
</tr>
<tr>
<td />
<td>[[User:MingChen|MingChen]]</td>
<td>Mike/Michael Ortman</td>
<td>Ming Chen</td>
<td></td>
<td>-6 (-5 in Summer)</td>
<td>DeepThink Pty Ltd</td>
<td>Estate/Parcel Support/Modules/Keeping things all neat and tidy.</td>
</tr>
<tr>
<td> </td>
<td>[[User:lbsa71|lbsa71]]</td>
<td>Stefan Andersson</td>
<td>PierreJoseph Proudhon</td>
<td>OSG:Stefan Andersson<br/>OLG:Stefan Andersson</td>
<td>+1</td>
<td>Tribal Media AB</td>
<td> 3D and Web Integration</td>
</tr>
<tr>
<td />
<td>[[User:SeanDague|sdague]]</td>
<td>Sean Dague</td>
<td>Neas Bade</td>
<td></td>
<td>-5</td>
<td>IBM</td>
<td>Database, Linux, Testing, Misc</td>
</tr>
<tr>
<td />
<td>[[User:Tedd|Tedd]]</td>
<td>Tedd Hansen</td>
<td>Tedd Maa</td>
<td></td>
<td>+1</td>
<td>Tedd Hansen</td>
<td>Programming/Scripting/Architecture</td>
</tr>
<tr>
<td />
<td>[[User:dalien|dalien]]</td>
<td>Dalien Talbot</td>
<td>Dalien Talbot</td>
<td></td>
<td>+1</td>
<td>Mostly TCP-based</td>
<td>Small fixes; rev.eng./prototyping; nightlies; git-keeper </td>
</tr>
<tr>
<td />
<td>ckrinke</td>
<td>Charles Krinke</td>
<td>Charlesk Bing</td>
<td></td>
<td>-8</td>
<td> </td>
<td>Reliability/Grid servers/ll-functions</td>
</tr>
<tr>
<td />
<td>[[User:chi11ken|chi11ken]]</td>
<td>Jeff Ames</td>
<td>Chillken Proto</td>
<td></td>
<td>+9</td>
<td>3Di / Genkii</td>
<td> </td>
</tr>
<tr>
<td />
<td>[[User:adjohn|adjohn]]</td>
<td>Adam Johnson</td>
<td>Zeuz Zenovka</td>
<td></td>
<td>+9</td>
<td>3Di / Genkii</td>
<td> </td>
</tr>
<tr>
<td />
<td>[[User:joha1|joha1]]</td>
<td>Johan Berntsson</td>
<td>Joppi Brandenburg</td>
<td></td>
<td>+9</td>
<td>3Di Inc, Japan<br/>http://www.3di.jp/</td>
<td>Performance, packet handling/libSL</td>
</tr>
<tr>
<td />
<td>[[User:Teravus|Teravus]]</td>
<td>Teravus</td>
<td>Teravus Ousley</td>
<td></td>
<td>-5</td>
<td>W3z</td>
<td>Physics & Admin tools, A working sim.</td>
</tr>
<tr>
<td />
<td>[[User:Justincc|Justincc]]</td>
<td>Justin Clark-Casey</td>
<td>Lulworth Beaumont</td>
<td>Justin Clark-Casey (osgrid)</td>
<td>0</td>
<td>IBM</td>
<td>Grid, performance & reliability, inventory (avatar and object), assets, scenes.</td>
</tr>
<tr>
<td />
<td>[[Alondria]]</td>
<td></td>
<td>Alondria LeFay</td>
<td>Alondria LeFay (OSGrid)</td>
<td>-8</td>
<td>Independent</td>
<td>Implementation of LSL functions and other scripting tidbits.</td>
</tr>
<tr>
<td />
<td>[[User:DrScofield|drscofld]]</td>
<td>Dirk Husemann</td>
<td>Dr Scofield</td>
<td></td>
<td>+1</td>
<td>IBM</td>
<td>reliability, networking protocols, voice, inventory, assets, remote control, and pretty much everything else :-)</td>
</tr>
<tr>
<td />
<td>[[User:dahlia|dahlia]]</td>
<td></td>
<td>Dahlia Trimble</td>
<td></td>
<td>-8 / -7</td>
<td>independent</td>
<td>prim collision geometry, more later :)</td>
</tr>
</table>

== Retired OpenSim core developers ==

These people are core developers who have transcended our mortal plane (i.e. they are no longer active).

<table border="1" cellpadding="2" cellspacing="0" class="sortable">
<tr>
<th>Photo </th>
<th>IRC Nick </th>
<th>Name</th>
<th>SL Avatar</th>
<th>Other Grid</th>
<th>Time Zone<br>(UTC)</th>
<th>Org</th>
<th>Areas of Interest</th>
</tr>
<tr>
<td />
<td>[[User:babblefrog|babblefrog]]</td>
<td>Brian McBee</td>
<td>Dogen Coldstream</td>
<td>Babblefrog Ballistic (osgrid)</td>
<td>-8</td>
<td>Disorganized</td>
<td> </td>
</tr>
<tr>
<td />
<td>[[User:danx0r|danx0r]]</td>
<td>Dan Miller</td>
<td>Albert Pascal</td>
<td></td>
<td>-8</td>
<td>squiggle.com</td>
<td>PHEEZIKS; everything</td>
</tr>
<tr>
<td />
<td>Tleiades</td>
<td> </td>
<td>Tleiades Hax</td>
<td></td>
<td>+1</td>
<td> </td>
<td>Grid servers/Database</td>
</tr>
<tr>
<td />
<td>[[User:Darok|Darok]]</td>
<td> </td>
<td>Darok Kaminski</td>
<td></td>
<td>+1</td>
<td> </td>
<td>Physics engines (especially BulletX)</td>
</tr>
</table>

== Additional Developers/Testers/Contributors ==
These people have contributed bug reports, patches or other contributions to OpenSim.

<table border="1" cellpadding="2" cellspacing="0" class="wikitable sortable">
<tr>
<th>IRC Nick </th>
<th>Name</th>
<th>SL Avatar</th>
<th>Other Grid</th>
<th>Time Zone<br>(UTC)</th>
<th>Org</th>
<th>Areas of Interest</th>
</tr>
<tr>
<td>[[User:Nebadon|Nebadon]]</td>
<td>Michael Cerquoni</td>
<td>Nebadon Izumi</td>
<td>Nebadon Izumi</td>
<td>-7 Arizona</td>
<td>Oni Kenkon Creations</td>
<td>Building, Scripting, Testing</td>
</tr>
<tr>
<td>[[User:jtclark48|jclark4]]</td>
<td>Jay Clark</td>
<td>Jay Clarke</td>
<td></td>
<td>-5</td>
<td>IBM</td>
<td>Physics, Grid Host, AI, Scripting, Testing</td>
</tr>
<tr>
<td>Gareth</td>
<td> </td>
<td> </td>
<td></td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[User:AdamStevenson|BigFootAg]]</td>
<td>Adam Stevenson</td>
<td>Adamus Petrov</td>
<td></td>
<td>-6</td>
<td>Texas A&M University</td>
<td>AI, Skynet, Evolving Systems, Biology</td>
</tr>
<tr>
<td>simsim</td>
<td>caocao</td>
<td> </td>
<td> </td>
<td>+9</td>
<td> </td>
<td>Testing whole functions of OpenSim system,working with OpenSim-Engine,reporting on OpenSim</td>
</tr>
<tr>
<td>[[User:Vicero Lambert|Vicero Lambert]]</td>
<td> </td>
<td> </td>
<td></td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>Ldvoipeng</td>
<td> </td>
<td> </td>
<td></td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>idoru</td>
<td> </td>
<td> </td>
<td></td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[User:Magi|Magi]]</td>
<td>Andy Agnew</td>
<td>Magi Merlin</td>
<td></td>
<td>+10</td>
<td>Spun Pty Ltd</td>
<td>3D Web Integration, Database stuff and playing with the odds and ends box.</td>
</tr>
<tr>
<td>john_</td>
<td>John Moyer</td>
<td>VAJohn GeekSquad or Matthew Kendal</td>
<td></td>
<td>-5</td>
<td>Best Buy/Geek Squad</td>
<td>Tester</td>
</tr>
<tr>
<td>[[User:ClarkZone|ClarkZone]]</td>
<td>Troy Admin(@ClarkZone)</td>
<td>Troy Childs</td>
<td>Troy Admin (ClarkZone)</td>
<td>-5</td>
<td>Http://clarkzone.dyndns.org</td>
<td>Tester and Grid Host</td>
</tr>
<tr>
<td>[[User:aiaustin|aiaustin]]</td>
<td>Ai Austin</td>
<td>Ai Austin</td>
<td>Ai AIAI (AIAI Grid)</td>
<td>+0</td>
<td>AIAI, University of Edinburgh<br>http://www.aiai.ed.ac.uk/~ai/<br>http://vue.ed.ac.uk/openvue/</td>
<td>Windows Vista tests<br>Content testing<br>Use of multiple VWs</td>
</tr>
<tr>
<td>[[User:balthazar|balthazar]]</td>
<td>Trevor Brooks</td>
<td>Balthazar Sin</td>
<td></td>
<td>-5</td>
<td>None</td>
<td>Terrains, testing and some small coding tasks</td>
</tr>
<tr>
<td>[[User:jimbo2120|jimbo2120]]</td>
<td>Michael Osias</td>
<td>Illuminous Beltran</td>
<td></td>
<td>-5</td>
<td>IBM</td>
<td>Grid, AI, Skynet, coding and testing</td>
</tr>
<tr>
<td>[[User:Sakai|Sakai]]</td>
<td>Steve S</td>
<td></td>
<td>Sakai Openlife (OpenlifeGrid)</td>
<td>+10</td>
<td>http://www.openlifegrid.com</td>
<td>Grid, Hardware, Testing, Contribution</td>
</tr>
<tr>
<td>ZeroPoint</td>
<td> </td>
<td>Guilderoy Dench</td>
<td></td>
<td>-5</td>
<td> </td>
<td>Programming/Database</td>
</tr>
<tr>
<td>MaltosSosa</td>
<td>Maltos Sosa</td>
<td>Maltos Sosa<br></td>
<td>Maltos Sosa (Central Grid)</td>
<td> </td>
<td>Central Grid</td>
<td>Grid Operator, Central Grid Project Manager. Anything we can offer, just ask.</td>
</tr>

<tr>
<td>[[User:DerekTang|DerekTang]]</td>
<td>Derek Tang</td>
<td>Derek Timeless</td>
<td>Derek Tang (ChineseGrid)</td>
<td>+8</td>
<td>http://ChineseGrid.net</td>
<td>Running a public WINDOWS sim for testing, Docs, Helping Chinese users to enjoy OpenSim; building Chinese OpenSim communities. In construction...</td>
</tr>

<tr>
<td>[[User:TayB|TayB]]</td>
<td>Earl B</td>
<td>Taylor Boyau</td>
<td></td>
<td>-10</td>
<td>ViziGrid</td>
<td>Grid Host,Networking,Contributions & Testing.</td>
</tr>
<tr>
<td>[[User:JamieDav|JamieDav]]</td>
<td>Jamie David</td>
<td>Jamie David</td>
<td></td>
<td>+7</td>
<td>Forum</td>
<td>Grid, Sim, Avitar, Functionality</td>
</tr>
<tr>
<td>[[User:Krtaylor|Krtaylor]]</td>
<td>Kurt Taylor</td>
<td>Kurt Stringer </td>
<td></td>
<td>-6</td>
<td>IBM</td>
<td>Grid, Networking, Monitoring, Scripting, Inventory, Testing</td>
</tr>
<tr>
<td>[[User:Nink|Nink]]</td>
<td>Peter Finn</td>
<td>Nink Noonan</td>
<td></td>
<td>-5</td>
<td>IBM</td>
<td>Disruptive Influence.</td>
</tr>
<tr>
<td>[[User:Bruce|Bruce]]</td>
<td>Bruce Meerson</td>
<td>Bruce Meerson</td>
<td></td>
<td>+8</td>
<td>HiPiHi</td>
<td>Watching.</td>
</tr>
<tr>
<tr>
<td>[[User:Darb|DarbD]]</td>
<td>Brian B. Quinn</td>
<td>Darb Dabney</td>
<td>regions<br />near Berkeley</td>
<td>-7</td>
<td>City of Berkeley, CA<br /> http://blog.simgis.org</td>
<td>LiDAR-based sculpties, real-world terrain, <br />pursuit of civic paraverses </td>
</tr>
<tr>
<td>[[CharlieO]]</td>
<td>Dan</td>
<td>Charlie Omega</td>
<td></td>
<td> </td>
<td> </td>
<td>Mild coding/tweaking/simple feature adds, Stress testing/break stuff, Testing limits of existing code. Making sure [[LSL Status]] is up to date</td>
</tr>
<tr>
<td>oobscure</td>
<td> </td>
<td>Opensource Obscure</td>
<td></td>
<td>+1</td>
<td>http://www.opensim.it</td>
<td>Running a public Linux sim for testing, Docs, Helping italian users, Building opensim communities, Watching</td>
</tr>
<tr>
<td>pitman</td>
<td>Mike Pitman</td>
<td>Rez Tone</td>
<td></td>
<td> </td>
<td>IBM</td>
<td>Scientific visualization schemes, virt world product design, persistant workspaces, virt world based big biz</td>
</tr>
<tr>
<td>cmu</td>
<td>Christopher Mumme</td>
<td>Snook Destiny</td>
<td></td>
<td>+1</td>
<td>http://www.cmu-develop.de/ and research group "Collaboration Systems and CSCW" at Clausthal University of Technology</td>
<td>Testing OpenSim, working with OpenSim-Engine, reporting on OpenSim</td>
</tr>

<tr>
<td>[[Silpol]]</td>
<td>Andriy Tymchenko</td>
<td>Andy Tir</td>
<td></td>
<td>EET (+2/3)</td>
<td> http://silpol.blogspot.com/ (also visible at Nokia)</td>
<td>highly uncoordinated mess with elements of palace games, under-table diplomacy, rebellion, coup d'état and mutiny. optionally pirate</td>
</tr>
<tr>
<td>[[User:Grumly|Grumly]]</td>
<td></td>
<td>Forest Klaar</td>
<td>Grumly TheBear</td>
<td>GMT+1</td>
<td>.NET MCAD Dev/Arch/Trainer http://www.devoteam.com</td>
<td>Trying to get into OpenSim code for now. Particularly interrested in data persistence. blog (Hello, Avatar!): http://lslblog.free.fr</td>
</tr>
<tr>
<td>[[daTwitch]]</td>
<td>James G. Stallings II</td>
<td><br>Lazarus Longstaff</td>
<td>Hiro Protagonist (OSGrid)</td>
<td>-5</td>
<td>House Husband</td>
<td>OSGrid Region owner, OSGrid Operator,<BR>Forum Admin, sometime wiki editor</td>
</tr>

<tr>
<td>gryc</td>
<td>Gryc Ueusp</td>
<td>Gryc Uriza</td>
<td>Gryc Uriza(OSGrid)</td>
<td>-6</td>
<td></td>
<td>PHP scripting, web interfaces, interconnectivity, cross-platformedness</td>
</tr>

<tr>
<td>[[User:Phrearch|Phrearch]]</td>
<td>Jeroen van Veen</td>
<td>Phrearch Miles</td>
<td>Phrearch Miles(OSGrid)</td>
<td>Amsterdam/Paris</td>
<td></td>
<td>Documentation, scripts(perl/lsl), RIA(flex) mashup, testing</td>
</tr>

<tr>
<td>[[User:Burnman|Burnman]]</td>
<td>Allen Wilkins</td>
<td>Burnman Bedlam</td>
<td>Sid Green (United Grid)</td>
<td>Boston, USA</td>
<td>United Grid</td>
<td>Testing, testing, and more testing! Getting familiar with the source, interested in all aspects of the project.</td>
</tr>

<tr>
<td>[[User:krisbfunk|krisbfunk]]</td>
<td>Kris Bulman</td>
<td>krisbfunk Vought</td>
<td>Krisbfunk Nocturnal(OSGrid)</td>
<td>PE, Canada (-4)</td>
<td>Edactive Technologies<br />NocturnalEye Productions<br />UPEI</td>
<td>Currently: Testing, bug reports, wiki updating, building on OSGrid</td>
</tr>

<tr>
<td>[[User:HashBox|HashBox]]</td>
<td> </td>
<td>Sibariel Darkstone</td>
<td>Sibariel Darkstone (OSGrid)</td>
<td>New Zealand (+12)</td>
<td></td>
<td>Testing, bug reports, and updating the wiki.</td>
</tr>

<tr>
<td>[[User:Kinoc|Kinoc]]</td>
<td>Kino Coursey</td>
<td>Daxxon Jaxxon</td>
<td>Daxxon Kinoc (OSgrid)</td>
<td>-6</td>
<td>Daxtron Laboratories <br /> http://www.daxtron.com<br /> University of North Texas</td>
<td>AI, Semantic web, Ontologies, Natural Laanguage Processing, Cyc, Bots, NPC </td>
</tr>
<tr>
<td>[[User:trapuh|trapuh]]</td>
<td>Pedro Ribeiro</td>
<td>Vaiten Forder</td>
<td></td>
<td>GMT</td>
<td>University Student, Escola Superior de Educação de Viseu, Portugal </td>
<td>Testing, eventual bug reports and wiki. Music, web/digital arts and php+sql.</td>
</tr>
<tr>
<td>[[User:SonicViz|SonicViz]]</td>
<td>Paul Cohen</td>
<td>Komuso Tokugawa</td>
<td></td>
<td>+9</td>
<td>Http://sonicviz.com</td>
<td>Audio/Music, Interactive Music, Control Protocols, Interfaces, VisualFX, Procedural animation/Generative systems + testing and general dev</td>
</tr>
<tr>
<td>[[User:Mokele|mokele]]</td>
<td>Scott Norman</td>
<td>Mokelembembe Mokeev</td>
<td></td>
<td>-8 (Southern California)</td>
<td>Web Developer (PHP and MySQL)</td>
<td>Interested in seeing running on PowerPC Macs which it is. So, when I can, I'll compile and test on PowerPC Mac (PowerBook G4) and submit reports and then update the wiki if need on installing on Mac. Also have a Ubuntu 7.10 server that I can do testing on too.</td>
</tr>

<tr>
<td>[[User:devalnor|devalnor]]</td>
<td>Devalnor</td>
<td>M. Watkin</td>
<td></td>
<td>+1 (Belgium)</td>
<td></td>
<td>Small Patch code, bug reports, and updating the wiki.</td>
</tr>

<tr>
<td>[[User:Ezekiel|Ezekiel]]</td>
<td>Ezekiel</td>
<td>Ezekiel Zabelin</td>
<td></td>
<td>+1 </td>
<td>http://www.yosims.com </td>
<td>Concepts, business aspects of virtual worlds - web developer (PHP, MySQL, Javascript, LSL) </td>
</tr>

<tr>
<td>[[User:Diva|diva]]</td>
<td>Crista Lopes</td>
<td>Diva Canto</td>
<td>Diva Canto or Crista Lopes in as many grids as possible</td>
<td>-8 </td>
<td>UC Irvine and http://metaverseink.com </td>
<td>Search, general architecture, real-world modeling</td>
</tr>

<tr>
<td>[[User:Buggmaster|Buggmaster]]</td>
<td>Mike D</td>
<td>Bug Master</td>
<td>None</td>
<td>-8 </td>
<td>http://www.adultmetaverse.com</td>
<td>Grid, Data/Web PHP/PERL/MySQL</td>
</tr>

<tr>
<td>[[User:Nixnerd|nixnerd]]</td>
<td>Richmund</td>
<td>Dangerously Moody</td>
<td>None</td>
<td>GMT </td>
<td>http://www.integratedtechnologies.eu</td>
<td>Cross Platform Testing, Feedback, Bug Reporting</td>
</tr>

<tr>
<td>[[User:MoHax|mohax]]</td>
<td>Mo Hax</td>
<td>Mo Hax</td>
<td></td>
<td>-5 Eastern</td>
<td>IBM</td>
<td>Testing, Feedback, Content Contributions, Bug Reporting, Documenting, Development</td>
</tr>

<tr>
<td>[[User:Webmage|webmage]]</td>
<td>webmage</td>
<td>Leyla Masala</td>
<td>Web Mage</td>
<td>+1</td>
<td>IBM</td>
<td>Testing, terrain</td>
</tr>

<tr>
<td>[[User:NLStitch|NLStitch]]</td>
<td>Marijn Oosterveld</td>
<td>Stitch Seale</td>
<td>NYA</td>
<td>GMT +1 Amsterdam</td>
<td>
Twingate Systems (http://www.twingate.nl)<br>
HanzeHogeschool Groningen, Netherlands
</td>
<td>Programming, Photography, AI</td>
</tr>

<tr>
<td>[[User:Ideia Boa|Ideia Boa]]</td>
<td>Joao Lopes</td>
<td>Ideia Boa</td>
<td>Ideia Boa or Boa Ideia in as many grids as possible</td>
<td>+1</td>
<td>http://www.clubslportugues.com</td>
<td>Testing, testing, and more testing! Trying to get into OpenSim code for now. Updating the original wiki and translating the OpenSim Wiki into Portugueses and reporting on OpenSim</td>
</tr>

<tr>
<td>[[User:Lulurun|lulurun]]</td>
<td>liu</td>
<td></td>
<td></td>
<td>+9</td>
<td>3Di Inc, Japan <br />http://www.3di.jp</td>
<td>patches, openid, server performance, UGAI</td>
</tr>

<tr>
<td>[[User:Mikem|mikem]]</td>
<td>Mike</td>
<td></td>
<td></td>
<td>+9</td>
<td>3Di Inc, Japan <br />http://www.3di.jp</td>
<td>patches, scripting improvements</td>
</tr>
<tr>
<td>[[User:Carlosroundel|Carlosrounde]]</td>
<td>Carlosroundel</td>
<td>Carlos Roundel</td>
<td></td>
<td>+1</td>
<td>Cyberlandia Italy<br />http://www.cyberlandia.net</td>
<td>grid, programmer, database, tester</td>
</tr>
</table>
[[Category:Main]]
[[Category:Development]]