Talk:Hypergrid

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