[Opensim-dev] The essence of "grid"
Mystical Demina
MysticalDemina at xrgrid.com
Fri Apr 17 03:04:48 UTC 2009
I am thinking this direction and support you model.
-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie
Sent: Thursday, April 16, 2009 7:51 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] The essence of "grid"
In the current thinking:
Users should be in control of their own inventory and it's
associated assets, independent of a single grid.
This means:
- users can select where their data is stored. This may be an ISP, a
web hoster, a grid or their own PC (bandwidth permitting). No
simulator has authority over that storage.
- Regions hold COPIES of the assets needed to render whatever is
currently in world. Normally, this will be "by value", e.g. the sim
will have a full and valid copy of the data and be able to supply
everything needed to render it's content independent of any outside
servers.
- Grids are trust domains, they are groups of regions sharing asset
and user services. The access the same servers for their data and
anything within one region can be moved to any other region without
the need to copy assets. Regions within a trust domain are able to
destroy storage needed by other regions to render data, but cannot
access user inventories unless authorized, and with very limited
scope. Typically, but not mandatory, all sims in one trust domain
will be owned and operated by a single individual/organization.
- User services authenticate user for access to a trust domain. They
may require username/password, X.509 certificates, oAuth, openID or
any other form of authentication, or none. They may decree that, if
you don't authenticate, your access may be limited to observation
only, or in any other way they, as the trust domain controller, see fit.
- Sim asset services are the storage at the heart of a trust domain,
sims in a trust domain share these asset services. That is distinct
from user asset services, which are out of scope for regions.
- Optionally, user asset services may pass an object to a region "bt
reference". This assumes a basic level of trust with the region,
which is advised to not keep a copy, but request the current data
from the user asset service each time it is needed. This required
continuous authorization for that item, which will be limited to
specific sims, Therefore, such items can't leave the sim, they
cannot be given or sold, but only be taken by the owner. This is
useful for allowing the update of scripts in-place, e.g. for
applications like sloodle, which may want to update all inworld
terminals all at once. It it a marked departure from the Linden way
of doing things.
I hope this clarifies things a little.
Melanie
Ideia Boa wrote:
> Yes, that is what I wanted to say but the words are not as strong in me.
> So I try not to say many things.
>
> Ideia Boa
>
> Diva Canto wrote:
>> We want to secure many things:
>>
>> - Simulators data and performance against malicious users -- this is the
>> most vocally spoken problem, but it's not specific to a web of VWs; it
>> happens in closed worlds too. Obviously, we need to address it in some
>> way if we want to be friendly to content producers.
>>
>> - User's data against malicious simulators -- e.g. the ability that a
>> rogue sim currently has of wiping out a user's inventory, doing false
>> impersonations, etc etc. This is specific to a web of VWs; this problem
>> doesn't exist in closed worlds, because there are no rogue sims in those
>> worlds, all sims are within the same domain of trust. These are the
>> kinds of problems I'm most worried about, because they come with
>> decentralization of control.
>>
>> So we're talking about safety of users' data. Currently when a user
>> visits a sim that sim has access to just about everything related to
>> that user.
>>
>>
>> Ideia Boa wrote:
>>
>>> I think the big confusion is that most posts are referring to USERS and
>>> safety is not the topic.
>>> I suppose what is at stake is how to interconnect grids and regions in a
>>> safe or not and nothing is related to the USERS.
>>> Please correct me if I am wrong in my way of seeing "The essence of
grid"
>>>
>>> Ideia Boa
>>>
>>>
>>> Diva Canto wrote:
>>>
>>>> I think you may be thinking of OpenSim's equivalent to OGP's
>>>> "agent domain" -- that's different, and yes, that is our User Server.
>>>>
>>>> "Trust domain", in the context of this discussion, is what Melanie and
I
>>>> said over a few emails: a collection of simulators that trust each
other
>>>> and that are all under one single authority. They may be associated
with
>>>> User services or not -- they may simply be simulators without
associated
>>>> user accounts. I think OGP has a name for it too, "region domain"
perhaps?
>>>>
>>>>
>>>> Charles Krinke wrote:
>>>>
>>>>
>>>>> I have had this discussion with Adam and Lbsa in the past.
>>>>>
>>>>> The OpenSim equivalent to SecondLife's AgentDomain is our UserServer.
>>>>>
>>>>> So, the "trust domain" is the UserServer executable on a given grid.
>>>>>
>>>>> Now, it may be incomplete, but that is the direction we have been
going
>>>>> for the last two years.
>>>>>
>>>>> Charles
>>>>>
>>>>>
------------------------------------------------------------------------
>>>>> *From:* Ideia Boa <ideiaboa at gmail.com>
>>>>> *To:* opensim-dev at lists.berlios.de
>>>>> *Sent:* Thursday, April 16, 2009 1:16:52 PM
>>>>> *Subject:* Re: [Opensim-dev] The essence of "grid"
>>>>>
>>>>> Finally someone to explain in brief what is "trust domain" and is
>>>>> precisely what we need. We need to create something that the grids and
>>>>> regions connected by hypergrid can behave as "trust domain"
>>>>> Cristina got 100000% of reason in your security considerations for
links
>>>>> between grids and regions.
>>>>> Melanie, thanks for the help given by your post.
>>>>>
>>>>> Ideia Boa
>>>>>
>>>>> Melanie wrote:
>>>>>
>>>>>
>>>>>> In the future, the avatar and his inventory will be independent of
>>>>>> the grid. This is already almost a reality.
>>>>>>
>>>>>> To address another post, a "trust domain" doesn't imply that the
>>>>>> visitor trusts it. It merely means that all regions within it trust
>>>>>> each other. Like the servers that make up a web application.
>>>>>>
>>>>>> Melanie
>>>>>>
>>>>>> Charles Krinke wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Backing up a bit, I think we need to start with the fact that a grid
provides a common start point for an avatar logon. By that, I mean, a grid
will have some quantity of users in the users MySQL or MSSQL table with a
particular avatar appearance and some semblance of an inventory.
>>>>>>>
>>>>>>> For the purpose of HyperGrid, many folks wish to travel from
grid->grid, standalone->grid, standalone->standalone or grid->standalone.
And most of those folks will expect to have their avatar appearance constant
based on their original logon place as they HG around.
>>>>>>>
>>>>>>> So, from the most basic point, we can say that our current and most
reasonable use case is an avatar with custom edits and some inventory that
logs onto a particular standalone or grid and then expects to be able to
HyperGrid to a different grid and have that avatar and inventory stay
reasonably constant. That is, the avatar should not be ruthed.
>>>>>>>
>>>>>>> In order to accomplish this
>>>>>>> in the general case is a bit tricky and I believe is one of the
issues being worked on currently. A number of other things begin falling out
of this notion after this one is working reliability and consistently such
as the other things brought up in this thread.
>>>>>>>
>>>>>>> But, I think it all begins with a desire for a consistent avatar and
inventory experience while HyperGridding.
>>>>>>>
>>>>>>> Charles
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
------------------------------------------------------------------------
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> -----Inline Attachment Follows-----
>>>>>
>>>>> begin:vcard
>>>>> fn:Ideia Boa
>>>>> n:Boa;Ideia
>>>>> note;quoted-printable:Best regards,=0D=0A=
>>>>> Ideia Boa=0D=0A=
>>>>> WorldSimTerra=0D=0A=
>>>>> =0D=0A=
>>>>> Join the new 3D world revolution : http://www.worldsimterra.com/
>>>>> <http://www.worldsimterra.com/>
>>>>> x-mozilla-html:TRUE
>>>>> url:http://www.worldsimterra.com <http://www.worldsimterra.com>
>>>>> version:2.1
>>>>> end:vcard
>>>>>
>>>>>
>>>>>
------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>>
>> _______________________________________________
>> 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
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
More information about the Opensim-dev
mailing list