Talk:Hypergrid

Revision as of 05:10, 4 February 2009

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...." Frank W Sweet 17:51, 3 February 2009 (UTC)

It doesn't make any of the assumptions you mention. (1) Standalones are here to stay and in fact, are they the base case of OpenSim. (2) You should always be careful with whom you trust your data with. The question we're debating here is who has access to your inventory (standalone or grided) when you are out and about in other grids. If your answer is that you don't want to be out and about in other grids, then you have nothing to add to this discussion. If you do want to be out and about and access your standalone inventory then think about what architecture would make sense. The current one, with the regions proxying access, is the worst possible architecture. The right thing to do is to have your viewer access your inventory directly, wherever your inventory is (standalone service included, which is already working in the HG) Diva

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 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 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.

I like this vision of independent services in abstract, but I'm not sure it's realistic to think of OpenSim without the bundle UGAIM in the near future, for a number of reasons, the most important being this one: I'm having a hard time envisioning people choosing organization A as the storage service, but organization U for their identity. Could you explain more about the users' motivation to do that if they have the option of choosing all of those services in a bundle. Also the companies' motivation -- why would a company interested in storage miss out on grabbing users and their eyeballs Diva

OK, I thought a little bit harder about this, and I can see a scenario where I would possibly want to access several inventory servers under one single identity. This: most of the time I use my UCI Grid identity, and I access my inventory stored in the UCI grid. However I also have my own personal standalone at home; I can imagine having more personal items in that OpenSim. It would be nice to be able to access my personal OpenSim inventory while I'm under the UCI Grid identity. In that case, using your examples, I would simply specify on my home inventory service: RW: http://grid.uci.edu/users/diva. Nice. This brings about a lot of questions, not just about the infrastructure but also about user interaction. I'm going to have to think a lot more about this. But I think that you and others who have been working on the distributed asset server idea need to explain a lot more about the motivation scenarios, to make it more accessible. Diva

ktweedy says:

My Vision for Asset/Inventory Servers

This is a really interesting subject that I think is really important to get it right to really enable the supply chain of content providers and content consumers to expand beyond what even Second Life is able to do. To me Second Life has lots of limitations in the management of content that makes it more expensive to develop, maintain and deliver which make developing content for people more expensive and difficult to get updates.

I break this problem down into four use cases. Content Creators, Content Distributors, Contents Consumers/Users, Content Viewers

1. Content Creators People that make content for sell. Things I believe content creators want.

A. Access to the asset server for their own assets to update them. If anyone has made content they know they will upload hundreds of copies of textures that they throw away. To me it would be better if I could just overwrite the old one. It would also save me time because all the places that use that texture would get updated. There may be some caching issues related to that but we have this on web pages now so I am sure it could be addressed.

B. Be able to update content without having to send out copies to everyone. In Second Life if I need to fix something and send out an update we have to go through sending tons of copies to everyone, which then they open. If just proliferates tones of copies. If I could fix something and then it is available to everyone with a cache refresh that would save tones of overhead for distributing updates. Also to me how will updates work on a multi-grid system, if I make an update how will people get to it, how will I send it to them if they aren't on my grid right now.

C. As a content creator I don't see how it will be possible to go around to hundreds of grids and setup stores and update stores. I will need to have one central location that I can license my content to avatars, to regions or to grids.

D. There are some content models that Second Life doesn't support. Like Dynamic textures. Each time we get a texture we can't assume that it is a disk file; it could be a URL to a web site that is making the texture on the fly. Also, people may want to buy a service from me that will make updates to the content every month like a picture viewer. If the content was a URL I could each month distribute new textures without the overhead of scripting totally controlled from my server. Or I could deliver different textures based on the time of the day. I could have changes in the look of my builds all controlled from a server. Someone goes to my website and selects a new look for their house as soon as their textures refresh their how would have a new look.

E. Textures or assets that are paid for monthly or some other time period and are only available while the service is being paid for. If I make textures I could sell based on a monthly fee to use any of my textures. If they decide to stop paying then I will be able to block their access to use them.

F. If I have my assets on my own server I would like to be able to assign the URL to the asset to the prim or avatar and not have to upload it into the grid asset server. I will also probably have to register in the grid something so that the region can serve that asset to people that come to the region to view it on my behalf.

2. Content Distributors A person that resells, distribute or host other people's content. XStreetSL could be this, but also Renderosity, RuntimeDNA some day and many new ones that will be coming. Also Avatar hosting services where you login to start your avatar and start running around on various grids.

A. I see content distributors very similar to content creators. I see these guys as avatar login providers or asset/inventory servers that content creators can use. If they are avatar servers then as I buy stuff and have it in inventory it will need to maintain copies of them and serve them as well as references to other asset servers and inventory servers that I have license use of content from.

3. Content Consumers/Users These are people that have purchased content, or possibly developed their own and have implemented into a region or are wearing the content.

A. As a content consumer I will want to be able to view my inventory by source which may be in different grids. I will need to know what is licensed to use where.

B. I would like to be able to view a listing of my rezzed objects and on what sims they are in, possibly even update them without having to go around to all of these places to do it.

C. I will need a way to open the profile, or support site of the content that I have license to use that may be sourced on another grid or asset/inventory server provider even if they do not have an avatar account in my current grid.

4. Content Viewers These are people that only have rights to view the content while they are in the sim or view the content of another avatar will it is in range. Their license has to be defined when they enter the grid that says their limited use of the content. (Note I think this is an issue in the current hypergrid in that when I hypergrid anywhere I am not required to accept a terms of use like I do if I make an account some where.

A. As a content viewer I may want to get information on the source of the asset so I can go there and look at the assets to buy them. Talk to the creator even if they so not have an account in the grid I am looking at the content in.

So I know I am presenting more than I am solving but mostly trying to expand the vision of what asset/inventory servers can be. Technically I know there are lots of issues to doing this. To me SL will not progress their viewer fast enough so I believe that there needs to be a new viewer that will support these concepts capabilities.

First time I have posted something on the site. Hope you guys find this interesting and helpful. --Ktweedy1 04:48, 4 February 2009 (UTC)

Ai Austin says:

Federated Virtual Worlds with Different Properties

The Hypergrid concept seems to be very well placed to allow for the wide range of types of topology, security management and asset exchange or mappings that will be needed in future for virtual worlds to be practically management and evolved.

It would be interesting to explore if the following could all be sported by the prop sowed architecture and mechanism:

• Ability to move between grids managed and served by separate communities (as now;
• Ability to limit regions open or closed to hypergrid travellers not authenticated directly on the visited grid (other preferably just seeing void spaces water);
• Ability to go into Grid with different capabilities (e.g. concierge supported meeting zones optimized for larger groups/conferences, etc.);
• Ability to enter a RexServer (rich 3D mesh) supported region from a standard region;
• Ability to move between Linden Grid and such Hypergrids via an OGP portal perhaps.

Can I also suggest we try to adopt a community name and perhaps even visual representation for the object in-world which can act as a portal to move between grids... I suggest "Hypergate" and I am using an object that looks and is coloured like the portals used at UCI Gateways 3000 and Gateway 7000.

We are preparing our own Hypergrid accessible grid, but it does need more thought on how to mange the areas we want open and those we want to remain limited. The group management framework within Opensim needs to mature before we can set that up better, and prevent accidental (or deliberate) loss or messing up of builds.