[Opensim-dev] The essence of "grid"

[DZO]

"I can't visualize Bank of America using opensim for transactions."

Why not?

IBM is already providing "meeting room space" for companies. I guess each
room would then be a subset of a region with different access rights.

Personally I can't visualise that opensim will remain a secondlife clone. It
has too much potential. I really think design choices should be made in such
a way as to promote diversity, rather than based on what we can visualise
today.



-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of
opensim-dev-request at lists.berlios.de
Sent: 16 April 2009 17:24
To: opensim-dev at lists.berlios.de
Subject: Opensim-dev Digest, Vol 20, Issue 54

Send Opensim-dev mailing list submissions to
	opensim-dev at lists.berlios.de

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.berlios.de/mailman/listinfo/opensim-dev
or, via email, send a message with subject or body 'help' to
	opensim-dev-request at lists.berlios.de

You can reach the person managing the list at
	opensim-dev-owner at lists.berlios.de

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Opensim-dev digest..."


Today's Topics:

   1. Re: The essence of "grid" (Brianna)
   2. Re: Springs, Torques, joints , friction, questions and
      Vehicles oh my (Michael Cortez)
   3. Re: Mysql help request (Giorgio Servillo)
   4. Re: The essence of "grid" (Michael Cortez)


----------------------------------------------------------------------

Message: 1
Date: Thu, 16 Apr 2009 05:14:17 -0700
From: "Brianna" <wwwench at gmail.com>
Subject: Re: [Opensim-dev] The essence of "grid"
To: <opensim-dev at lists.berlios.de>
Message-ID: <89A813BE97FC424C892C8544CD1F0303 at BoscoPC>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original

"opensim should have a very simple region based password system"

Sounds like a re-invented 1996 Palace Chat, based on rooms. I can't
visualize Bank of America using opensim for transactions. So the security
should fit the threat of loss vs the inconvenience to users mobility.
If such a system comes into being, please map in red so to avoid those
grids.

----- Original Message -----
From: "DZO" <dzo at cybertalon.net>
To: <opensim-dev at lists.berlios.de>
Sent: Thursday, April 16, 2009 3:41 AM
Subject: Re: [Opensim-dev] The essence of "grid"


>I like to think of opensim as the VW version of Apache.
>
> I think something that is confusing us is that moving from region to 
> region
> in opensim is pratically seemless, and the joins between the regions 
> almost
> invisible. IE when walking from one region to another, you can see the new
> region appearing on the horizon, as if its just a continuation of the 
> region
> you are in.
>
> In apache you can also move between sites / pages, but the change is much
> more visible, you have to actually click on a link and move away from your
> current page, its obvious that you have gone from one area to another, 
> more
> so when moving between sites.
>
> Both opensim regions and apache(internet) sites allow you to move between
> content hosted by different people and/or on different servers. I believe
> THIS is the area where the confusion comes in. In the conventional 
> internet
> we don't mind typing a zillion passwords because we can obviously see that
> the pages are different. But in opensim it would seem strange to type in a
> password just to be able to take an extra step on the road you are already
> on.
>
> Personal opinion:
> - I don't believe centralising user profiles and managing permissions from
> there is a good idea for an open source project.
> - I do believe, as I have mentioned earlier, that opensim should have a 
> very
> simple region based password system and the client should be allowed to
> manage multiple passwords such as a messenger or email application. This
> would divide the task of security up between components in an equal and
> logical way.
>
> So opensim would allow grids and regions to ask for passwords from 
> different
> user server components, and the client software would allow the creation 
> of
> a user profile with multiple saved passwords.
>
> This would not break anything as it stands as it would be possible to set 
> a
> region security to "grid" so anyone allowed to used the grid would also be
> able to use the regions, however, a region owner would be able to restrict
> useage in their own region and take ownership of their own user base, 
> while
> managing their own hardware and content useage. This would facilitate 
> social
> groups, business interests, and various other applications for the VW.
>
> In my view:
> Grid: Hosting company
> Region: Web page (perhaps only using the hosting company to link to a
> private server)
>
>
>
>
>
>
> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of
> opensim-dev-request at lists.berlios.de
> Sent: 16 April 2009 01:01
> To: opensim-dev at lists.berlios.de
> Subject: Opensim-dev Digest, Vol 20, Issue 51
>
> Send Opensim-dev mailing list submissions to
> opensim-dev at lists.berlios.de
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> or, via email, send a message with subject or body 'help' to
> opensim-dev-request at lists.berlios.de
>
> You can reach the person managing the list at
> opensim-dev-owner at lists.berlios.de
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of Opensim-dev digest..."
>
>
> Today's Topics:
>
>   1. Re: The essence of "grid" (Thomas Grimshaw)
>   2. Re: The essence of "grid" (Diva Canto)
>   3. Re: The essence of "grid" (Charles Krinke)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 15 Apr 2009 22:41:57 +0100
> From: Thomas Grimshaw <tom at streamsense.net>
> Subject: Re: [Opensim-dev] The essence of "grid"
> To: opensim-dev at lists.berlios.de
> Message-ID: <49E654A5.5080300 at streamsense.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Charles Krinke wrote:
>> At this point, the only way to stop a region from attaching to an
>> OpenSim grid is to put a fake entry into the regions table.
> Or.. change the password?
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 15 Apr 2009 14:50:28 -0700
> From: Diva Canto <diva at metaverseink.com>
> Subject: Re: [Opensim-dev] The essence of "grid"
> To: opensim-dev at lists.berlios.de
> Message-ID: <49E656A4.1030505 at metaverseink.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I think we already have an understanding of what is needed for securing
>  users from malicious hosts: client-side control, that's all. Client has
> direct control over user agents, user's inventory, IM, social network, 
> etc.
> The regions stay out of it, they are only simulators of objects and 
> agents.
> Grider is exploring that design space, and instrumenting OpenSim for it.
> We're very close to having OpenSim support these kinds of clients.
>
> However, in some cases, the user may want to give control, at least some, 
> to
> the ... and this is where terminology gets tricky...
> simulators? "grid"? And why would that be, you may ask. Well, because that
> server-side (not to get into the choice of words again) may provide some
> cool stuff if you pass it the control. It may, for example, give you an
> additional world-specific inventory, or it may open agents for you in
> interesting 3d spaces, or you won't be able to play whatever game is going
> on in there unless the server-side has control over some of your data.
>
> But even this is *sortof* relatively simple to do, IF we align the concept
> of VW with the concept of trust domain. OSGrid, however, doesn't do that. 
> So
> what would it mean for a user to visit OSGrid? With which server would the
> user's client share authority, if it were to share it?
>
>
> Christian Scholz wrote:
>> Hi!
>>
>> Cristina Videira Lopes schrieb:
>>> I'm trying to understand what it is that we are supposed to secure,
>>> because security depends entirely on that :-)
>>
>> That usually is my problem with most of these discussions be it on
>> MMOX, AWG or social networking. So it would be good to have some sort
>> of list of what needs to be secured against what sort of action.
>>
>>> I've seen way too many talks/chats/posts/blogs talking about a Web of
>>> VWs in some form, while making the unwritten assumption that the
>>> concept of "grid" (aka Virtual World unit, or whatever you want to
>>> call it) aligns with the concept of a domain of trust (i.e. a bunch
>>> of simulators that trust each other, under the control of one
>>> authority). Then, a Web of VWs is the interconnection of those domains 
>>> of
> trust.
>>>
>>> Well, OSGrid doesn't align with that. So either OSGrid is not a
>>> valid/sustainable use case for OpenSim or there's something wrong
>>> with that unwritten assumption. In my infinite tolerance towards
>>> variety, and given the empirical evidence here, I'm leaning towards the
> latter (i.e.
>>> there's something wrong with that assumption).
>>
>> Unfortunately I am not too familiar on how OSGrid works but I can
>> explain how it could work with the scenario I described where we have
>> quite many separate services.
>>
>> In this case a user would login to a region with separate locations of
>> the user's inventory, a list of links to group memberships, a link to
>> the user's profile and so on.
>>
>> The region would then ask an authorization manager to get access to
>> these resources on behalf of the user. The user will then be asked
>> with a list of services the region wants access to and on "ok" this
>> access will be granted in form of OAuth access token which can be used
>> to perform signed requests to these services. (the concept of the auth
>> manager needs to be developed as mentioned).
>>
>> So in this case the region can only access a user's data after getting
>> those tokens. If this "ok" is given automatically though security will
>> obviously be lacking.
>>
>> Now many regions could be grouped into one region domain which might
>> mean that they e.g. provide some mapping services and they could maybe
>> use shared access to that data.
>>
>> In the case of a region domain consisting of regions operated by
>> different providers this of course means that a rogue sim indeed could
>> get access to that data. But in general I don't see a solution here
>> unless you really give each sim access upon visiting. Which of course
>> would be annoying.
>>
>>> Yes, OSGrid, as is, will always be extremely vulnerable towards
>>> insider rogues; technically, it's impossible to secure OSGrid's UGAIM
>>> servers from malicious sims connected to it. But so what? Maybe
>>> people want it like that, maybe the OSGrid community wants to perform
>>> human surveillance instead of applying technical solutions such as
>>> the Hypergrid (once it's matured). Should we stop supporting that use
> case?
>>
>> I think in the case of a grid which is operated by many people and you
>> don't want just a shared map but also shared access for convenience
>> there is not much left for kicking out rogue domains. In fact a user
>> might not know that it's a bad sim when entering it anyway so even in
>> the case of a confirmation on each crossing that sim would probably
>> gain access.
>>
>> (Moreover I think bad clients is the more likely case of e.g. content
>> theft).
>>
>>> If we continue to support the existence of grids like OSGrid, then we
>>> need to think what it means for the users to visit such grids, and
>>> how they can visit them securely -- that's all I'm trying to figure out.
>>
>> They should at least be made aware that there is not one entity
>> running it you can sue (well, I don't know the TOS so I don't know if
>> you actually could sue somebody).
>>
>> -- Christian
>>
>> PS: I know that the OAuth stuff is far away from what would be
>> possible right now as it would also mean quite some changes to the
>> client, I am mostly mentioning it for discussion purposes and because
>> those are standards which are on the rise right now.
>>
>>>
>>> Justin Clark-Casey wrote:
>>>> Charles Krinke wrote:
>>>>> OSGrid exists with two goals.
>>>>>
>>>>> 1. Test OpenSim SVN on a regular basis and report results to aid in
>>>>> software development.
>>>>> 2. Nurture a community.
>>>>>
>>>>> We need to start by considering that OpenSim splits the asset
>>>>> storage between regions and the OpenSim assetServer. So, the
>>>>> OpenSim asset model is a little different then SecondLife since we
>>>>> already distribute some assets between regions and the UGAIM.
>>>> I didn't know you were doing this already.  Is there anywhere you could
> point to with more details?
>>>>
>>>>> Are we saying that OSGrid is doing something problematic and
>>>>> pertubating the OpenSim development? I am confused about the OSGrid
>>>>> comments in this philosophical discussion. As I see the whole
>>>>> situation, OSGrid is testing the mainline trunk SVN from OpenSim in
>>>>> a manner consistent with the desires of the community.
>>>> Not at all.  I think the debate is more about how the architecture
>>>> will move forward in the future.  As you know, regions on OSGrid
>>>> have to be pretty trustworthy so as not to abuse the central grid
>>>> services.  This classic architecture won't go away, but it might be 
>>>> that
> active development and research switches to other architectures (e.g. 
> client
> side asset/inventory access, hypergrid), which can be better secured for a
> robust distributed virtual environment.
>>>>
>>>> OSGrid may want to consider at some point whether it wants to
>>>> migrate or switch to other architectures once these have matured
> further.  I doubt that this maturity is all that imminent.
>>>>
>>>> Anyway, I'm probably putting words into Diva's mouth now.
>>>>
>>>>> Charles
>>>>>
>>>>> -------------------------------------------------------------------
>>>>> -----
>>>>> *From:* Justin Clark-Casey <jjustincc at googlemail.com>
>>>>> *To:* opensim-dev at lists.berlios.de
>>>>> *Sent:* Wednesday, April 15, 2009 8:24:45 AM
>>>>> *Subject:* Re: [Opensim-dev] The essence of "grid"
>>>>>
>>>>> Diva Canto wrote:
>>>>>  > As I zoom in on issues of trust and security, I'm getting to the
>>>>> point  > where I need a sharp definition of "grid". What is a grid,
>>>>> besides being  > a map/lookup service and a user accounts service?
>>>>>  >
>>>>>  > a) nothing more than that
>>>>>  > b) a trust domain
>>>>>  >
>>>>>  > If we choose b) then we need to think about OSGrid-like grids.
>>>>> How can  > we trust that a collection of regions administered by
>>>>> different people  > will behave? Can OSGrid-like grids survive
>>>>> without ToS being signed  > between the grid operator and the
>>>>> region operators? What if the ToS is  > such that it delegates to
>>>>> the region admins any liability on bad things  > happening in their
>>>>> regions? -- that leaves the user with no central  > authority to
> complain, which is as good as not having a trust domain.
>>>>>  >
>>>>>  > If OSGrid-like grids (i.e. no contracts, or very loose ones;
>>>>> just a map  > service) are to exist, then it's clear that b) doesn't
> hold in general.
>>>>>  > It means that there can be grids that are simply a collection of
>>>>> regions  > that come together in virtual space, but whose
>>>>> trustworthiness as a  > whole doesn't exist.
>>>>>  >
>>>>>  > The Hypergrid is specifically designed to cross trust
>>>>> boundaries. Should  > the OSGrid-like grids become HG-ed sims that
>>>>> share the same map, and let  > "grids" be, fully, trust domains?
>>>>>  >
>>>>>  > You may think I'm getting into philosophy, but this is critical
>>>>> for the  > technical work I'm doing right now related to
>>>>> authentication,  > server-side vs client-side authority, etc. If we
>>>>> can assume that a  > "grid" is a uniform trust domain with a
>>>>> central authority, things will  > be simpler in many ways. If not,
> things will be a bit more complicated.
>>>>>  >
>>>>>  > Thoughts?
>>>>>
>>>>> I think that you could adopt b) without having a philosophical
>>>>> problem with OSGrid.  I would say that even the 'loose contracts'
>>>>> on OSGrid are a form of trust.  If someone were to abuse that trust
>>>>> then I be very surprised if they were not removed from the grid.
>>>>>
>>>>> If OSGrid wanted better security by not sharing the current central
>>>>> services then perhaps they could stipulate that new regions had to
>>>>> connect by Hypergrid rather than the current model (once the
>>>>> various gaps in Hypergrid are ironed out)?
>>>>> Then, in a sense, all the directly connected regions becomes a
>>>>> large Hypergrid node in the federation that makes up OSGrid.
>>>>>
>>>>>  >
>>>>>  >
>>>>>  > _______________________________________________
>>>>>  > Opensim-dev mailing list
>>>>>  > Opensim-dev at lists.berlios.de
>>>>> <mailto:Opensim-dev at lists.berlios.de>
>>>>>  > https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>  >
>>>>>
>>>>>
>>>>> --
>>>>> justincc
>>>>> Justin Clark-Casey
>>>>> http://justincc.wordpress.com
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------
>>>>> -----
>>>>>
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev at lists.berlios.de
>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 15 Apr 2009 15:01:07 -0700 (PDT)
> From: Charles Krinke <cfk at pacbell.net>
> Subject: Re: [Opensim-dev] The essence of "grid"
> To: diva at metaverseink.com, opensim-dev at lists.berlios.de
> Message-ID: <678807.81030.qm at web82604.mail.mud.yahoo.com>
> Content-Type: text/plain; charset="us-ascii"
>
> You have completely lost me.
>
> OSGrid uses the OpenSim UserServer for its "trust domain", as do all other
> OpenSim grids.
>
> Perhaps you need to change your semantics or argument a bit as there is
> nothing different about OSGrid then any of the other OpenSim grids.
>
> If you could perhaps make your debate a bit more focused on OpenSim grids 
> in
> general, then maybe we can figure out how to accomodate your thought
> processes.
>
> Charles




------------------------------

Message: 2
Date: Thu, 16 Apr 2009 05:22:08 -0700
From: Michael Cortez <mcortez at gmail.com>
Subject: Re: [Opensim-dev] Springs, Torques, joints , friction,
	questions and Vehicles oh my
To: opensim-dev at lists.berlios.de
Message-ID: <49E722F0.2090608 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Teravus Ovares wrote:
> Looking at the LSL Vehicle API, it seems clear that there is at least
> an angular motor and a linear motor involved.   There may be two
> angular motors, one for the angular movement and one for the vertical
> attractor(which may just be a jacobian constraint).  In ODE, angular
> motors are implemented as springs.    Sometimes this can cause
> instability and vibration.     The truth is, using ODE's angular motor
> may or may not be the best solution.   
I had attempted to implement the vertical attractor, and was only partly 
successful.

My attempt which is now a little stale can be found here:

http://code.google.com/p/flotsam/downloads/detail?name=vehicle.3.patch

Some of the things that I found:

* dAMotorEuler is not appropriate.  I could not find a any set of 
parameters for the aMotor that would even begin to remotely approximate 
the behavior for a vertical attractor, I had to instead turn to using 
dAMotorUser.  dAMotorUser requires that at each step, you specify at 
what angle(s) the joint is at, rather then having the ODE attempt to 
calculate it automatically.  I also ran into gimbal lock issues with 
aMotorEuler, since the vertical attractor needs to work with 2 or 3 
axises with a full 360 deg range of motion.

* The closest approximation I could get was to essentially set the stops 
at near 0 degs of movement, and then adjust CFM, StopCFM and ERP values 
to control how much the aMotor would attempt to correct the angles 
beyond the stops.

* FudgeFactor and Bounce had little to no visible effect during my 
experiments

* FMax appeared not to affect CFM/ERP behavior, and only seemed to be 
used when you use Vel


The best results I could get adjusting CFM/ERP values had the following 
results:

+ If you manually rotated a physical object out of vertical using the 
editor and then "let go" -- it would more or less smoothly return to 
vertical, although sometimes it would move past vertical and then 
oscillate back and forth, usually taking minutes to come to a rest, 
sometimes never coming to a rest.

+ If I set an object to float (either via buoyancy or the HoverHeight 
PID) and I "bumped" the object with my avatar to impart rotation, it 
would nearly always wildly oscillate, usually obtain vertical on one or 
two axis, and then rarely coming to a rest on the third.  Occasionally 
it would rotate violently, launching my avatar either 1000's of meters 
vertically, under ground, or out of the region.

I was tempted to push what I had to the main SVN, but was unhappy with 
the results so I never got around to it -- then got distracted by Sun, 
Wind, Groups, etc...

--
Michael Cortez


------------------------------

Message: 3
Date: Thu, 16 Apr 2009 16:18:42 +0200
From: Giorgio Servillo <gioservil at gmail.com>
Subject: Re: [Opensim-dev] Mysql help request
To: opensim-dev at lists.berlios.de
Message-ID:
	<57d9a0370904160718r2d9526e9le16ece935ad54f1e at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Thanks for the answers,
I just realized the kyle solution using the xml-rpc, it work fine .
Thanks.

Giorgio.

2009/4/8 Kyle <create at reactiongrid.com>
>
> You could store the data in a table and then use XMLRPC or llHTTP to query
the DB and move prims inworld. It isn?t as fast as direct DB but come by
www.reactiongrid.com to see on Project Manhattan sim how we have a local
instrument feeding data via a VB app from our PC?s serial port to SQL 2008
then a ASP.NET page is used for LSL inworld to query which drives prim
color, movement, creating particles based on if-then for the value and more.
>
>
>
> Kyle G
>
>
>
> From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Giorgio Servillo
> Sent: Wednesday, April 08, 2009 6:53 AM
> To: opensim-dev at lists.berlios.de
> Subject: [Opensim-dev] Mysql help request
>
>
>
> HI to all,
>
>
>
> I need to modify an object proprieties through direct changing of the
database table,
>
>
>
> For example i would move an object only changing relatives coordinates of
my object inside the opportune table of the database.
>
> I tried to do this, but OpenSim server dooesn't change immediatly the
position of the object, until I restart the server.
>
>
>
> Is there a way to solve my issue without restart the ?entire server ?
>
>
>
>
>
> Thanks to All
>
>
>
> Giorgio
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>


------------------------------

Message: 4
Date: Thu, 16 Apr 2009 07:24:03 -0700
From: Michael Cortez <mcortez at gmail.com>
Subject: Re: [Opensim-dev] The essence of "grid"
To: opensim-dev at lists.berlios.de
Message-ID: <49E73F83.60101 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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.

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.

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.

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.


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

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


Cheers,
--
Michael Cortez


------------------------------

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


End of Opensim-dev Digest, Vol 20, Issue 54
*******************************************