[Opensim-dev] UGAIM++ (Re: rex auth & avatar systems)

Thu Dec 11 04:46:19 UTC 2008

About the picture below. In OpenSim, the login process could be made 
more decoupled if only the user server didn't assume anything about the 
map (grid) server. On the other hand, I don't see a problem in giving 
users "homes", that is, default regions where they always land upon 
logging in. The home concept is actually quite important, I think. In 
VWs users should probably have homes. A "home" is the place where users 
can do everything without fear of being robbed -- that's my definition 
of "home."

Also, the User Service could be decoupled from inventory and assets. It 
already is, to some extent. However...

I think there's something really interesting about the set UGAIM++ (the 
++ is for additional user-centered services), and although they serve 
different purposes, their total decoupling is not necessarily a good 
thing. I came to that conclusion after having thought first that the 
decoupling was definitely the way to go. I'm not so sure it is anymore, 
but I can see both ways. I think we can do a lot of interesting things 
with peer-to-peering sets of UGAIMs instead of decoupling the individual 
services. Here's why.

I really like the idea of designing a global infrastructure centered on 
people ("people", not "avatars"). The question we should be asking is: 
what do people need to go around this global infrastructure? They need 
an identity to login to (U), a home (G), raw storage (A), storage 
organization and ACL (I), a way to talk to other people (M), ... and 
maybe other things. Yes, we can certainly spread these different 
services among different service providers, but what are the advantages 
of doing so?

I came to formulate these questions as I started to understand the 
architecture of OpenSim a little better. What if... we packed a bunch of 
user-centered services into Apache? Wouldn't that make Apache a lot more 
interesting? What if... every computer would come with an associated 
user-centered web server, a "standalone"? Wouldn't that make a lot of 
things a lot easier on the web?

Before we blindly copy the web, and the practices on it, we should 
consider ways to make something *better* than the web, and this goes way 
beyond the 3D-ness of VWs. The UGAIM++ collection made me stop and think 
about this.

Crista

>
> Frisby, Adam wrote:
>>
>> My understanding of the structure is the Rex system is closer to a 
>> decoupled system than the Hypergrid.
>>
>>  
>>
>> Hypergrid involves teleporting along known links -- ie you teleport 
>> to a hypergrid region which connects you to other regions. The Rex 
>> model is closer to a web browser, where you move along via 
>> URL-equivilents, and it will disconnect/reconnect you from the 
>> current/next sims -- sort of ala a more seamless Meerkat.
>>
>>  
>>
>> The Rex auth server basically acts as an identity broker -- when you 
>> request access to a sim on a different network ("grid"-ish), you get 
>> authorised by your auth server. Your auth server acts very similarly 
>> to the OGP Agent Domain, in that it is responsible for routing 
>> messages to you, assigning sessions, etc.
>>
>>  
>>
>> At risk of using outlook's HTML here, allow me to draw a diagram...
>>
>>  
>>
>> Text Box: Simulator or Collection of SimsText Box: Simulator or 
>> Collection of Sims
>>
>>  
>>
>>
>>
>> 	
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>
>> This diagram shows a user logging into the first sim, then 
>> teleporting to a second sim on another network. AuthAlpha.com isn't 
>> prescribed anywhere on any sims -- they don't know it exists until a 
>> user attempts to login, in which case it is contacted and asked to 
>> cough up some info about the user.
>>
>>  
>>
>> The rex server operates under two modes here, you can either lock to 
>> particular pre-authorised auth servers (the OGP 'internal network' 
>> use case -- ie, corporate intranets, etc), or you can open up to any 
>> avatar on any auth server (public grids, etc).
>>
>>  
>>
>> Regards,
>>
>>  
>>
>> Adam
>>
>>  
>>
>>  
>>
>> *From:* opensim-dev-bounces at lists.berlios.de 
>> [mailto:opensim-dev-bounces at lists.berlios.de] *On Behalf Of *Cristina 
>> Videira Lopes
>> *Sent:* Monday, 8 December 2008 9:37 AM
>> *To:* opensim-dev at lists.berlios.de
>> *Subject:* Re: [Opensim-dev] rex auth & avatar systems (Re: future 
>> rexviewer merger)
>>
>>  
>>
>> To be precise, the comparison is not really between the hypergrid and 
>> Rex's avatar server; it's about comparing Rex's avatar server with 
>> OpenSim's User+Asset+Inventory trio.
>> The hypergrid is simply adding the capability of region servers 
>> interacting with several of those trios instead of just one.
>>
>> So, the unclear spot, really, is why Rex felt the need to substitute 
>> UAI with something else.
>>
>>
>> Charles Krinke wrote:
>>
>> I'm sorry. This is an OpenSim discussion channel. So, we are 
>> interested in what OpenSim is doing and where we are going.
>>
>> We have two different teleporting methods in OpenSim already. One is 
>> the AWG/OGP which allows teleporting from the LL betagrid to an 
>> OpenSim region. The other is the "HyperGrid", which allows 
>> teleporting between OpenSim grids or regions.
>>
>> We certainly can consider a third, and that certainly could be Rex. 
>> Or, certain Rex features may be added to the existing two interop 
>> technologies we already support.
>>
>> So, with that in mind, lets move forward and discuss the technical 
>> details of how the Rex technology works and how some or all of it is 
>> appropriate to add to OpenSim.
>>
>> Charles
>>
>>  
>>
>> ------------------------------------------------------------------------
>>
>> *From:* Lc <lcc1967 at gmail.com> <mailto:lcc1967 at gmail.com>
>> *To:* opensim-dev at lists.berlios.de <mailto:opensim-dev at lists.berlios.de>
>> *Sent:* Monday, December 8, 2008 9:11:05 AM
>> *Subject:* Re: [Opensim-dev] rex auth & avatar systems (Re: future 
>> rexviewer merger)
>>
>> "Rex avatar server was out and TPing from SL to a Rex grid was done
>> before LL made the gridnaughts. The Rex group is ahead of the curve.
>> It probably will not hard for them to retool and go backwards to be
>> compatible with others are doing. But you have to remember that Rex
>> server is really the leader, the others are just following and not
>> acknowledging the work that has been done already."
>>
>> Please don't speak in the name of ReX pple particularly when you 
>> don't know what you are talking about.
>>
>> Sm
>>
>>  
>> ------------------------------------------------------------------------
>>
>>
>>   
>>  
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de <mailto: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/20081210/61dfdcbf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 227 bytes
Desc: not available
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081210/61dfdcbf/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1150 bytes
Desc: not available
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081210/61dfdcbf/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1138 bytes
Desc: not available
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081210/61dfdcbf/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2857 bytes
Desc: not available
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081210/61dfdcbf/attachment-0007.png>