[Opensim-dev] The essence of "grid"

Wed Apr 15 13:12:52 UTC 2009

I think we need a different term. The "grid" as it exists today is more 
concerned with mapping regions than anything else; any trust domain or 
resource sharing that exists seems to me to have emerged as a side-effect 
of the necessities of co-location. We should abandon the grid and move 
toward federalism.

I don't see any reason why notions such as trust, co-location, asset sets, 
or anything else should necessarily be anything other than loosely 
coupled, independent, federations. I think this would encourage a more 
minimal approach to what constitutes a simple region implementation 
(looking outside for all of the "services" it requires apart from perhaps 
a local region database.

I do agree with the view that assets and inventory are user-centric, and 
any asset dependencies in a region are consequential, diverse, and not 
necessarily managed by the region at all.

Best regards
Alan
-------------------
T.J. Watson Research Center, Hawthorne, NY
1-914-784-7286
alan_webb at us.ibm.com

From:
Melanie <melanie at t-data.com>
To:
opensim-dev at lists.berlios.de
Date:
04/15/2009 08:46 AM
Subject:
Re: [Opensim-dev] The essence of "grid"

I'm happy to see others are sharing my vision. :)

That is just what i think needs to happen:

Users becoming independent entities who use a inventory and asset 
space provider of their choice, even self-hosted if they have the 
bandwidth.

Regions service local assets themselves, so there is no nee for 
continuous access and authorization to the user's asset services 
just to render content.

Grids being like websites, as trust domains binding regions together 
that share a common pool of local resources (assets).

And the HG letting us travel freely between them, and comms being 
simply out of scope for regions, handled between comms provider 
networks and the client.

Melanie

BlueWall Slade wrote:
> I have imagined a scenario where a user service exists that 
authenticates
> the user and provides credentials to whatever place they may travel. And
> possibly provides an inventory service for the user as well. The service 
is
> not, necessarily, anything but a standalone user service, much like an 
email
> provider. The user can login via the service travel to various places, 
their
> identity guaranteed by the user service and their inventory with them
> wherever they travel.
> 
> I see a variety of asset services. Some with the ability to determine
> through digital signatures whether a new upload is authentic and whether 
it
> should be allowed/disallowed based on the users credentials and the
> signature of the author. I see some of these being content 
creator/content
> distribution centric and provided as a service for wide content
> distribution. These would also hold some bearing on the enforcement of
> licenses for the content, for instance, where the item can be rezzed. 
And I
> see some as being utility asset services hosted by entities with 
connected
> regions for the management of local/near assets.
> 
> And, I see connected groups of regions based around specific themes, 
ideas
> or goals. Destinations that allow or disallow travel to a user based on
> policy set by the connecting entity. Not necessarily  providing a user
> service, but rather a consumer of the user service. Not necessarily
> providing an asset service, beyond servicing local needs. But, more of a
> consumer of the widely distributed asset services. The policy may 
require a
> registration before allowing the user, and may allow or disallow entry 
based
> on a set of preset criteria.
> 
> Also, user/group centric messaging services that span the infrastructure 
to
> allow users and groups to communicate, offer teleports and inventory to 
each
> other regardless of their location.
> 
> If we think in terms of openness and distributed services that provide a
> better experience for the user, it allows a more useful infrastructure 
to
> develop. And, if we think of  a grid as a UGAIM with a bunch of 
connected
> regions backed by a hall of lawyers and a bank, we don't get too far.
> 
> 
> Thanks,
> BlueWall
> 
> 
> 
> 
> On Wed, Apr 15, 2009 at 4:52 AM, Thomas Grimshaw 
<tom at streamsense.net>wrote:
> 
>> I know i'm pretty much a newcomer to this scene, but i'd like to throw
>> my two pence into the midst.
>>
>> First of all, i'm not a big fan of beaurocracatic discussions about the
>> theory behind "what a grid is"; principally because we're not building 
a
>> grid, we're building a platform - a platform which may have reaches far
>> different from any scopes and concepts which we individually may 
retain.
>>
>> One thing which really provoked a reaction from me in Melanie's 
response
>> was this:
>>
>>  "being forced to share asset and inventory servers"
>>
>> Is that really such a bad thing? I have to be honest, I have not met a
>> single person in second life, OSgrid, reactiongrid, openlife, k-grid,
>> who has said to me "You know what, what we really need is asset
>> segregation and to make content harder to find."
>>
>> Here's my viewpoint, in a summary.
>>
>> - Security is a good thing.  Real security, as in, stuff which prevents
>> attacks, helps to keep the grid stable, etc.
>>
>> - Please let's not provide a platform which promotes segregation. If
>> you're really looking for the definition of a "grid", i believe there 
is
>> a definite conflict of interest with this approach.
>>
>> - Let's look to the future, and not base the way we think on constructs
>> already in place. No matter committed you think we are to the "linden
>> designed protocol" - things can change in a matter of days.
>>
>> - I can easily predict the availability in the future of "asset farms"
>> which are linked in to multiple grids.  I think this is the right
>> approach, please don't push things in the other direction.
>>
>> ~T
>>
>> Melanie wrote:
>> > I believe that, for technical purposes, a "grid" should indeed be
>> > seen as a trust domain. That was what the protocol was designed for
>> > and bending it to anything else would be very painful and not
>> > entirely successful, feature-wise. The Linden-designed protocol
>> > elements are best suited to that situation, and the HG ones are best
>> > suited to untrusted connections.
>> > OSGrid really does straddle the fence in many respects, but I think
>> > it will change over time and become HG connected rather than
>> > grid-structured. The server-centric region handoff system doesn't
>> > allow for any level of content protection and being forced to share
>> > asset and inventory servers is no longer needed in the new
>> > architecture that Diva and I hashed out last night.
>> > We would, indeed, arrive at a secure Hypergrid, and a true 3d
>> > internet, much sooner if we made that distinction and considered a
>> > "grid" as we know it today a trust domain.
>> >
>> >  From that follows:
>> > Region = Webpage
>> > Grid = Website
>> > Hypergrid = Internet
>> >
>> > The operator of a complex, multipage website needs trust between
>> > it's pages, and so the operator of a complex HG site with many
>> > regions needs trust between them.
>> >
>> > Melanie
>> >
>> >
>> > 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?
>> >>
>> >>
>> >> _______________________________________________
>> >> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090415/ea3cc3d7/attachment-0001.html>