Subject: Re: [vwrap] [Opensim-dev] Global identifiers

From: "Hurliman, John" <[email-masked]>
Date: Mon, 30 Aug 2010 13:39:01 -0600

I'd like to throw in my two cents to this discussion as the Virtual Worlds Infrastructure team at Intel has spent some time thinking about this issue, presenting on it at IETF-77, and trying to prototype something that actually works (not an easy feat!).

Let me preface by saying that while compatibility with the Linden viewer may be a short term benefit, ultimately it is not relevant to the discussion. Whatever method we decide on will be made to work with current and future viewers through any means it takes, which might be another layer of viewer compatibility abstraction sitting on top of our "clean" model or it might just work naturally with whatever we use.

The question of internally storing local identifiers or global identifiers is primarily an optimization question in my mind. We already have a great system in OpenSim for storing account metadata, referencing it, requesting it, caching it, etc. This is an optimized system that I know we've spent a lot of time on because I've personally submitted and received patches that allowed it to deal with the load of identifying the permissions for 15,000+ objects in a scene created and owned by dozens of different avatars and groups. If we can leverage this existing system we'll be a long ways ahead on building something that will scale to millions of independent grids. The work on OpenSim Archives (OARs), Inventory Archives (IARs), and HyperGrid have already paved most of the way on how we can do this. Any time a new identity is recognized by a grid whether it be an incoming HG teleport, an OAR load, a prim being rezzed from a foreign grid with an unrecognized creator, or any other means, you create a local identity that points to the global identifier. This is the only time when you can guarantee the global identifier will resolve and foreign account details can be fetched. With this extra bit of work up front, we can leverage the current identity system we have with very little effort. Extra icing on the cake can be added like periodically attempting to pull the latest account info into the local accounts or improving the profile display for identities with a foreign origin to link to their home grid or home identity for example, but the difficult part of the problem has already been solved. No rewriting APIs to handle a second type of account identifier, no dealing with the question of whether a global identifier will currently resolve or not, no additional abstraction layer to make things play nicely with the current protocols. Prims will show their creator names 100% of the time and it will use the same caching systems and optimizations that make local accounts work.

An open question with this approach is whether you need to use global identifiers when dealing with cross-grid scenarios, or whether there is always enough context to derive a global identifier. Some examples:

* A HyperGrid user is teleporting from grid A to grid B. Does grid B have enough information to build the global identifier "gridA/user"?
* A HyperGrid user rezzes an object into grid B that exists in their inventory on grid A. The object has a creator that is unrecognized to grid B. Should grid B pull the creator profile from grid A (which may actually be storing a local copy of the real creator identity from grid X)? Note that this isn't a question about trust because we're already trusting grid A to provide creator information for the object, it's just about where we pull profile info from.
* An OAR file is loaded and contains an unrecognized identity. Should identities in OAR files be encoded as global identifiers, or a header added to the OAR file to say "all of this content came from grid A", or the full profiles of all the identities in the OAR embedded right into the archive?

P.S. I'm CCing this to the VWRAP list as the participants there will be interested in how these architecture decisions are progressing in OpenSim, and may be able to lend more insight to the discussion.

-John

> -----Original Message-----
> From: [email-masked] [mailto:opensim-dev-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Monday, August 30, 2010 9:34 AM
> To: [email-masked]
> Subject: Re: [Opensim-dev] Global identifiers
>
> Let me throw another thought into this. It is related to the subtle
> differences of URLs and URNs, and Bob Wellman's suggestion.
>
> So far we are more or less converging to
> protocol://authority/resource_type/resource_id[/cacheable_info]
> with the [/cacheable_info] sill up for discussion. Independent on how
> you break this down in persistent storage, this is an URL, and one with
> specific assumptions about the existence of a resource_id.
>
> However, in the future we would like to interoperate with systems that
> aren't virtual worlds as such. In most of those systems, the resources
> are named with names that may not even be URLs and even if they are,
> they may not  have "resource_id" at all. For example,
>
> Cristiano Ronaldo's Facebook handle is
> http://www.facebook.com/Cristiano
>
> A Collada model has
> <contributor><author>John.Smith</author></contributor>
> (Wondering how Linden Lab is going to deal with this... )
>
>
> So this would not comply with the form above.
>
> Now, in practice, we have been designing under a fixed-point: the LL
> viewer. The LL viewer MUST have UUIDs for every resource that is sent
> from the server the client. So, in practice what this means is that
> every external resource reference must be assigned a local UUID if it
> doesn't come with one, which sounds like a very reasonable thing to do,
> and some people here already mentioned it.
>
> Nevertheless, the Collada example breaks the assumption that every
> named
> resource out there has an authority (locator) that we can refer back
> to.
> It may not. We can continue down the road of fixing missing information
> with default information. So, for example, if something comes in as
> John.Smith, our reference to it could be
> http://ourgrid/user/some_uuid/John+Smith -- even though there is no
> such
> account. But that's a slippery slope.
>
> This further supports the argument of having a table that maps between
> local UUIDs and external references. And maybe external references may
> take more than just one URI form, not just the one we have been talking
> about
> protocol://authority/resource_type/resource_id[/cacheable_info]
>
> Maybe it can also be a URN.
>
> Nevertheless, the semantics is important, because when an authority
> (locator) is present, the receiving grid may want to invoke it.
>
>
>
> Melanie wrote:
> > While you have a case with using a central table, rather than
> > storing the URL string, and therefore the name, all over the place,
> > your request schema would not work.
> >
> > First off, it overcomplicates (IMO) things if you even attempt to
> > show the current name of an identity. My plan has been to show the
> > name AT CREATION TIME on a prim, e.g. the displyed creator name of a
> > prim will not change, even if the underlying identity changes their
> > name. This removes much complaxity.
> >
> > Second, your system breaks when a prim is taken to a new grid after
> > the grid it was created on has vanished from the internet. In that
> > case, even the initial lookup will fail and you have no data to
> display.
> >
> > Therefore, I'd prefer to go with my initial recommendation and
> > indeed store the URL, including the name, "all over the place". The
> > client view can always decide to ignore that part and to a table
> > lookup, or even contact the grid of origin.
> >
> > It seems that a lot of people here are all for omitting information
> > that would be helpful for the 90% case in order to make their
> > particular corner case the norm. 90% of avatars never change names.
> >
> > Melanie
> >
> > Bob Wellman wrote:
> >> Can I subvert this discussion back to the original question of
> Global Identifiers?
> >>
> >>
> >>
> >> I have been following the discussion on Global Identifiers with
> interest and I see strong differences of opinion but merits in both
> arguments. I agree that hard coding meaning into the URI seems like an
> inflexible way forward but I also see that minimising lookup traffic
> between grids is desirable too. So I have been trying to think is there
> a middle way to compromise on this. I have the kernel of an idea I
> would like to put forward for discussion.
> >>
> >> Let us say we invent a new table in the local grids database (called
> UserLookup maybe) and the key to that table is the URI diva proposed
> (without the user name part) sent intially. Sorry Melanie but please
> read on before deciding.
> >>
> >> Draft table design here:
> >>
> >> 1) Original URI  (key)
> >> 2) Original User name
> >> 3) Last verification date.
> >> 4) Current user name
> >> 5) Current URI (optional idea see later)
> >>
> >> When the original URI is received (or later referenced) we do a
> check against this table to see if a lookup is available and proceed as
> follows:
> >> 1) If the lookup is not on file... we immediately send to the other
> grid for verification and the user name and we add the lookup to the
> table with original user name and current user name the same.
> >> 2) If the lookup is on file but out of date ... we send to the other
> grid for verification (this can be dleayed if need be) and take the
> latest feedback of user name and update the lookup with current name.
> >> 3) If the lookup is on file but not out of date (most times this
> will be the case) ... we do nothing.
> >>
> >> What constitutes out of date will be configurable in Opensim.ini
> (out-of-date= x days). In Melanie's case she will set forever as
> avatars must not be changeable. For others this can be tailored to
> their requirements of speed versus flexibility.
> >>
> >> The user service already looks up the Prims user UUID to decode the
> name for local avatars so it just would be changed to do this new
> lookup at the same time. I think of it this way ...The user service
> currently answer the question "who is this" and would now answer "who
> in the global community is this".
> >>
> >> This method keeps the database design 3rd normal form rather than
> storing key decodes all over the database, as to not do this will at
> some stage cause database chaos just like it did in appearance sometime
> ago. Can you tell I have a database design background...LOL
> >>
> >> If a grid goes bust or is temporary offline we have the last know
> user info to rely on using just local grid lookup, which covers the
> very valid argument Melanie made that we need to know identity even if
> the other grids no longer there.
> >>
> >> We can also have the ability to recognise that verification has not
> been available for a long time so cross grid IM is probably no longer
> available to this agent.  In the case of an avatar moving grid maybe
> the forwarding address can be sent back and the current URI stored (the
> fifth column) at the next look up verification. If the forwarding
> doesnt ecist or is only temporary, it does matter, as we have last
> known address stored at our grid, which is the best thats possible.
> Maintaining an IM link of freindship to an agent that moves grids
> becomes feasible too. So this keeps things flexible for those that
> think this is the correct approach long term.
> >>
> >> In summary this method reduces the need for massive cross grid
> lookups and still keeps the link between the URI and the user name
> flexible.
> >>
> >> Just my opinion (and I expect to be overruled) but felt I should say
> this anyway if only to purge my guilt of saying nothing just to avoid a
> slap down ...LOL
> >>
> >> Thanks for reading it.. Bob Wellman (PMgrid)
> >>
> >>
> >>
> >>> Date: Sun, 29 Aug 2010 19:59:34 -0700
> >>> From: [email-masked]
> >>> To: [email-masked]
> >>> Subject: Re: [Opensim-dev] Global identifiers
> >>>
> >>> See my previous email about what changed.
> >>>
> >>> We seem to have quite different concepts of what a standards
> process is.
> >>> In my book, a standards process is something that happens *after*
> >>> implementations exist, and preferably several competing ones; in
> the
> >>> people in VWRAP's book, it seems to mean "let's design something
> >>> together from scratch and on paper".
> >>>
> >>> Let's see how well these two concepts can co-exist. Maybe they
> can't!
> >>>
> >>> Meadhbh Hamrick wrote:
> >>>> what's changed?
> >>>>
> >>>> last year you (diva) seemed to have no interest in merging VWRAP
> with
> >>>> Hypergrid. if i remember correctly, hypergrid was going to go off
> and
> >>>> do an implementation while VWRAP went another way to try to
> >>>> incrementally build a standard and some code to implement it.
> >>>>
> >>>> there's still, of course, room for you at the table. but if i
> remember
> >>>> correctly, you seemed to have problems with LLSD/LLIDL (now about
> to
> >>>> get renamed DSD) and you had a security model that didn't work
> with
> >>>> zha's use cases.
> >>>>
> >>>> if you're interested in making the case for why VWRAP should adopt
> the
> >>>> hypergrid security model and drop DSD, you're welcome to
> participate
> >>>> in the VWRAP mailing list.
> >>>>
> >>>> and i encourage you to actually do so before dropping a spec on
> the group.
> >>>>
> >>>> -cheers
> >>>> -meadhbh
> >>>>
> >>>> --
> >>>> meadhbh hamrick * it's pronounced "maeve"
> >>>> @OhMeadhbh * http://meadhbh.org/ * [email-masked]
> >>>>
> >>>>
> >>>>
> >>>> On Sun, Aug 29, 2010 at 5:29 PM, <[email-masked]> wrote:
> >>>>> Melanie is just right, as usual... well, as in 90% of the time :)
> >>>>> The cacheable_data was a brilliant idea, and if you had
> experience with
> >>>>> OpenSim in the wild, in how volatile these worlds are and how
> much these
> >>>>> particular remote lookups lag the sims, you would come to
> appreciate it,
> >>>>> instead of being put off by her dominatrix attitude.
> >>>>>
> >>>>> OpenSim core has been contributing center-front in VWRAP: John
> Hurliman is a
> >>>>> core developer of OpenSim.
> >>>>>
> >>>>> Mike Dickson wrote:
> >>>>>> That's great to hear. And the first I've heard of it. I'm on the
> VWRAP
> >>>>>> mailing list and yes, John has made some very substantive
> contributions
> >>>>>> to the discussion. I haven't seen anything from OpenSim core
> during any
> >>>>>> part of the discussion to date. I'm a pretty smart guy but not
> >>>>>> omnipotent. I've simply interpreted the lack of participation as
> lack
> >>>>>> of interest and past comments would tend to support that (I can
> dig them
> >>>>>> out if you like). And there is no "general feeling" in VWRAP as
> to your
> >>>>>> proposal since its never been presented or discussed there.
> >>>>>>
> >>>>>> I'm not interested in a war, just open dialog and a sincere
> interest in
> >>>>>> interoperability. I'll be glad to read the proposal when its
> made. In
> >>>>>> the meantime I'd appreciate you not attribute negative motives
> to
> >>>>>> anything I've said. I've been simply trying to make technical
> arguments
> >>>>>> against an approach I think is wrong headed and not though out.
> I've
> >>>>>> seen discussion here pretty much get cut off when a core member
> >>>>>> "dictates" the solution. Melanie seems to have made up her mind.
> Fine.
> >>>>>> Go build it. Best of luck to you. In the meantime I'll look
> forward to
> >>>>>> the Hypergrid proposal to VWRAP and reserve my comments for that
> time.
> >>>>>> BTW, I've found the VWRAP discussions to be pretty open and
> devoid of
> >>>>>> politics. People will assert politics over almost anything of
> course
> >>>>>> but the dialog has been mostly open and good natured (and quiet
> lately).
> >>>>>> It will be good to have you at the table. Given OpenSim gets a
> fair bit
> >>>>>> of attention it would have been nice if you'd been there all
> along.
> >>>>>>
> >>>>>> Mike
> >>>>>>
> >>>>>> On Mon, 2010-08-30 at 00:00 +0000, [email-masked] wrote:
> >>>>>>> Mike,
> >>>>>>>
> >>>>>>> That's an interesting statement to make, considering that John
> Hurliman
> >>>>>>> and I are working on writing up the *working* Hypergrid 1.5 as
> a proposal to
> >>>>>>> VWRAP, since we have both concluded that the concepts being
> talked there
> >>>>>>> lately, without any implementation behind them, are essentially
> >>>>>>> indistinguishable from the working HG 1.5 that lots of people
> are already
> >>>>>>> using.
> >>>>>>>
> >>>>>>> It seems that you are trying really hard to make this look like
> a war
> >>>>>>> between OpenSimulator and VWRAP. I don't think that's the
> general feeling in
> >>>>>>> VWRAP, I think it's just you. The proposal to VWRAP will
> happen. Hopefully,
> >>>>>>> most people there will be able to assess the technical issues,
> independent
> >>>>>>> of the political ones. (emphasis on *hopefully*)
> >>>>>>>
> >>>>>>> Diva / Crista
> >>>>>>>
> >>>>>>> Mike Dickson wrote:
> >>>>>>>> Fine, then do what you like. The code's all available. If I
> don't like
> >>>>>>>> it I can change it. Of course that sort of shoots holes in
> >>>>>>>> interoperability. But then I didn't feel that hyper-grid
> belonged in
> >>>>>>>> core either for the same reason.
> >>>>>>>> I think you've way over trivialized the whole set of
> interactions
> >>>>>>>> between agent, asset and simulator services in situations
> where those
> >>>>>>>> services are defined by different principals. As Meadbh said,
> this
> >>>>>>>> feels like optimizing to solve a specific problem before
> you've really
> >>>>>>>> looked at the larger issues. It might be instructive just to
> simply walk
> >>>>>>>> through some use cases and see where things fall apart. Alot
> of that
> >>>>>>>> discussion has already taken place on the VWRAP list but
> OpenSim core
> >>>>>>>> seems to be dead set against involvement in that.
> >>>>>>>>
> >>>>>>>> I don't see a way to contribute here beyond the opinion I've
> already
> >>>>>>>> voiced so I'll drop this.
> >>>>>>>>
> >>>>>>>> Mike
> >>>>>>>>
> >>>>>>>> On Sun, 2010-08-29 at 22:56 +0000, Melanie wrote:
> >>>>>>>>> Sorry, i disagree. The information included is defined by the
> >>>>>>>>> REQUIRED data on the recipient, not on what data the sender
> wants to
> >>>>>>>>> provide. the recipient NEEDS a displayable field. It can't be
> optional.
> >>>>>>>>>
> >>>>>>>>> Melanie
> >>>>>>>>>
> >>>>>>>>> Mike Dickson wrote:
> >>>>>>>>>> If the decision is to go ahead and do cache-able data then
> I'd agree,
> >>>>>>>>>> do
> >>>>>>>>>> it as attribute NVP's and make them optional. The
> originating agennt
> >>>>>>>>>> service is then free to define the semantics of the
> attributes it
> >>>>>>>>>> exposes.
> >>>>>>>>>> Mike
> >>>>>>>>>>
> >>>>>>>>>> On Sun, 2010-08-29 at 21:42 +0000, Ai Austin wrote:
> >>>>>>>>>>>> From: [email-masked]
> >>>>>>>>>>>>
> protocol://authority/resource_type/resource_id[/cacheable_data]
> >>>>>>>>>>> +1
> >>>>>>>>>>>
> >>>>>>>>>>> consider ensuring that at least the name is provided in a
> form that
> >>>>>>>>>>> can be resolved fast and locally by including the avatar
> firstname+lastname
> >>>>>>>>>>> - in whatever form the providing grid wishes to address
> issues raised by
> >>>>>>>>>>> others - so long as the strings are "legal" in the
> creator/owner fields.
> >>>>>>>>>>>
> >>>>>>>>>>> would it be worth making sure that the "cachable data" is
> in the form
> >>>>>>>>>>> of keyword=value pairs, and hence put in a "parameter" form
> after ? rather
> >>>>>>>>>>> than a final /?
> >>>>>>>>>>>
> >>>>>>>>>>>
> protocol://authority/resource_type/resource_id[?key_value_pair[,...]]
> >>>>>>>>>>>
> >>>>>>>>>>> with a minimum suggested (or required?)
> >>>>>>>>>>> avatarname=firstname+lastname if the resource_type = user
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> Opensim-dev mailing list
> >>>>>>>>>>> [email-masked]
> >>>>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> Opensim-dev mailing list
> >>>>>>>>>> [email-masked]
> >>>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Opensim-dev mailing list
> >>>>>>>>> [email-masked]
> >>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>>>>>>> _______________________________________________
> >>>>>>>> Opensim-dev mailing list
> >>>>>>>> [email-masked]
> >>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Opensim-dev mailing list
> >>>>>>> [email-masked]
> >>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>>>> _______________________________________________
> >>>>> Opensim-dev mailing list
> >>>>> [email-masked]
> >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>>>>
> >>> _______________________________________________
> >>> Opensim-dev mailing list
> >>> [email-masked]
> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> ----
> >>
> >> _______________________________________________
> >> Opensim-dev mailing list
> >> [email-masked]
> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
> > _______________________________________________
> > Opensim-dev mailing list
> > [email-masked]
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> _______________________________________________
> Opensim-dev mailing list
> [email-masked]
> https://lists.berlios.de/mailman/listinfo/opensim-dev

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 30 Aug 2010 14:38:42 -0600

> [email-masked]] On Behalf Of Melanie
> Sent: Monday, August 30, 2010 1:09 PM
> Cc: [email-masked]
> Hi,
> Hurliman, John wrote:
> [...]
> > * A HyperGrid user is teleporting from grid A to grid B. Does grid B
> have enough information to build the global identifier "gridA/user"?
>
> They may not teleport in from their home grid. Also, they may be
> carrying objects from other creators, that may have passed through
> any number of grids, any number of which may not exist anymore.
>

This is a good argument in support of fetching information from the most recent grid containing an identity instead of trying to go back to a point of origin. By embedding metadata like a display name in a URL/URN this is effectively what you are doing, we're just talking about what the on-the-wire format looks like at that point. I don't have any strong preference about how global identities are passed around between foreign grids and through export formats.

> > * A HyperGrid user rezzes an object into grid B that exists in their
> inventory on grid A. The object has a creator that is unrecognized to
> grid B. Should grid B pull the creator profile from grid A (which may
> actually be storing a local copy of the real creator identity from grid
> X)? Note that this isn't a question about trust because we're already
> trusting grid A to provide creator information for the object, it's
> just about where we pull profile info from.
>
> Grid X may no longer exist. That is why I am so strongly for having
> enough information contained in the URL to be able to at least
> display a name, and, for performance reasons, do no lookups at all
> unless the request is for more than name display (e.g. communication).
>

It sounds like we are on the same page for everything, there's just the question of how to represent global identities coming into a grid before they are translated into a local identity. I'll defer to the expertise of others here. I'm generally more in favor of using URLs (even if they are non-opaque) instead of a new URN format. If a grid only cares about storing the display name in the profile and is happy to leave the rest of the profile data blank then no request would be needed at all here, it can just create the local account with a new UUID and the given name and continue on.

> > * An OAR file is loaded and contains an unrecognized identity. Should
> identities in OAR files be encoded as global identifiers, or a header
> added to the OAR file to say "all of this content came from grid A", or
> the full profiles of all the identities in the OAR embedded right into
> the archive?
>
> Oar and Iar should always translate the identifiers to global
> format, and may be written to translate loaded data back to local
> format if it originated with the grid loaded into.
>
> >
> > P.S. I'm CCing this to the VWRAP list as the participants there will
> be interested in how these architecture decisions are progressing in
> OpenSim, and may be able to lend more insight to the discussion.
> >
> > -John
> >
> >

---

From: Melanie <[email-masked]>
Date: Mon, 30 Aug 2010 22:08:36 +0200

Hi,

Hurliman, John wrote:
[...]

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 30 Aug 2010 14:45:08 -0600

My interpretation (please correct me if I'm wrong) is that there is rough consensus on the overall strategy, but an open question of how to encode global identities when cross-grid communication (or out-of-grid archiving) happens. There is probably also a hidden question of how to mark a local account as linked to a foreign identity, which may solve the friending issue. If I am friends with your avatar and we are both on grid B but your avatar actually originated from grid A, that link in the profile is what can tip off the presence service to try a remote presence check (assuming the user is not online in the local grid). My only interest in these low level questions like how the global identifiers and profile links look is what the final decision is so I can implement it in the OpenSim SimianGrid connectors.

John

> Sent: Monday, August 30, 2010 1:36 PM
> I have different answers than Melanie.
> 
> > An open question with this approach is whether you need to use global
> identifiers when dealing with cross-grid scenarios, or whether there is
> always enough context to derive a global identifier. Some examples:
> >
> Yes. It already does that on the spot. We don't need persistent global
> identifiers for agents.
> 
> The issue we are now talking about is if someone in grid B makes
> friends
> with this user. In this case, we need to add an entry to grid B's
> Friends service referring to an external user, and vice-versa. That's
> when we need global identifier for this user (not its agent).
> 
> Yes, it should. And since the code that does that is exactly the same
> code that prepares inventory items for archiving, this should be no
> different than archiving itself.
> 
> I don't think it can be bulk in the general case, although that could
> be
> option in some cases. I'm looking at my inventory right now and it's a
> rainbow of stuff I got from all sorts of places.

---

From: [email-masked]
Date: Mon, 30 Aug 2010 13:36:07 -0700

The issue we are now talking about is if someone in grid B makes friends 
with this user. In this case, we need to add an entry to grid B's 
Friends service referring to an external user, and vice-versa. That's 
when we need global identifier for this user (not its agent).

> * An OAR file is loaded and contains an unrecognized identity. Should identities in OAR files be encoded as global identifiers, or a header added to the OAR file to say "all of this content came fr…

I don't think it can be bulk in the general case, although that could be 
option in some cases. I'm looking at my inventory right now and it's a 
rainbow of stuff I got from all sorts of places.

---

From: [email-masked]
Date: Mon, 30 Aug 2010 14:09:05 -0700

Hurliman, John wrote:
> My interpretation (please correct me if I'm wrong) is that there is rough consensus on the overall strategy, but an open question of how to encode global identities when cross-grid communication (or out-of-grid archiving) happens. 

That's what's going on.
Up to now, all global identifiers (that already exist) have been 
volatile; nothing has persisted. As I found myself writing code that 
would inject global identifiers into a DB table, I thought we should all 
talk about the form of such identifiers.

> There is probably also a hidden question of how to mark a local account as linked to a foreign identity, which may solve the friending issue. If I am friends with your avatar and we are both on grid B but your avatar actually originated from grid A, that link in the profile is what can tip off the presence service to try a remote presence check (assuming the user is not online in the local grid). My only interest in these low level questions like how the global identifiers and profile links look is what the final decision is so I can implement it in the OpenSim SimianGrid connectors.

Well, we distinguish "user accounts" from "grid users" -- these are 2 
different interfaces, although implementers may decide to collapse them. 
But they are different concepts. User accounts are the 
locally-registered users; in some cases, like for example, the UCI grid, 
there's only some people who can get accounts there, namely people 
associated with the university. Grid users are users that are referenced 
by things that happen in the grid. So we already have an interface for 
that, although now I'm thinking that perhaps we need to separate its 
UserID field into 2 things: a local UUID and a reference to the external 
name. And I guess that's my main issue at this point.

---

From: <[email-masked]>
Date: Mon, 30 Aug 2010 17:47:08 -0400

ETL systems have dealt with this stuff for years and usually there is one
main rule, external references are kept separate from internal references
and you never carry external references into your internal stuff.

As such internal objects often contain a reference or a flag that identifies
their external source.

So for OpenSim what that means to me is there are profiles, but some
profiles are proxies to profiles on external grids.  Once these profiles are
created they should act and perform like any other locally made profile
except for the fact that some of its functions are proxies to the real
instance.  So I think you have most of this from what I would follow.  I
would say you need two pieces of information, the external source, and their
identifier.  The two fields can take completely different forms depending on
the external system.  If the source was Facebook, it could look completely
different than a iphone telephone application that may be external system of
ATT and an identifier of a telephone number.  Mainly I think you need to
make a wall between this external information and the use of the profile
internally.

If this profile rezzes an object there are several pieces of information I
understand you would like to keep, the creator and the owner.  To me I see
no difference in this, when the object is taken from inventory and an
instance is made of it, both of these profiles need to exist locally, but if
both are proxies then their profiles will contain the needed references to
the external system and identifier.  I would say they need to point to the
original system and identifier since just like email, no matter how many
emails get passed around, the email still refers back to the system of
origin.  The prim has no system of origin, it only has a creator and an
owner.

The textures, other prims and other items would all follow the same process.
The items would have to be copied locally, local instances made for them and
I would think would follow the same caching rules any other item in the
world follows.

Now if you would take that item back into inventory and travel to another
grid and rezz it.  I think the question is what you give as the external
source and identifier for the creator and owner.  I would suggest any
proxies would give the external system and identifier and not chain proxy to
proxy unless there is a reason to do it, and the assets should be copied
from the original source.  I think that solves a lot of legal issues to,
because you may have rights to use a cached item, but you may not have
rights to transfer it.

I see IM, friends and everything else working the same.

So I probably didn't help you with your original question about global
identifiers.  From my experience with ETL and large enterprise systems I
suggest you have one you like to use but I see there being many forms of
these fields because of all the varieties of systems.  There may well be
authentication codes that go with them to, like OAuth keys giving
permissions to access these external items.

Regards,
M

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, August 30, 2010 5:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Opensim-dev] Global identifiers

Hurliman, John wrote:
> My interpretation (please correct me if I'm wrong) is that there is rough
consensus on the overall strategy, but an open question of how to encode
global identities when cross-grid communication (or out-of-grid archiving)
happens. 

That's what's going on.

> There is probably also a hidden question of how to mark a local account as
linked to a foreign identity, which may solve the friending issue. If I am
friends with your avatar and we are both on grid B but your avatar actually
originated from grid A, that link in the profile is what can tip off the
presence service to try a remote presence check (assuming the user is not
online in the local grid). My only interest in these low level questions
like how the global identifiers and profile links look is what the final
decision is so I can implement it in the OpenSim SimianGrid connectors.