<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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. <br><br>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.<br>
<br><br>Thanks,<br>BlueWall<br><br><br><br><br><div class="gmail_quote">On Wed, Apr 15, 2009 at 4:52 AM, Thomas Grimshaw <span dir="ltr"><<a href="mailto:tom@streamsense.net">tom@streamsense.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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>
<div class="im"><br>
 "being forced to share asset and inventory servers"<br>
<br>
</div>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>
<font color="#888888"><br>
~T<br>
</font><div><div></div><div class="h5"><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>
>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>><br>
>><br>
>><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br>