[Opensim-dev] The essence of "grid"

Christian Scholz cs at comlounge.net
Wed Apr 15 13:24:11 UTC 2009


Hi!

I am also a bit new to this list but some might know me from the MMOX
list or in general as Tao Takashi in SL.

Melanie wrote:
> 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.

I am thinking in similar terms and also would like to connect social
networks and virtual worlds a bit more. Fact is that a virtual world
might also be seen just as a social network with 3D services attached as
you have the same base: user authentication, profile information,
contact lists, group memberships, instant messaging, asset storage (be
it 2D for e.g. photos/videos/text/etc. or 3D like 3D objects, avatars
and the like).

All these services might be distributed in the cloud. E.g.
authentication could happen via OpenID, profile could be stored at
MySpace and accessible via OpenSocial REST API, photos might be on
flickr and so on.

There are some groups, namely the DataPortability Project[1] and the
DiSo group[2] where I heard about the term Service Catalogue which
basically is a listing where a user has all that data stored. A possible
format for that could be XRD[3] but in fact it really is a simple list
of (type, URI) pairs.

Now if a user logs in to a region that region could actually retrieve
that Service Catalogue and could use OAuth to get an authorization to
access data of these services. Some of these of course might be asset
servers.

Likewise a region could also have a list of service describing what sort
of 3D formats/protocols it understands so that the client can choose
appropriately. A region could also point to other services such as e.g.
an instant messaging service for that region (or region group) etc.

If we also define a concept of a region domain as OGP does then we could
also group regions together because IMHO that will be a requirement in
larger installations as otherwise you might have to accept a new TOS on
every sim crossing.

With a Service Catalogues in place for both user and regions it would
also be easy to later on add new protocols plus it would allow one to
split the whole thing which OpenSim is right now into separate services
(which I would like very much as I am more of a Python programmer and
would then be able to code one of these services, e.g. user or asset
management).

The specification for such things is also actually mostly there already
(with OpenID, OAuth, OpenSocial, XRD, LRRD) with maybe the exception of
a mass authorization step where you can authorize multiple services from
one service with one automated step. Otherwise you'd need to send the
user to each service individually where one has to click OK after maybe
logging in first. But there is some discussion about this on the OAuth
list already and Sun also has some proposal called ProtectServe[4].

I am not sure if I could explain this properly but I hope so. Basically
I just would like to advocate a wider angle and looking at social
networking in general as well as IMHO at some point Web and VWs should
grow a bit more together.

-- Christian

[1] http://dataportability.org
[2] http://diso-project.org/
[3] http://www.hueniverse.com/hueniverse/xrd/
[4] http://www.xmlgrrl.com/blog/categories/protectserve/



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


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