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

(This is a first draft-version and can change at any time until complete
implementation. Feel free to comment, either on the Discussion page or on the
opensim-dev mailing list)

= Why =

The current RegionModule system's API is in part inconsistent and doesn't
really support region-restarts and adding/removing regions on the fly during
a region-server run.
E.g., the API says ''Initialise'' is called for every region (in every
region-module), after that, ''PostInitialise'' is called for every region-module.
When a new region is added, what should happen?
* Don't call ''Initialise'': Then the region-module isn't initialised for that region, which leads to missing functionality.
* Call ''Initialise'': Then ''PostInitialise'' was called too early. Actually, ''PostInitialise'' can not be called at all, because you can add a region after that anytime.

What should happen if a region is restarted? What should happen if a region
is removed?

= What =

The new region-module system is based on three interfaces: ''ISharedRegionModule'',
''INonSharedRegionModule'' and ''IRegionModuleBase'', which is the base interface for
the other two.

public interface IRegionModuleBase
{
string Name { get; }
void Initialise(IConfigSource source);
void Close();
void AddRegion(Scene scene);
void RegionLoaded(Scene scene);
void RemoveRegion(Scene scene);
}

public interface ISharedRegionModule : IRegionModuleBase
{
void PostInitialise();
}

public interface INonSharedRegionModule : IRegionModuleBase
{
}

* Loading the region-modules' classes happens via ''Mono.Addins'' on server-start.
* Instantiating the region-modules happens...
** for ''ISharedRegionModule''s once after loading (on server start)
** for ''INonSharedRegionModule''s after creation of the ''Scene'' object.
* You can cleanup when a region is removed.
* You can cleanup before the server shuts down.

;Note:
:A ''PostInitialise'' for a ''INonSharedRegionModule'' doesn't make a lot of sense, as we don't have a certain point from which on we won't call ''Initialise'' on a ''INonSharedRegionModule'' again. Every time a new region is added (on restart, too), a new instance is created and ''Initialise'' is called on that instance, so the intended semantics of ''PostInitialise'' will never apply.

= Details =

== Creating a region module assembly ==

You will need to add several attributes to your assembly and the extension classes in the assembly for Mono.Addins to recognize the .dll file as containing valid addins. Put the following anywhere in your library:

[assembly: Addin("MyAddin", "0.1")]
[assembly: AddinDependency("OpenSim", "0.5")]

And for each extension class use the attribute:

[Extension(Path="/OpenSim/RegionModules",NodeName="RegionModule")]

== Start of region-server ==

* Region-server starts, the classes of all region-modules are loaded in no particular order
** For every ''ISharedRegionModule'', one instance is created and ''Initialise'' is called.
** For every ''ISharedRegionModule'' instance, ''PostInitialise'' is called.
* The ''Scene''s are instantiated, one by one:
** For every ''Scene''
*** for every ''INonSharedRegionModule'', a new instance is created and ''Initialise'' called.
*** for every ''INonSharedRegionModule'' and ''ISharedRegionModule'', ''AddRegion(scene)'' is called. The modules are associated to the ''Scene'' (for deletion on remove)
*** for every ''INonSharedRegionModule'' and ''ISharedRegionModule'', ''RegionLoaded(scene)'' is called (you can access the methods in other modules of that scene via ''scene.RequestModuleInterface<ModuleInterfaceType>()'' here).

== Adding a region ==
* for every ''INonSharedRegionModule'', a new instance is created and ''Initialise'' called.
* for every ''INonSharedRegionModule'' and ''ISharedRegionModule'', ''AddRegion(scene)'' is called. The modules are associated to the ''Scene'' (for deletion on remove)
* for every ''INonSharedRegionModule'' and ''ISharedRegionModule'', ''RegionLoaded(scene)'' is called.

== Removing a region ==

* For every ''INonSharedRegionModule'' of the scene and every ''ISharedRegionModule'', ''RemoveRegion(scene)'' is called
** For the ''INonSharedRegionModule''s, ''Close'' is called
* Every module reference of the scene is removed from the scene. No references should be left after that; the ''INonSharedRegionModule''s could be garbage collected now.

== Restarting a region ==

Restarting happens as a sequence of [[#Removing_a_region|"Removing a region"]], followed by a
[[#Adding_a_region|"Adding a region"]]. As usual, avatars that are in that region when it restarts are kicked.

== Shutdown of the region-server ==

* For every scene, perform the [[#Removing_a_region|"Removing a region"]] step:
** ''RemoveRegion'' is called for all scenes and modules, ''Close'' is called for all the ''INonSharedRegionModule''s
* ''Close'' is called for all the ''ISharedRegionModule''. The ''ISharedRegionModule'' could now be garbage-collected.

= Notes =

* ''RemoveRegion''/''Close'' is for cleaning up. Things you added in ''Initialise''/''AddRegion'' should be removed in ''Close''/''RemoveRegion'' again, respectively.
* The modules are loaded via ''Mono.Addins''. This means, you can build your own assemblies with region modules, and by putting them into the ''<opensim>/bin'' folder, they will be loaded automatically. Make sure the correct attributes are set for the addin to be loaded correctly
: clear enough? Or should we add a spelled out example? [[User:HomerHorwitz|HomerHorwitz]] 18:21, 12 May 2009 (UTC)

= TODOs =
* Configuration about which modules should be loaded.
: we already have the <tt>enabled = true/false</tt> OpenSim.ini config option for most region modules --- [[User:DrScofield|DrScofield]] 09:53, 26 January 2009 (UTC)
: which is a horribly ad hoc solution - we really do need a better way of controlling this imho --- [[User:Justincc|Justincc]] 20:26, 28 January 2009 (UTC)
: agree with Justin. A module shouldn't be responsible for turning itself off, it should never get loaded in the first place --[[User:SeanDague|SeanDague]] 21:51, 28 January 2009 (UTC)

CableBeachProposal

2009-04-06T22:28:12Z

Jhurliman: /* Step 2: OpenID Login With web_login_key */

==Motivation==

Many virtual worlds are being developed independently with a wide variety of different architectures and protocols. The current generation of virtual worlds are implemented as proprietary stacks of services, where each world is not only simulating virtual space but also providing identity services, content hosting, digital rights management, instant messaging, virtual economies, social networking elements such as groups, and many other services. We believe there are shortcomings with this approach. Specifically:

# The barrier to entry for creating and running a virtual world is too high. Even with popular platforms such as OpenSim, grid administrators are taking on a monumental task of overseeing many or all of the above services when only a simple world simulation is needed.
# The all-or-nothing approach of the current protocols prevents the development of a robust virtual world ecosystem, where many specialized services are provided. Today's large stakeholders in content hosting, content delivery acceleration, identity services, and social networking have no means of entry to the virtual worlds space.
# Due to the walled garden nature of current worlds, third party services such as search and digital content creation tools have been almost entirely locked out of virtual worlds.

==Vision==

We envision virtual world grids modeled after the current World Wide Web, with millions of independent administrative domains. Content will be spread across millions of small, independent domains as well as aggregated on large domains supporting millions of users. A rich community of value added services and the free and open exchange of content will weave the network together, much as the Web 2.0 movement is tying the web together today. Every organization can choose what services they will run themselves, what services will be provided by third parties, and which third parties will provide services. Additionally, the content rights decisions are placed in the hands of the content hosts. With the proper authentication users are free to move assets to wherever they roam.

Data services will become as important as data hosting itself. Just as search engines and content portals have changed how we use the web, services that can plug into a common interface in asset hosting will change how we use virtual worlds. Auditing services can provide an approach to rights management and traffic analytics. Existing caching techniques and services that have been built for today's web content can be leveraged for delivery of rich virtual world content.

==Approach==

A roadmap has been designed to provide a migration from the current OpenSim implementation of the Second Life® protocol to a decentralized service protocol. The first step will provide some of the services in a disaggregated grid and will improve the security of existing models such as OSGrid's decentralized hosting with centralized trust. The second step will remove any assumptions about tightly coupled services and present a true decentralized virtual world service platform. Step 3 will remove any leftover baggage by making service authentication and authorization client-centric, and potentially enable new use cases such as multiple inventory servers or content migration.

==Step 1: Login With Existing LL Client==

[[Image:CableBeach_LL_Client_Login_1.png]]

# This step is the familiar XML-RPC login initiated from the Linden Lab client, passing a first name, last name, and md5 hash of the password. What is new here is that the login is sent directly to the grid server for a grid, since identities are no longer tightly coupled to grids.
# The login is forwarded to a known identity server. Note that because the client is providing a grid server with sensitive information (md5 hash of the agent password), and it does not provide a URL for the identity server, this form of login requires the grid server and a known identity server to exist in the same trust domain.
# The identity server holds profile information for each identity, which includes a list of URLs for various services. For each service, a temporary access token is requested.
# Each service grants a temporary access token back to the identity server.
# The login request successfully returns back to the grid server with information about the agent, the list of services, and access tokens for each service.
# The grid server determines which simulator the client will start in. This may be the closest available location to a requested destination, the agent's home simulator in this grid, or the default starting location for the grid.
# The grid server contacts the starting simulator to prepare the login. Information about the agent, the list of services for the agent, and the access tokens for each service are given to the simulator. The grid server uses its certificate as a client certificate so the simulator can authenticate the request.
# The simulator checks the presented client certificate and confirms it as being signed by the grid server. Preparations are made and a UDP circuit is created. The identifier for the waiting UDP circuit is passed back to the grid server with the success response.
# The grid server uses the access token it received for the inventory server to contact the inventory server and receive information about the agent inventory, including a skeleton of the folder structure and owner information.
# The inventory server checks the access token and confirms that it is a valid and non-expired token.
# Inventory information is returned to the grid server along with the success response.
# Agent information, inventory information, and the UDP circuit identifier are all returned to the client along with the success response.

==Step 2: OpenID Login With web_login_key==

[[Image:CableBeach_OpenID_Client_Login_1.png]]

This is the same login flow as the first diagram, but the client passes an OpenID identity URL to the grid server instead of login credentials. An OpenID login process is initiated with the identity server where the client supplies login credentials directly to the identity server. This removes the restriction that the grid server and identity server must be in the same trust domain.

==Step 3: Client-Centric World==

[TODO]

==Use Cases==

Several common virtual world operations are presented below. Teleporting between two regions in the same trust domain or between domains that have shared trust, teleporting between two untrusted domains, content publishing from digital content creation tools, and content migration between untrusted domains. [TODO]

===Trusted Teleport===

[[Image:CableBeach_Hypergrid_Trusted_Teleport_1.png]]

CableBeachProposal

2009-04-06T22:26:03Z

Jhurliman: /* Step 3: Client-Centric World */

==Motivation==

Many virtual worlds are being developed independently with a wide variety of different architectures and protocols. The current generation of virtual worlds are implemented as proprietary stacks of services, where each world is not only simulating virtual space but also providing identity services, content hosting, digital rights management, instant messaging, virtual economies, social networking elements such as groups, and many other services. We believe there are shortcomings with this approach. Specifically:

# The barrier to entry for creating and running a virtual world is too high. Even with popular platforms such as OpenSim, grid administrators are taking on a monumental task of overseeing many or all of the above services when only a simple world simulation is needed.
# The all-or-nothing approach of the current protocols prevents the development of a robust virtual world ecosystem, where many specialized services are provided. Today's large stakeholders in content hosting, content delivery acceleration, identity services, and social networking have no means of entry to the virtual worlds space.
# Due to the walled garden nature of current worlds, third party services such as search and digital content creation tools have been almost entirely locked out of virtual worlds.

==Vision==

We envision virtual world grids modeled after the current World Wide Web, with millions of independent administrative domains. Content will be spread across millions of small, independent domains as well as aggregated on large domains supporting millions of users. A rich community of value added services and the free and open exchange of content will weave the network together, much as the Web 2.0 movement is tying the web together today. Every organization can choose what services they will run themselves, what services will be provided by third parties, and which third parties will provide services. Additionally, the content rights decisions are placed in the hands of the content hosts. With the proper authentication users are free to move assets to wherever they roam.

Data services will become as important as data hosting itself. Just as search engines and content portals have changed how we use the web, services that can plug into a common interface in asset hosting will change how we use virtual worlds. Auditing services can provide an approach to rights management and traffic analytics. Existing caching techniques and services that have been built for today's web content can be leveraged for delivery of rich virtual world content.

==Approach==

A roadmap has been designed to provide a migration from the current OpenSim implementation of the Second Life® protocol to a decentralized service protocol. The first step will provide some of the services in a disaggregated grid and will improve the security of existing models such as OSGrid's decentralized hosting with centralized trust. The second step will remove any assumptions about tightly coupled services and present a true decentralized virtual world service platform. Step 3 will remove any leftover baggage by making service authentication and authorization client-centric, and potentially enable new use cases such as multiple inventory servers or content migration.

==Step 1: Login With Existing LL Client==

[[Image:CableBeach_LL_Client_Login_1.png]]

# This step is the familiar XML-RPC login initiated from the Linden Lab client, passing a first name, last name, and md5 hash of the password. What is new here is that the login is sent directly to the grid server for a grid, since identities are no longer tightly coupled to grids.
# The login is forwarded to a known identity server. Note that because the client is providing a grid server with sensitive information (md5 hash of the agent password), and it does not provide a URL for the identity server, this form of login requires the grid server and a known identity server to exist in the same trust domain.
# The identity server holds profile information for each identity, which includes a list of URLs for various services. For each service, a temporary access token is requested.
# Each service grants a temporary access token back to the identity server.
# The login request successfully returns back to the grid server with information about the agent, the list of services, and access tokens for each service.
# The grid server determines which simulator the client will start in. This may be the closest available location to a requested destination, the agent's home simulator in this grid, or the default starting location for the grid.
# The grid server contacts the starting simulator to prepare the login. Information about the agent, the list of services for the agent, and the access tokens for each service are given to the simulator. The grid server uses its certificate as a client certificate so the simulator can authenticate the request.
# The simulator checks the presented client certificate and confirms it as being signed by the grid server. Preparations are made and a UDP circuit is created. The identifier for the waiting UDP circuit is passed back to the grid server with the success response.
# The grid server uses the access token it received for the inventory server to contact the inventory server and receive information about the agent inventory, including a skeleton of the folder structure and owner information.
# The inventory server checks the access token and confirms that it is a valid and non-expired token.
# Inventory information is returned to the grid server along with the success response.
# Agent information, inventory information, and the UDP circuit identifier are all returned to the client along with the success response.

==Step 2: OpenID Login With web_login_key==

[[Image:CableBeach_OpenID_Client_Login_1.png]]

==Step 3: Client-Centric World==

[TODO]

==Use Cases==

Several common virtual world operations are presented below. Teleporting between two regions in the same trust domain or between domains that have shared trust, teleporting between two untrusted domains, content publishing from digital content creation tools, and content migration between untrusted domains. [TODO]

===Trusted Teleport===

[[Image:CableBeach_Hypergrid_Trusted_Teleport_1.png]]

CableBeachProposal

2009-04-06T22:25:45Z

Jhurliman:

==Motivation==

Many virtual worlds are being developed independently with a wide variety of different architectures and protocols. The current generation of virtual worlds are implemented as proprietary stacks of services, where each world is not only simulating virtual space but also providing identity services, content hosting, digital rights management, instant messaging, virtual economies, social networking elements such as groups, and many other services. We believe there are shortcomings with this approach. Specifically:

# The barrier to entry for creating and running a virtual world is too high. Even with popular platforms such as OpenSim, grid administrators are taking on a monumental task of overseeing many or all of the above services when only a simple world simulation is needed.
# The all-or-nothing approach of the current protocols prevents the development of a robust virtual world ecosystem, where many specialized services are provided. Today's large stakeholders in content hosting, content delivery acceleration, identity services, and social networking have no means of entry to the virtual worlds space.
# Due to the walled garden nature of current worlds, third party services such as search and digital content creation tools have been almost entirely locked out of virtual worlds.

==Vision==

We envision virtual world grids modeled after the current World Wide Web, with millions of independent administrative domains. Content will be spread across millions of small, independent domains as well as aggregated on large domains supporting millions of users. A rich community of value added services and the free and open exchange of content will weave the network together, much as the Web 2.0 movement is tying the web together today. Every organization can choose what services they will run themselves, what services will be provided by third parties, and which third parties will provide services. Additionally, the content rights decisions are placed in the hands of the content hosts. With the proper authentication users are free to move assets to wherever they roam.

Data services will become as important as data hosting itself. Just as search engines and content portals have changed how we use the web, services that can plug into a common interface in asset hosting will change how we use virtual worlds. Auditing services can provide an approach to rights management and traffic analytics. Existing caching techniques and services that have been built for today's web content can be leveraged for delivery of rich virtual world content.

==Approach==

A roadmap has been designed to provide a migration from the current OpenSim implementation of the Second Life® protocol to a decentralized service protocol. The first step will provide some of the services in a disaggregated grid and will improve the security of existing models such as OSGrid's decentralized hosting with centralized trust. The second step will remove any assumptions about tightly coupled services and present a true decentralized virtual world service platform. Step 3 will remove any leftover baggage by making service authentication and authorization client-centric, and potentially enable new use cases such as multiple inventory servers or content migration.

==Step 1: Login With Existing LL Client==

[[Image:CableBeach_LL_Client_Login_1.png]]

# This step is the familiar XML-RPC login initiated from the Linden Lab client, passing a first name, last name, and md5 hash of the password. What is new here is that the login is sent directly to the grid server for a grid, since identities are no longer tightly coupled to grids.
# The login is forwarded to a known identity server. Note that because the client is providing a grid server with sensitive information (md5 hash of the agent password), and it does not provide a URL for the identity server, this form of login requires the grid server and a known identity server to exist in the same trust domain.
# The identity server holds profile information for each identity, which includes a list of URLs for various services. For each service, a temporary access token is requested.
# Each service grants a temporary access token back to the identity server.
# The login request successfully returns back to the grid server with information about the agent, the list of services, and access tokens for each service.
# The grid server determines which simulator the client will start in. This may be the closest available location to a requested destination, the agent's home simulator in this grid, or the default starting location for the grid.
# The grid server contacts the starting simulator to prepare the login. Information about the agent, the list of services for the agent, and the access tokens for each service are given to the simulator. The grid server uses its certificate as a client certificate so the simulator can authenticate the request.
# The simulator checks the presented client certificate and confirms it as being signed by the grid server. Preparations are made and a UDP circuit is created. The identifier for the waiting UDP circuit is passed back to the grid server with the success response.
# The grid server uses the access token it received for the inventory server to contact the inventory server and receive information about the agent inventory, including a skeleton of the folder structure and owner information.
# The inventory server checks the access token and confirms that it is a valid and non-expired token.
# Inventory information is returned to the grid server along with the success response.
# Agent information, inventory information, and the UDP circuit identifier are all returned to the client along with the success response.

==Step 2: OpenID Login With web_login_key==

[[Image:CableBeach_OpenID_Client_Login_1.png]]

==Step 3: Client-Centric World==

==Use Cases==

Several common virtual world operations are presented below. Teleporting between two regions in the same trust domain or between domains that have shared trust, teleporting between two untrusted domains, content publishing from digital content creation tools, and content migration between untrusted domains. [TODO]

===Trusted Teleport===

[[Image:CableBeach_Hypergrid_Trusted_Teleport_1.png]]

CableBeachProposal

2009-04-06T21:05:01Z

CableBeachProposal

2009-04-06T21:00:36Z

Jhurliman:

==LL Client Login==

# This step is the familiar XML-RPC login initiated from the Linden Lab client, passing a first name, last name, and md5 hash of the password. What is new here is that the login is sent directly to the grid server for a grid, since identities are no longer tightly coupled to grids.
# The login is forwarded to a known identity server. Note that because the client is providing a grid server with sensitive information (md5 hash of the agent password), and it does not provide a URL for the identity server, this form of login requires the grid server and a known identity server to exist in the same trust domain.
# The identity server holds profile information for each identity, which includes a list of URLs for various services. For each service, a temporary access token is requested.
# Each service grants a temporary access token back to the identity server.
# The login request successfully returns back to the grid server with information about the agent, the list of services, and access tokens for each service.
# The grid server determines which simulator the client will start in. This may be the closest available location to a requested destination, the agent's home simulator in this grid, or the default starting location for the grid.
# The grid server contacts the starting simulator to prepare the login. Information about the agent, the list of services for the agent, and the access tokens for each service are given to the simulator. The grid server uses its certificate as a client certificate so the simulator can authenticate the request.
# The simulator checks the presented client certificate and confirms it as being signed by the grid server. Preparations are made and a UDP circuit is created.
# The identifier for the waiting UDP circuit is passed back to the grid server with the success response.
# The grid server uses the access token it received for the inventory server to contact the inventory server and receive information about the agent inventory, including a skeleton of the folder structure and owner information.
# The inventory server checks the access token and confirms that it is a valid and non-expired token.
# Inventory information is returned to the grid server along with the success response.
# Agent information, inventory information, and the UDP circuit identifier are all returned to the client along with the success response.

==OpenID Client Login==

==Hypergrid Trusted Teleport==

CableBeachProposal

2009-04-06T21:00:19Z

Jhurliman: New page: ==LL Client Login== # This step is the familiar XML-RPC login initiated from the Linden Lab client, passing a first name, last name, and md5 hash of the password. What is new here is that...

==LL Client Login==

# This step is the familiar XML-RPC login initiated from the Linden Lab client, passing a first name, last name, and md5 hash of the password. What is new here is that the login is sent directly to the grid server for a grid, since identities are no longer tightly coupled to grids.

# The login is forwarded to a known identity server. Note that because the client is providing a grid server with sensitive information (md5 hash of the agent password), and it does not provide a URL for the identity server, this form of login requires the grid server and a known identity server to exist in the same trust domain.

# The identity server holds profile information for each identity, which includes a list of URLs for various services. For each service, a temporary access token is requested.

# Each service grants a temporary access token back to the identity server.

# The login request successfully returns back to the grid server with information about the agent, the list of services, and access tokens for each service.

# The grid server determines which simulator the client will start in. This may be the closest available location to a requested destination, the agent's home simulator in this grid, or the default starting location for the grid.

# The grid server contacts the starting simulator to prepare the login. Information about the agent, the list of services for the agent, and the access tokens for each service are given to the simulator. The grid server uses its certificate as a client certificate so the simulator can authenticate the request.

# The simulator checks the presented client certificate and confirms it as being signed by the grid server. Preparations are made and a UDP circuit is created.

# The identifier for the waiting UDP circuit is passed back to the grid server with the success response.

# The grid server uses the access token it received for the inventory server to contact the inventory server and receive information about the agent inventory, including a skeleton of the folder structure and owner information.

# The inventory server checks the access token and confirms that it is a valid and non-expired token.

# Inventory information is returned to the grid server along with the success response.

# Agent information, inventory information, and the UDP circuit identifier are all returned to the client along with the success response.

==OpenID Client Login==

==Hypergrid Trusted Teleport==

File:Simian-child-agents.png

2009-03-13T19:58:52Z

Jhurliman: uploaded a new version of "Image:Simian-child-agents.png"

Simian

2009-03-13T19:54:19Z

Jhurliman: New page: ==Grid Layer== ===Child Agent Establishment=== Image:Simian-child-agents.png ==Client Layer==

==Grid Layer==

===Child Agent Establishment===

[[Image:Simian-child-agents.png]]

==Client Layer==

File:Simian-child-agents.png

2009-03-13T19:53:44Z

Jhurliman:

Talk:Hypergrid

2009-02-03T18:02:20Z

Jhurliman: Formatting cleanup

'''Diva says:'''

== Some thoughts on how to go about inventory security ==

These thoughts pertain to the problem of inventory security only, not to the other issue of potential property piracy after a sale.

The very first decision point is whether we want to continue to be compatible with Linden Lab's official viewer or whether we should start looking for alternative viewers that are more in sync with where OpenSim is going. Here's why.

Technically, the viewer plays a leading role in this story. Linden Lab's architecture has the viewer always contact the regions for inventory asset downloads. I'm not sure why they did this, but that's how things are. By doing this, there is implicitly a trust relation between the viewer and the region with respect to assets: the viewer requests the inventory assets to the region which, in turn, fetches them from the asset server and then sends them to the viewer; the user trusts that the region is not going to steal or delete or infect those inventory assets. This works well in closed systems like Linden Lab's, but it's terrible for open systems, where different regions are controlled by different people. We really can't trust the regions in general!

=== Alternative Architecture ===

The obvious alternative to that is to have the viewer contact the inventory/asset server(s) directly for all operations related to inventory manipulation, without having the region in between. This would solve *all* the inventory security issues we face by abiding to LL's architecture. Granted, this is a radical architectural change, and I'm not even sure I can foresee all the consequences. It's just makes a lot of sense to me, intuitively. Regions should never be trusted with the users' confidential data, and the viewer should be a hub for interaction with lots of servers that the user needs to interact with. The region should stay out of it.
:This solution makes two unjustified assumptions. (1) All regions are on a grid with a separate asset server. (2) Grid assets servers are trustworthy. The first assumption ignores the proliferation of standalone sims with built-in asset servers, unconnected to any grid. That the metaverse will come more and more to resemble the anarchy of websites may disturb some. But that is what is happening, like it or not. The second assumption is also false, as demonstrated by Linden Labs. I, like many former SL users, was ripped off by Linden Lab's policy changes depriving me of paid-up (openspace) land and months of construction labor without even refunding my initial fee. Never again will I or others like me trust anyone else with the fruits of my labor. My assets will always remain in my possession on my own asset server. As the Scots put it, "Fool me once, shame on you, fool me twice...." [[User:FrankWSweet|Frank W Sweet]] 17:51, 3 February 2009 (UTC)

=== Back to Reality ===

OK, so that probably won't happen any time soon, not in the official LL viewer, and not in all the other derivative viewers out there (anyone wants to prove me wrong? I would love that! :-). What's the next best thing?

* An extra flag in the item's Properties indicating that the item is to be shared with foreign regions. In this case the inventory server can selectively send the user's inventory to the foreign regions, sending only those item marked with that flag. This requires a small change in the viewer to add that extra flag and send out the corresponding bit in a message to the inventory server. However, we need to figure out a way to coerce the viewer to make that contact to the inventory server directly without going through the region, otherwise the region may just flip the bit; we're not sure how to do this.

* A coarse-grained selection via the concept of Suitcase (explained [[Hypergrid_Inventory_Access | here]]). This is the simplest thing to do, it doesn't require any changes to the viewer.

------------------
'''John says:'''

== Moving Away from Local vs. Foreign ==

I think this is making too many assumptions about "local" vs. "foreign". An inventory or asset server should be an independent concept from a simulator or grid of simulators. Requiring that I define one grid as my local grid if I go into the content storage/distribution business places a lot of burden on the Akamai's and AmazonS3's of the metaverse. If an inventory server is an independent service, every grid becomes foreign. Maybe my ACL looks like this:

RW: http://grid.uci.edu/users/diva
RW: http://osgrid.org/users/*
R: *

And a second level of checks would further restrict read access. Everyone can grab a texture if they know the UUID (in this particular config), but only the owner of a script can access it unless someone owns an inventory item giving them read access. Maybe someone is trying to setup a walled garden grid, and the ACL looks like this:

RW: http://identity.ibm.com/users/*

The only hurdle left is how to delegate trust so simulators can access the content they need without compromising identity or additional assets/inventory. One solution could be Google's recently released spec on combining [http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html OpenID+OAuth]. OAuth was designed for exactly this purpose; to delegate limited trust to an automated service without having to give away your login credentials.

One big plus with this approach is that it should be feasible without rewriting the Linden Lab viewer. The LL viewer already makes heavy use of capabilities, which is just another way of using access tokens to talk to services. Inventory is supposed to be switched over to all CAPS in the near future (libOpenMetaverse and OpenSim devs are surely cringing) which means OAuth tokens could be mangled into CAPS URLs and handed to the client to make things work seamlessly.

In practice, the simulator never needs access to inventory (except in the current scenario where inventory is proxied through the simulator, which is going away soon). It does need access to some assets. An additional CAPS URL could be generated that is stored on the simulator side and handed around with HyperGrid teleports that allows limited access. In a tightly coupled grid approach, logging in to the user server alleviates the need to do a direct OpenID login to an asset server, which gives you the entire security model without the client ever understanding what OpenID or OAuth are. However, you can still use your third party tools to communicate directly with the inventory/asset server using OpenID (and optionally OAuth).

The downside is that this still requires some notion of tight coupling to make the backward compatible paths work (logging into the user server pings a local asset/inventory server to prevent the need for a second login). However, this is no different from today's setup and it provides a roadmap to completely decentralizing grid services.

Talk:Hypergrid

2009-02-03T18:00:11Z

Jhurliman: John's comments

'''Diva says:'''

== Some thoughts on how to go about inventory security ==

These thoughts pertain to the problem of inventory security only, not to the other issue of potential property piracy after a sale.

The very first decision point is whether we want to continue to be compatible with Linden Lab's official viewer or whether we should start looking for alternative viewers that are more in sync with where OpenSim is going. Here's why.

Technically, the viewer plays a leading role in this story. Linden Lab's architecture has the viewer always contact the regions for inventory asset downloads. I'm not sure why they did this, but that's how things are. By doing this, there is implicitly a trust relation between the viewer and the region with respect to assets: the viewer requests the inventory assets to the region which, in turn, fetches them from the asset server and then sends them to the viewer; the user trusts that the region is not going to steal or delete or infect those inventory assets. This works well in closed systems like Linden Lab's, but it's terrible for open systems, where different regions are controlled by different people. We really can't trust the regions in general!

=== Alternative Architecture ===

The obvious alternative to that is to have the viewer contact the inventory/asset server(s) directly for all operations related to inventory manipulation, without having the region in between. This would solve *all* the inventory security issues we face by abiding to LL's architecture. Granted, this is a radical architectural change, and I'm not even sure I can foresee all the consequences. It's just makes a lot of sense to me, intuitively. Regions should never be trusted with the users' confidential data, and the viewer should be a hub for interaction with lots of servers that the user needs to interact with. The region should stay out of it.
:This solution makes two unjustified assumptions. (1) All regions are on a grid with a separate asset server. (2) Grid assets servers are trustworthy. The first assumption ignores the proliferation of standalone sims with built-in asset servers, unconnected to any grid. That the metaverse will come more and more to resemble the anarchy of websites may disturb some. But that is what is happening, like it or not. The second assumption is also false, as demonstrated by Linden Labs. I, like many former SL users, was ripped off by Linden Lab's policy changes depriving me of paid-up (openspace) land and months of construction labor without even refunding my initial fee. Never again will I or others like me trust anyone else with the fruits of my labor. My assets will always remain in my possession on my own asset server. As the Scots put it, "Fool me once, shame on you, fool me twice...." [[User:FrankWSweet|Frank W Sweet]] 17:51, 3 February 2009 (UTC)

=== Back to Reality ===

OK, so that probably won't happen any time soon, not in the official LL viewer, and not in all the other derivative viewers out there (anyone wants to prove me wrong? I would love that! :-). What's the next best thing?

* An extra flag in the item's Properties indicating that the item is to be shared with foreign regions. In this case the inventory server can selectively send the user's inventory to the foreign regions, sending only those item marked with that flag. This requires a small change in the viewer to add that extra flag and send out the corresponding bit in a message to the inventory server. However, we need to figure out a way to coerce the viewer to make that contact to the inventory server directly without going through the region, otherwise the region may just flip the bit; we're not sure how to do this.

* A coarse-grained selection via the concept of Suitcase (explained [[Hypergrid_Inventory_Access | here]]). This is the simplest thing to do, it doesn't require any changes to the viewer.

'''John says:'''

== Moving Away from Local vs. Foreign ==

I think this is making too many assumptions about "local" vs. "foreign". An inventory or asset server should be an independent concept from a simulator or grid of simulators. Requiring that I define one grid as my local grid if I go into the content storage/distribution business places a lot of burden on the Akamai's and AmazonS3's of the metaverse. If an inventory server is an independent service, every grid becomes foreign. Maybe my ACL looks like this:

RW: http://grid.uci.edu/users/diva
RW: http://osgrid.org/users/*
R: *

And a second level of checks would further restrict read access. Everyone can grab a texture if they know the UUID (in this particular config), but only the owner of a script can access it unless someone owns an inventory item giving them read access. Maybe someone is trying to setup a walled garden grid, and the ACL looks like this:

RW: http://identity.ibm.com/users/*

The only hurdle left is how to delegate trust so simulators can access the content they need without compromising identity or additional assets/inventory. One solution could be Google's recently released spec on combining [http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html OpenID+OAuth]. OAuth was designed for exactly this purpose; to delegate limited trust to an automated service without having to give away your login credentials.

One big plus with this approach is that it should be feasible without rewriting the Linden Lab viewer. The LL viewer already makes heavy use of capabilities, which is just another way of using access tokens to talk to services. Inventory is supposed to be switched over to all CAPS in the near future (libOpenMetaverse and OpenSim devs are surely cringing) which means OAuth tokens could be mangled into CAPS URLs and handed to the client to make things work seamlessly.

In practice, the simulator never needs access to inventory (except in the current scenario where inventory is proxied through the simulator, which is going away soon). It does need access to some assets. An additional CAPS URL could be generated that is stored on the simulator side and handed around with HyperGrid teleports that allows limited access. In a tightly coupled grid approach, logging in to the user server alleviates the need to do a direct OpenID login to an asset server, which gives you the entire security model without the client ever understanding what OpenID or OAuth are. However, you can still use your third party tools to communicate directly with the inventory/asset server using OpenID (and optionally OAuth).

The downside is that this still requires some notion of tight coupling to make the backward compatible paths work (logging into the user server pings a local asset/inventory server to prevent the need for a second login). However, this is no different from today's setup and it provides a roadmap to completely decentralizing grid services.

AssetServerProposal/Verse

2009-01-21T00:37:56Z

Jhurliman: Updating progress

To turn Cable Beach into a [http://verse.blender.org/faq/ Verse] host, the Verse protocol needs to be implemented in C#. There was a previous effort to wrap libverse using P/Invoke, but this is now a dead project.

==Work Required==

Create a C# Verse library that implements:

* <s>RSA encryption for login</s>
* <s>The modified XOR encryption used for packet encryption</s>
* <s>UDP server (the libomv UDP server can be used here)</s>
* Callback to connect login attempts to an authorization backend
* <s>Subscription commands for clients to subscribe to different data types</s>
* Geometry node command decoding
* <s>Command callback system</s>
* <s>Packet serialization/deserialization</s>
* Packet queuing (logging) system for incoming and outgoing, with event compression (searching for old commands to make obsolete)
* ACK/NAK system
* Ordered transmission mode for non-idempotent commands
* <s>Decoders for each message type that connect packets to callbacks and take action such as broadcasting the packet or sending it back to the client</s>

===Estimate===

A basic implementation (possibly only supporting one or two types of nodes) should be possible in two weeks or less. Once this library is created, a VerseFrontend.cs could be started for Cable Beach to create a Verse host. Some form of Verse file format would have to be created to make use of the storage backends, and logic would need to be added to balance between overloading the storage backend with small updates and potentially losing data by not saving to disk. This might take up to another two weeks. Finally, an OpenSim (realXtend server?) Verse client could be written that subscribes to geometry data and converts subdivision surfaces into polygon meshes. The complexity of this depends on availability of algorithms to convert subdivision surfaces into polygons, and the amount of work required to inject new mesh objects into the OpenSim scene. A rough estimate would be one week.

Total project time: Five weeks

AssetServerProposal/Verse

2009-01-20T21:04:13Z

Jhurliman: Updating the page with current progress

To turn Cable Beach into a [http://verse.blender.org/faq/ Verse] host, the Verse protocol needs to be implemented in C#. There was a previous effort to wrap libverse using P/Invoke, but this is now a dead project.

==Work Required==

Create a C# Verse library that implements:

* <s>RSA encryption for login</s>
* <s>The modified XOR encryption used for packet encryption</s>
* <s>UDP server (the libomv UDP server can be used here)</s>
* Callback to connect login attempts to an authorization backend
* Subscription service (for clients to subscribe to different data types) with four unique states for each node in common data, three states per object node, two states per geometry node, one state per material node, two states per bitmap node, two states per text node, two states per curve node, and three states per audio node
* Basic Node class or interface
* Object, Geometry, Material, Bitmap, Text, Audio and Curve nodes
* Custom layers for each node type
* <s>Command callback system</s>
* <s>Packet serialization/deserialization</s>
* Packet queuing (logging) system for incoming and outgoing, with event compression (searching for old commands to make obsolete)
* ACK/NAK system
* Ordered transmission mode for non-idempotent commands
* <s>Decoders for each message type that connect packets to callbacks and take action such as broadcasting the packet or sending it back to the client</s>

===Estimate===

A basic implementation (possibly only supporting one or two types of nodes) should be possible in two weeks or less. Once this library is created, a VerseFrontend.cs could be started for Cable Beach to create a Verse host. Some form of Verse file format would have to be created to make use of the storage backends, and logic would need to be added to balance between overloading the storage backend with small updates and potentially losing data by not saving to disk. This might take up to another two weeks. Finally, an OpenSim (realXtend server?) Verse client could be written that subscribes to geometry data and converts subdivision surfaces into polygon meshes. The complexity of this depends on availability of algorithms to convert subdivision surfaces into polygons, and the amount of work required to inject new mesh objects into the OpenSim scene. A rough estimate would be one week.

Total project time: Five weeks

AssetServerProposal/Verse

2009-01-15T23:29:17Z

Jhurliman: New page: To turn Cable Beach into a [http://verse.blender.org/faq/ Verse] host, the Verse protocol needs to be implemented in C#. There was a previous effort to wrap libverse using P/Invoke, but th...

To turn Cable Beach into a [http://verse.blender.org/faq/ Verse] host, the Verse protocol needs to be implemented in C#. There was a previous effort to wrap libverse using P/Invoke, but this is now a dead project.

==Work Required==

Create a C# Verse library that implements:

* RSA encryption for login (may require big integer support, there is a Mono library for this)
* The modified XOR encryption used for packet encryption
* UDP server (the libomv UDP server can be used here)
* Callback to connect login attempts to an authorization backend
* Subscription service (for clients to subscribe to different data types) with four unique states for each node in common data, three states per object node, two states per geometry node, one state per material node, two states per bitmap node, two states per text node, two states per curve node, and three states per audio node
* Basic Node class or interface
* Object, Geometry, Material, Bitmap, Text, Audio and Curve nodes
* Custom layers for each node type
* Callback defined for each command
* Packet serialization/deserialization
* Packet queuing (logging) system for incoming and outgoing, with event compression (searching for old commands to make obsolete)
* ACK/NAK system
* Ordered transmission mode for non-idempotent commands
* Decoders for each message type that connect packets to callbacks and take action such as broadcasting the packet or sending it back to the client

===Estimate===

A basic implementation (possibly only supporting one or two types of nodes) should be possible in six weeks or less. Once this library is created, a VerseFrontend.cs could be started for Cable Beach to create a Verse host. Some form of Verse file format would have to be created to make use of the storage backends, and logic would need to be added to balance between overloading the storage backend with small updates and potentially losing data by not saving to disk. This might take up to another two weeks. Finally, an OpenSim (realXtend server?) Verse client could be written that subscribes to geometry data and converts subdivision surfaces into polygon meshes. The complexity of this depends on availability of algorithms to convert subdivision surfaces into polygons, and the amount of work required to inject new mesh objects into the OpenSim scene. A rough estimate would be one week.

Total project time: Nine weeks