Virtual World Model

Latest revision as of 23:04, 3 March 2012

 

Home

 

Download

 

News

 

Support

 

Admin

 

Dev

 

Screen Shots

 

Grid List

 

Bugs

Languages:

English

What follows are working definitions for the model of virtual worlds supported by OpenSimulator. They are intended to clarify terminology, and to sharpen the requirements with respect to security of users' data and world assets. Please use the Discussion tab to comment on these definitions -- they are live and subject to improvements.

Simulator Trust Domain: One or more simulators that completely trust each other, operated by one single 
authority. Trust means that these simulators can safely exchange messages and share data with each other. 
Specifically, trusting simulators can engage in exchanges that enable useful features, such as server-side 
teleports, that are unsafe when done between non-trusting simulators. Trust domains can be extended to include 
simulators in other trust domains, but in these extensions trust is neither commutative nor transitive. 
discuss here

Resource Services: A set of zero or more services serving resources for simulators. Resources include:
assets, user accounts, and assorted services like map, lookup, social networking, forums, etc. 

Grid: One or more simulators that share resources via resource services. At the very minimum, the 
simulators in a grid share assets, but many more services are possible (see above). A Grid includes one or 
more simulator trust domains. Normally one would expect one grid to be one single trust domain, but that 
doesn't necessarily need to happen. Given that a Grid may include more than one simulator 
trust domain, there can be untrusted connections within the same grid. In deploying security schemes, this 
needs to be taken into account. (OSGrid and trust domains...discuss here).  

Hypergrid: The interconnection of grids. Hypergrid simulator connections are necessarily untrusted, so 
security schemes need to take that into account. Besides safe simulator connectivity between grids, the 
Hypergrid addresses the interoperability of resource services -- that is, the ability for: user accounts in 
one user service being recognized in other grids; assets in one asset service being transferred to other 
grids; social networking services being bridged, etc. The Hypergrid architecture enables, but does not impose, 
the emergence of independent Hypergrid-wide resource services such as User Services, Asset Storage, Social 
Networking, Search, etc. that serve several grids and are not coupled with any one grid in particular.

Walled-Garden Grid: A grid that only handles resources directly managed by its own resource services. It 
does not recognize or allow users and assets from other grids, and it does not allow the export of its own 
users and assets. It may, however, import/export assets in bulk via backend storage systems (e.g. OARs).

Additional notes:

• Tentatively, I'm unifying the concept of Grid with the concept of Virtual World.

• A "Standalone", which should be read as "Standalone Grid" (term credit to Michael Cortez), is a grid-in-a-box. It's one process that single-handily performs simulation and resource management. Just like any other grid, a Standalone grid may be hypergrided or may operate as a walled garden.

• Simulator trust domains have ultimate freedom to implement any feature they want among themselves, including transferring user agents (user permitting), sharing private data, etc.

• Grids may exist without any services but asset services. [Note: could there be a grid without assets?!]

• Hypergrided Grids may treat all users equally or may treat their own users in special ways.

• Grids may provide visitors with additional resources that are only available while the users visit that grid, and become unavailable once the visitor goes elsewhere (aka grid-specific inventory).

More notes (Melanie's email, edited by Diva):

Users should be in control of their own inventory and its associated assets, independent of a single grid. This means:

• users can select where their data is stored. This may be an ISP, a web hoster, a grid or their own PC (bandwidth permitting). No simulator has authority over that storage.

• Regions hold COPIES of the assets needed to render whatever is currently in world. Normally, this will be "by value", e.g. the sim will have a full and valid copy of the data and be able to supply everything needed to render its content independent of any outside servers.

• Grids are one or more trust domains, they are groups of regions sharing asset and user services. They access the same servers for their data and anything within one region can be moved to any other region without the need to copy assets. Regions within a trust domain are able to destroy storage needed by other regions to render data, but cannot access user inventories unless authorized, and with very limited scope. Typically, but not mandatory, all sims in one gridwill be owned and operated by a single individual/organization.

• User services authenticate users for access to a trust domain. They may require username/password, X.509 certificates, oAuth, openID or any other form of authentication, or none. They may decree that, if you don't authenticate, your access may be limited to observation only, or in any other way they, as the trust domain controller, see fit.

• Sim asset services are the storage at the heart of a grid, sims in a grid share these asset services. That is distinct from user asset services, which are out of scope for regions.

• Optionally, user asset services may pass an object to a region "by reference". This assumes a basic level of trust with the region, which is advised to not keep a copy, but request the current data from the user asset service each time it is needed. This required continuous authorization for that item, which will be limited to specific sims, Therefore, such items can't leave the sim, they cannot be given or sold, but only be taken by the owner. This is useful for allowing the update of scripts in-place, e.g. for applications like sloodle, which may want to update all inworld terminals all at once. It it a marked departure from the Linden way of doing things.