[Opensim-dev] User/Agent/Avatar Was: Question on Avatar Appearance persistance

Mon Apr 14 18:31:06 UTC 2008

I think one thing to consider here is that the concepts of agents is intrinsic to the operation of a sim. That is, when an avatar logs onto a region, agents are created on the adjacent regions. Thats partly how we can view terrain and prims on an adjacent region.

When an avatar crosses from one region to another, its agent is promoted, therefore making it visible and having additional abilities. So, when we speak about agents, we are really speaking from the existing viewpoint of how scenes are setup and how we allow a certain type of interaction between regions.

Charles

----- Original Message ----
From: Diva Canto <diva at metaverseink.com>
To: opensim-dev at lists.berlios.de
Sent: Monday, April 14, 2008 11:14:28 AM
Subject: Re: [Opensim-dev] User/Agent/Avatar Was: Question on Avatar Appearance persistance

  This is great! 8-) I'm looking forward to OpenSim having these conceptsall cleared out, and the decoupling in place. I'm still not convincedthat the goal of agents automatically taking different avatars indifferent grids is a worthy goal, because people can always getaccounts in those places if there is a special code there. 

...You need to think about the larger consequences of these gamingpractices, which make sense for games but can be severe for seriousapplications. For example, I would simply hate that my avatar would beforced to wear a head-to-toe veil whenever I visit a world hosted inSaudi Arabia... But since that is a super-set of what I'm saying, I'mnot going to argue [much]; if OpenSim ends up supporting that kind ofthing, I'll simply stay away from worlds that will *impose* anything onmy choices for my avatar's appearance or inventory. Unless, of course,I choose to sign up for a role-playing game (and I can imagine somewestern people looking at the veils and the discriminatory practices inSaudi Arabia as nothing but a role-playing computer game... /me shakeshead).

Anyway, the way things are right now,  there's enormous value-added inOpenSim already: opening the source is crucial, having the ability toextend region features is extremely important, physics is important,supporting full LSL and beyond is important, etc. etc., but... there'sthis one feature -- or whatever you want to call it -- that I think isthe single most important thing that will make OpenSim theinfrastructure that most organizations (around me) will want. We canall live with bugs and incompleteness for a while, but we need to knowthat we can have visits from people not registered here and let themvisit without us having to give them any persistent resources orimposing anything on them (if someone shows up naked to a virtualclassroom, the negotiation will happen as it would have happened in thereal world -- through a conversation and eventual eject). 

Michael Wright wrote:Yup there is certainly division between the various layers, and I think at times we have all got confused about the differentterms in opensim. 

I think the general layout is something like:

Users - can have a account with authentication and profile data etc. Weshould offer support for anonymous users too (configurable, if it isenabled or not)

Agent- can be thought of  as the connection between the client and aregion.  So the agent in the region, that contains the user's avatar,is called the root agent. But the client can  have child agents in theneighbouring regions. The agent connection is at the region level, soin opensim they "own/have" a ScenePresence that is its entity in the 3dworld...

ScenePresence- they are the entities representing the agents in the 3dworld, They have a position etc. The root agent's ScenePresence has/isa physical Avatar, so other users will see it. While the child agent'sScenePresence can be thought of ghost entities, that can see otheravatars but can't be seen itself.

It is possible that some clients could be created that don't actuallyhave any ScenePresences connected to their agents. And still allowthings like textures to be uploaded or inventory to be managed. Or evenmessages broadcast into the 3d scene. Like maybe region Admin Clients.

I think that there has to be some decoupling between Users/Agents andAvatars. As yes for some cases you want to take the same avatar aroundeverywhere with you but that is not always the case. As I said beforesome Games or whatever might want to give you a avatar for use in thatapplication. So we just need to make sure we support the differentcases. Also some 3d visualisation applications might not want anyavatars, just all users having ghost entities. 

OpenSim is not about creating one single type of metaverse. It is aboutcreating a 3d multi user platform that various applications, includinga global shared metaverse, can be built on top of.

  Stefan Andersson <stefan at tribalmedia.se> wrote:      .hmmessage P {margin:0px;padding:0px;}body.hmmessage {FONT-SIZE:10pt;FONT-FAMILY:Tahoma;}Diva,

the division of agent and avatar is definitively therere; you can have'agents' in neighbouring regions that communicates changes in thoseregions, but these does not have avatars associated with them. Agents(both child and root) also has a 'camera' that is positioned in theregions.

An agent needs no 'name' at all, but authentication credentials; anavatar needs no credentials, but has a 'name'.

Technically, what a region needs is a (trusted) source to tell it toexpect an agent connection with certain properties, then an agent thatconnects with those properties. It also needs to know where to fetchthe information to send to that agent in response to agent requests. AsOpenSim evolves, we will probably less and less assumptions regardinghow this is organized and communicated.

I was actually not discussing persistence at all; your comment aboutpersistence being a burden is 100% right.

When I say 'grid' I merely use a well-known term for 'resourcediscovery scope'.

As I mentioned, the 'User' concept, and with it user profile, is(probably) out of scope and best left implemented somewhere else; 

but being able to separate agent login credentials from avatar name isdefinitively within scope.

Also, my note was as a response to the current state of the region anduser storage - I was merely trying to get us to take a (relatively)small step towards a more generic model; which would then let us workbetter with various authentication and naming schema. (For example, theone I'm working with now, which clearly needs separation between logincredentials and avatar name)

/Stefan

           Date: Sun, 13 Apr 2008 12:56:13 -0700
From: diva at metaverseink.com
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] User/Agent/Avatar Was: Question on AvatarAppearance persistance

      That is a possibility. However, it seems a bit more complicated thannecessary: you don't necessarily need to separate the concept of"agent" from the concept of "avatar", a 1-to-1 relation between theseis fine. 

I'm imagining the interaction of what you propose: I (actual person)sign up to the metaverse with one of many agent credentials, say myverisign credentials; suppose I have another one at yahoo, for example,or even a second one at verisign; then the viewer makes me choosebetween my many online names of avatars associated with my firstverisign agent -- that's the step I think is unnecessary. Since I canhave many accounts anyway, I don't need many avatars per agent. --although I can see what you are saying is inline with the prevalentmodel of avatars being a grid concept, and therefore being able tochange as one goes around different grids with the same agent.

In my view of things, users and agents, along with their credentials,storage and comms, would be served outside of grids, and there would beno *persistent* representation of them at the grid and regions serverlevels -- although grids might choose to provide thatuser/identity/agent service too, at least for some people. But thisservice would be completely separate.

I would like to sign up to the metaverse under one of my accounts andbe able to go around many grids. There will be grids that won't allowmy account there. That's fine. If I really want to go there, I shouldget an account with that grid, or with whatever identity service itaccepts.

What you're proposing is one step more generic than what I, personally,need. More importantly, wearing my hat of a close advisor toorganizations who are interested in developing services in 3D, I thinkthat any persistent user/avatar representations at the grid level are aburden for these organizations. They will want visits from millions ofpeople, and they don't want to store any information about thoseavatars, other than logging their visits.

The best way of envisioning what I'm saying is to place yourself in theshoes of a university.

Stefan Andersson wrote:              .ExternalClass .EC_hmmessage P {padding:0px;}.ExternalClass body.EC_hmmessage {font-size:10pt;font-family:Tahoma;}Ehrm , not to spin off in too many directions at once, but we reallyshould acommodate for a somewhat more comprehensible set of concepts:

"User" : an actual acting person in the real world - 
  * can have many Agents (consider same person running-multiple viewers)
  * has a real name, and an online name
  * has a profile with profile data
  * has credentials, to be able to be authorized
"Agent" : the informational representation of a user in a world
  * has credentials, to be able to be authorized
"Avatar" : the visual representation of an agent in a world (only oneper Agent in the SL universe afaik)
  * has an online name
  * has a profile, with profile data
"Credentials" : data supplied for authentication (user names, keys,passwords, hashes, et c)

One example:

I'm Stefan Andersson in the real world. When I don't want to disclosemy full real name, such as in IM lists, I just call myself 'Stefan'(which, in this case, is my chosen 'online name' or 'calling name').

Now, in most user databases, I need a unique login credential, usually,i choose the username 'lbsa71' since that's available more often than'Stefan'.

Now, of course, I have a couple of avatars in SL, one of them is called"PierreJoseph Proudhon" (first/last construct by SL convention -strictly not necessary)

To choose what avatar I want to join SL with, and at the same timeauthorize myself, I enter an avatar name and avatar password into theviewer, which then uses it to authorize the agent with which I enterthe 3D world.

My point here, is that although this is how SL works, it's not howOpenSim ought to work. The same 'shortcuts' could be the defaultimplementation, but we really should be able to log in with one set ofcredentials, which would not be tied to the avtar at all. Also, someother viewers or launch methods might let the user log on with his usercredentials, and simply CHOOSE his avatar (the web page login methodwould allow for such a scheme)

I guess we might not even want to consider the 'user' and hiscredentials, and leave that to various implmentations (like, how eachgrid has their own user profile) but we should definitively call theAvatars profile data 'AvatarProfile' - and separate "Agent logincredentials" from "Avatar online name".

So; awaiting feedback, I propose we work towards the model outlinedabove.

Best,
Stefan

> Date: Sat, 12 Apr 2008 08:00:22 -0400
> From: sean at dague.net
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Question on Avatar Appearancepersistance
> 
> On Fri, Apr 11, 2008 at 06:09:56PM +0100, Michael Wright wrote:
> > okay will try to make this my last email (before anyonereplies) on this. But I think I'm understanding more of what you meant.        
> > 
> > And while I think there is no reason why we couldn't have
> > AvatarAppearance hanging off UserProfile data. I'm still notconvinced
> > there is a need to try to connect all these things. AvatarAppearance
> > is certainly a scene thing. In that every ScenePresence needsa
> > reference to one. But we could move the actual Av atarAppearance
> > class out to OpenSim.framework, or if going with the "AnemicDomain
> > Model" appoach suggested by Stefan then we could have a base
> > AvatarAppearance in the model project. Then in the avatarappearance
> > module fetch the appearance object that was attached to theuser
> > profile.
> > 
> > But I'm not sure I really see any benefit in this over themodule
> > doing a direct request to the user server for the appearance.I
> > actually think its better to decouple things in this way.
> 
> By decoupling from the user server, we've coupled AppearanceModuleto
> DataMapper, and are managing database connections in aRegionModule,
> which I think is a worse approach. 
> 
> m_scene.CommsManager.UserService.GetUserProfile(id) seems
> like a much better approach. We could just add .GetUserAppearanceand
> friends to it.
> 
> > As I said in my last email, there could also be somebots/NPC's that
> > don't have userprofiles. And also I think there is a chancethat scene
> > presences are created (and the appearance fetched) before theuser
> > profiles are. But can't be sure of that without lookingdeeper in the
> > code.
> 
> If an NPC exists in the environment, I would think it would have a
> profile (it needs that for Name for instance).
> 
> > But anyway as long as we went through the avatar appearancefactory
> > module concept to fetch the appearance that was attached tothe user
> > profile. Then I guess there is nothing stopping it. Justseems a
> > coupling that isn't needed.
> 
> Yes, that's probably strictly true. Actually, we don't really needit
> hanging off of UserProfile. What I really meant was that
> AvatarAppearance was an object that existed, and wasfetchable/updatable
> from the UserService by UUID.
> 
> > I am very strongly of the opinion that we need to keep thefactory
> > module concept. So that a different module could be used.Different
> > regions/applications might want a completely differentapproach to how
> > the appearance of the avatars are handled. Like a game mightwant to
> > randomly just give each user one of a set of preset avatars.
> > 
> > But with this factory module. We can actually fetch theappearance
> > from where ever we want, including the userprofile if it isdecided.
> 
> If we move the default storage back into UserService, I don't think
> we'll have an issue here. UserService will just support apersistance
> model for appearance, should anyone want to use that. Howappearance is
> created remains in the region modules.
> 
> -Sean
> 
> -- 
> __________________________________________________________________
> 
> Sean Dague Mid-Hudson Valley
> sean at dague dot net Linux Users Group
> http://dague.net http://mhvlug.org
> 
> There is no silver bullet. Plus, werewolves make better neighbors
> than zombies, and they tend to keep the vampire population down.
> __________________________________________________________________

_______________________________________________
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

   Yahoo! for Good helps you make
a difference  
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

-----Inline Attachment Follows-----

_______________________________________________
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/20080414/f9c99f26/attachment-0001.html>