[Opensim-dev] The essence of "grid"

[Melanie]

Sharing asset and inventory servers is not a bad thing. Being forced 
to do it is.

It's not about finding content, it's about protecting it.

With what I know about these protocols, continuing along a path of 
creating a grid based on Linden legacy protocols without assuming 
trust will lead to grief in the end. This is not philosophical, it's 
technical. The protocols weren't designed for it.

It is easier to recreate osgrid as a HG linked set of regions 
(outwardly identical to what it is today), yet fully secure, and 
leave the use of the Linden protocols to scenarios that occur within 
a trust domain.

OSGrid doesn't have to lose it's identity, it would still have a 
common map, adjacent regions and could offer user inventory and 
asset services.
Inventory would remain portable as well, and search can still index 
all regions in the grid.
This is not about changing OSGrid into something else, it is merely 
about using a different, better suited, protocol to implement OSGrid.

Melanie


Thomas Grimshaw 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
> 
>