[Opensim-dev] The essence of "grid"

Christian Scholz cs at comlounge.net
Thu Apr 16 15:49:46 UTC 2009


Good points!

Michael Cortez wrote:
> Just my pittance,
> 
> Assumptions: 
> * We want to create virtual space
> * We want to put this virtual space on networks to allow networked 
> viewers to enter and possibly interact
> * Some people may want to restrict what is and isn't allowed in their 
> virtual space, including who is allowed and what they can do while there
> * What we call a "Region" is simulation of a 256m x 256m region of 
> virtual space
> 
> My thoughts:
> 
> To me, a Grid is a virtual space that can be of any given size, and to 
> date, currently consists of one or more discrete Regions that are laid 
> out in a two dimensional grid pattern.  A Grid allows for these discrete 
> individual spaces to be joined together to provide a seamless virtual 
> space that viewers can traverse as if they were a single large simulation.

It might also serve as a point of new services which are based on these
regions, like providing a map.

> 
> A Grid can consist of just a single Region, or many Regions.
> 
> Within a Grid, it may be desirable to assign ownership of virtual space 
> to specific agents for administration.  Those agents, through their 
> viewers (or other means) should be able to determine who may enter their 
> space, what those visitors can do once there, including what 
> communications are available and what objects they may simulate.  
> Currently we determine areas of administration in 256m^2 regions of 
> space, that are then sub-divided by parcels.

This basically is the a region centric service which could have these
functions.

> To me the concept of a Region is inseparable from that of a Grid, 
> because a Grid is a simply a representation of space and a Region a 
> subset of that space.  Moving forward, the subsets of space within a 
> Grid may not be 256m x 256m, instead they may be 1m x 1m, or they may be 
> 1000m x 1000m -- currently we're using 256m^2 simply because the legacy 
> SL based viewers we have assume that regions of space within a Grid will 
> be that size.  We already have people that are "splitting" the 
> simulation of space represented by a Region, and the current 
> implementation of OpenSim already allows for a single simulation to 
> represent larger areas, albeit in 256m^2 chunks.

+1

> The various "grid services" -- such as users, inventory, assets, groups, 
> messaging -- are what determines who may or may not interact with the 
> virtual space, and what may or may not be placed within that virtual 
> space, and how those who are connected to that space may communicate 
> within and via that space.

I would like to add that these services actually can be outside the
influence of the grid. The grid can use them and maybe delegate access
to regions. Thus I wouldn't necessarily speak about them as "grid
services" as they might also be useful outside the grid context (e.g.
profiles, groups, IM, photos/texture assets)

> For what this means to Diva's original question, I'm not sure.  But 
> here's a few things to contemplate:
> 
> * If a subset of the assets an agent is going to use are solely in their 
> control, and they specifically have to grant permission for a simulation 
> to use those assets, then that negotiation should not be with a Region 
> or a specific instance of simulation, but instead with a Grid.  Because 
> in the seamless environment that a grid represents, a viewer who is 600m 
> away may be looking at your avatar -- and the simulation that the viewer 
> is in will need access to the assets that represent your appearance.  
> This scenario is a little clouded, but still true with existing 
> hypergrid regions now -- because every instance of OpenSim, is, in 
> itself a self contained "Grid."

Right, that's a good point and it does not need to be 600m, it also can
be simply one avatar on each sim border. Otherwise everything around
that sim would be simply black (as I would assume that it's also the
other way round: When a user enters a region it should also be checked
if the user is allowed to be there or actually should retrieve content
stored on that region. But here a grid based approach also makes more
sense. You might of course still "hide" objects for certain agents by
whatever means).

> * Just because something is called a trust domain, does not mean that I 
> trust it.  There are a lot of web sites out in the wild, each could be 
> considered to be a stand alone trust domain, and some via certificates 
> or other mechanisms join a larger trust domain, and I don't extend any 
> level of trust to them what'so'ever and would never provide them with 
> any personal data.  Other trust domains I will extend a little trust, 
> I'll give them my email address, a preferred user name/alias, and a 
> security token (password) that I will use just for them -- other trust 
> domains I extend full trust to and share much of my important personal 
> data with.  All that being a trust domain means, is that those members 
> within that domain will fall under the administration of, and policies 
> set forth by the trust domain -- if those policies are "Do what you 
> want, and here's some unsecured storage space you can use, and an 
> unverified database of users you can peruse", then as a user you must 
> decide what level of actual trust to extend.  Often people extend more 
> trust then they should through miss-understanding, for example people 
> extended trust to Linden Labs on the *assumption* that their assets 
> would be safe and protected from being copying within their trust domain 
> (Second Life) -- however LL never made any such promise, nor are they 
> even capable of enforcing such a policy {with a few exceptions including 
> scripts and personal data, such as CC #'s}.

That will always be a problem more of education than of technology. As I
said before I think in the moment of entering a new grid (which might
mean to show some TOS and grant access to one's resources) you should be
aware of what you are doing and what can happen. This will most probably
be described in the TOS one usually accepts without looking at it ;-)

-- Christian


-- 
Christian Scholz                          Homepage: http://comlounge.net
COM.lounge GmbH                              blog: http://mrtopf.de/blog
Hanbrucher Str. 33                                       Skype: HerrTopf
52064 Aachen                             Video Blog: http://comlounge.tv
Tel: +49 241 400 730 0                           E-Mail cs at comlounge.net
Fax: +49 241 979 00 850                               IRC: MrTopf, Tao_T

neuer Podcast: Der OpenWeb-Podcast (http://openweb-podcast.de)
new podcast: Data Without Borders (http://datawithoutborders.net)




More information about the Opensim-dev mailing list