<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif"><br>
Best regards<br>
Alan<br>
-------------------<br>
T.J. Watson Research Center, Hawthorne, NY<br>
1-914-784-7286<br>
alan_webb@us.ibm.com</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Melanie <melanie@t-data.com></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">opensim-dev@lists.berlios.de</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">04/15/2009 08:46 AM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: [Opensim-dev] The essence of "grid"</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>I'm happy to see others are sharing my vision. :)<br>
<br>
That is just what i think needs to happen:<br>
<br>
Users becoming independent entities who use a inventory and asset <br>
space provider of their choice, even self-hosted if they have the <br>
bandwidth.<br>
<br>
Regions service local assets themselves, so there is no nee for <br>
continuous access and authorization to the user's asset services <br>
just to render content.<br>
<br>
Grids being like websites, as trust domains binding regions together <br>
that share a common pool of local resources (assets).<br>
<br>
And the HG letting us travel freely between them, and comms being <br>
simply out of scope for regions, handled between comms provider <br>
networks and the client.<br>
<br>
Melanie<br>
<br>
<br>
BlueWall Slade wrote:<br>
> I have imagined a scenario where a user service exists that authenticates<br>
> the user and provides credentials to whatever place they may travel.
And<br>
> possibly provides an inventory service for the user as well. The service
is<br>
> not, necessarily, anything but a standalone user service, much like
an email<br>
> provider. The user can login via the service travel to various places,
their<br>
> identity guaranteed by the user service and their inventory with them<br>
> wherever they travel.<br>
> <br>
> I see a variety of asset services. Some with the ability to determine<br>
> through digital signatures whether a new upload is authentic and whether
it<br>
> should be allowed/disallowed based on the users credentials and the<br>
> signature of the author. I see some of these being content creator/content<br>
> distribution centric and provided as a service for wide content<br>
> distribution. These would also hold some bearing on the enforcement
of<br>
> licenses for the content, for instance, where the item can be rezzed.
And I<br>
> see some as being utility asset services hosted by entities with connected<br>
> regions for the management of local/near assets.<br>
> <br>
> And, I see connected groups of regions based around specific themes,
ideas<br>
> or goals. Destinations that allow or disallow travel to a user based
on<br>
> policy set by the connecting entity. Not necessarily  providing
a user<br>
> service, but rather a consumer of the user service. Not necessarily<br>
> providing an asset service, beyond servicing local needs. But, more
of a<br>
> consumer of the widely distributed asset services. The policy may
require a<br>
> registration before allowing the user, and may allow or disallow entry
based<br>
> on a set of preset criteria.<br>
> <br>
> Also, user/group centric messaging services that span the infrastructure
to<br>
> allow users and groups to communicate, offer teleports and inventory
to each<br>
> other regardless of their location.<br>
> <br>
> If we think in terms of openness and distributed services that provide
a<br>
> better experience for the user, it allows a more useful infrastructure
to<br>
> develop. And, if we think of  a grid as a UGAIM with a bunch
of connected<br>
> regions backed by a hall of lawyers and a bank, we don't get too far.<br>
> <br>
> <br>
> Thanks,<br>
> BlueWall<br>
> <br>
> <br>
> <br>
> <br>
> On Wed, Apr 15, 2009 at 4:52 AM, Thomas Grimshaw <tom@streamsense.net>wrote:<br>
> <br>
>> I know i'm pretty much a newcomer to this scene, but i'd like
to throw<br>
>> my two pence into the midst.<br>
>><br>
>> First of all, i'm not a big fan of beaurocracatic discussions
about the<br>
>> theory behind "what a grid is"; principally because
we're not building a<br>
>> grid, we're building a platform - a platform which may have reaches
far<br>
>> different from any scopes and concepts which we individually may
retain.<br>
>><br>
>> One thing which really provoked a reaction from me in Melanie's
response<br>
>> was this:<br>
>><br>
>>  "being forced to share asset and inventory servers"<br>
>><br>
>> Is that really such a bad thing? I have to be honest, I have not
met a<br>
>> single person in second life, OSgrid, reactiongrid, openlife,
k-grid,<br>
>> who has said to me "You know what, what we really need is
asset<br>
>> segregation and to make content harder to find."<br>
>><br>
>> Here's my viewpoint, in a summary.<br>
>><br>
>> - Security is a good thing.  Real security, as in, stuff
which prevents<br>
>> attacks, helps to keep the grid stable, etc.<br>
>><br>
>> - Please let's not provide a platform which promotes segregation.
If<br>
>> you're really looking for the definition of a "grid",
i believe there is<br>
>> a definite conflict of interest with this approach.<br>
>><br>
>> - Let's look to the future, and not base the way we think on constructs<br>
>> already in place. No matter committed you think we are to the
"linden<br>
>> designed protocol" - things can change in a matter of days.<br>
>><br>
>> - I can easily predict the availability in the future of "asset
farms"<br>
>> which are linked in to multiple grids.  I think this is the
right<br>
>> approach, please don't push things in the other direction.<br>
>><br>
>> ~T<br>
>><br>
>> Melanie wrote:<br>
>> > I believe that, for technical purposes, a "grid"
should indeed be<br>
>> > seen as a trust domain. That was what the protocol was designed
for<br>
>> > and bending it to anything else would be very painful and
not<br>
>> > entirely successful, feature-wise. The Linden-designed protocol<br>
>> > elements are best suited to that situation, and the HG ones
are best<br>
>> > suited to untrusted connections.<br>
>> > OSGrid really does straddle the fence in many respects, but
I think<br>
>> > it will change over time and become HG connected rather than<br>
>> > grid-structured. The server-centric region handoff system
doesn't<br>
>> > allow for any level of content protection and being forced
to share<br>
>> > asset and inventory servers is no longer needed in the new<br>
>> > architecture that Diva and I hashed out last night.<br>
>> > We would, indeed, arrive at a secure Hypergrid, and a true
3d<br>
>> > internet, much sooner if we made that distinction and considered
a<br>
>> > "grid" as we know it today a trust domain.<br>
>> ><br>
>> >  From that follows:<br>
>> > Region = Webpage<br>
>> > Grid = Website<br>
>> > Hypergrid = Internet<br>
>> ><br>
>> > The operator of a complex, multipage website needs trust
between<br>
>> > it's pages, and so the operator of a complex HG site with
many<br>
>> > regions needs trust between them.<br>
>> ><br>
>> > Melanie<br>
>> ><br>
>> ><br>
>> > Diva Canto wrote:<br>
>> ><br>
>> >> As I zoom in on issues of trust and security, I'm getting
to the point<br>
>> >> where I need a sharp definition of "grid".
What is a grid, besides being<br>
>> >> a map/lookup service and a user accounts service?<br>
>> >><br>
>> >> a) nothing more than that<br>
>> >> b) a trust domain<br>
>> >><br>
>> >> If we choose b) then we need to think about OSGrid-like
grids. How can<br>
>> >> we trust that a collection of regions administered by
different people<br>
>> >> will behave? Can OSGrid-like grids survive without ToS
being signed<br>
>> >> between the grid operator and the region operators? What
if the ToS is<br>
>> >> such that it delegates to the region admins any liability
on bad things<br>
>> >> happening in their regions? -- that leaves the user with
no central<br>
>> >> authority to complain, which is as good as not having
a trust domain.<br>
>> >><br>
>> >> If OSGrid-like grids (i.e. no contracts, or very loose
ones; just a map<br>
>> >> service) are to exist, then it's clear that b) doesn't
hold in general.<br>
>> >> It means that there can be grids that are simply a collection
of regions<br>
>> >> that come together in virtual space, but whose trustworthiness
as a<br>
>> >> whole doesn't exist.<br>
>> >><br>
>> >> The Hypergrid is specifically designed to cross trust
boundaries. Should<br>
>> >> the OSGrid-like grids become HG-ed sims that share the
same map, and let<br>
>> >> "grids" be, fully, trust domains?<br>
>> >><br>
>> >> You may think I'm getting into philosophy, but this is
critical for the<br>
>> >> technical work I'm doing right now related to authentication,<br>
>> >> server-side vs client-side authority, etc. If we can
assume that a<br>
>> >> "grid" is a uniform trust domain with a central
authority, things will<br>
>> >> be simpler in many ways. If not, things will be a bit
more complicated.<br>
>> >><br>
>> >> Thoughts?<br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> Opensim-dev mailing list<br>
>> >> Opensim-dev@lists.berlios.de<br>
>> >> </font></tt><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev"><tt><font size=2>https://lists.berlios.de/mailman/listinfo/opensim-dev</font></tt></a><tt><font size=2><br>
>> >><br>
>> >><br>
>> >><br>
>> > _______________________________________________<br>
>> > Opensim-dev mailing list<br>
>> > Opensim-dev@lists.berlios.de<br>
>> > </font></tt><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev"><tt><font size=2>https://lists.berlios.de/mailman/listinfo/opensim-dev</font></tt></a><tt><font size=2><br>
>> ><br>
>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> Opensim-dev@lists.berlios.de<br>
>> </font></tt><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev"><tt><font size=2>https://lists.berlios.de/mailman/listinfo/opensim-dev</font></tt></a><tt><font size=2><br>
>><br>
> <br>
> <br>
> ------------------------------------------------------------------------<br>
> <br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> Opensim-dev@lists.berlios.de<br>
> </font></tt><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev"><tt><font size=2>https://lists.berlios.de/mailman/listinfo/opensim-dev</font></tt></a><tt><font size=2><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
Opensim-dev@lists.berlios.de<br>
</font></tt><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev"><tt><font size=2>https://lists.berlios.de/mailman/listinfo/opensim-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>