The grid that the object was created on is, by definition, authoritative. I don't see a way that it can abuse that position. I do believe that we need to be able to have a display name even if that provider doesn't exist anymore, and i believe that we need to minimize remote lookups. I don't want my sims to look up the identity each time a prim is clicked in build mode. That would be a ridiculous amount of traffic. Also, see my previous posts.
Also, I believe we need to avoid a central registry at all cost. Melanie Dahlia Trimble wrote: > This looks to me to be an attempt to provide local caching of relevant > information for reducing lookup requirements and seems a usable approach as > long as the extra data is known to be non-authoritative. It does bring a > implementation-specific form into something that has potential to becoming a > standard of sorts and that may be a concern. It does not appear to address > the problem of fly-by-night service providers or those who may try to profit > excessively from a position of providing an authority. Personally I don't > like the idea of having a paid subscription service having any control over > my ability to surf the hypergrid, and as such I''d prefer to see the UUID > portion be the authoritative lookup key and the lookup domain portion be > considered a suggestion at best. UUIDs by design have sufficient variability > where collisions are highly unlikely so I don't see collisions as being an > issue even if they are independently generated by independent providers. > > On Sun, Aug 29, 2010 at 4:44 AM, Melanie <[email protected]> wrote: > >> We should. >> >> Also, we should use extra info in the URI. Reson: >> >> http://www.avination.net:8004/user/44626b40-13d6-4817-b61b-de5df7b5e7e8 >> >> The above is totally meaningless. It can't be used to do anything >> with unless www.avination.net exists and points to a gatekeeper. >> >> However, >> >> >> http://www.avination.net/user/44626b40-13d6-4817-b61b-de5df7b5e7e8/Melanie+Milland >> >> makes more sense here. >> >> The URI itself provides a "Display name" that the resolver at that >> URL can treat as extra path info and ignore, if it chooses. >> >> This would allow us to create a temporary memory cache record of the >> UUID -> name mapping that would let us display a prim creator >> without a lookup, which is a potentially frequent process. >> >> The sim can take the URL at face value and diassemble it, using >> 44626b40-13d6-4817-b61b-de5df7b5e7e8 -> "Melanie >> [email protected]" for the cache and returning that to the >> viewer as the creator, all without a lookup. >> >> While this doesn't prevent verification of stale URI's from failing, >> it does allow to display a meaningful text if that happens. >> >> Melanie >> >> [email protected] wrote: >> > Looks like ppl are reading more into this discussion than I intended. >> > >> > The hypergrid is up & running with all authentication and security in >> > place, and so are exchanges of content via HG and archives. What's >> > missing is *systematic* global identification of resources. OpenSim >> > already does that internally for resolving *certain* identifiers on the >> > Hypergrid, but nothing is stored persistently yet. That is going to >> > change soon, because 1) I want to make friends & IM work across the HG >> > (so, for example, your foreign friend needs to be identified by a global >> > ID); and 2) we really need to fix the b0rked "creator" field in >> OARs/IARs. >> > >> > This means that we need to write URIs persistently, both in certain >> > fields of the DB (which is already prepared for what's coming) and in >> > the archives. >> > >> > So the issue here is really narrow. Assuming everyone agrees that we >> > should use URIs, should we add type information in the URI or not? Any >> > other thoughts on the *form* of these URIs? >> > >> > >> > [email protected] wrote: >> >> May be good to share what your use case is. As universal are you >> suggesting >> >> an identifier that separate, potentially un-trusted domains, would use >> to >> >> identify the same person? >> >> >> >> Is so I don't think you can do that with two parties, you need at least >> one >> >> more party to validate that they are the same person, like how we do >> with >> >> SSL certificates, or with some kind of authentication, like you send me >> an >> >> email address which gets me to a profile, but I still need to enter in a >> >> password or something to get access to that profile. >> >> >> >> M. >> >> >> >> -----Original Message----- >> >> From: [email protected] >> >> [mailto:[email protected]] On Behalf Of Ai Austin >> >> Sent: Saturday, August 28, 2010 4:59 PM >> >> To: [email protected] >> >> Subject: Re: [Opensim-dev] Global identifiers >> >> >> >> diva wrote: >> >>> I'm about to introduce global identifiers, so that I can make friends >> >>> and IM work on the hypergrid, and would like feedback on the best form >> >>> of these identifiers. >> >> >> >>> Here are some options: >> >>> ... Thoughts? >> >> >> >> >> >> A couple of thoughts and observations Diva... >> >> >> >> Could the taxonomy of "types" you use cause problems if the chosen >> >> 1-1 mapping for a UUID is not felt to work well i future. >> >> >> >> "user" is also perhaps a different notion to a specific "avatar" >> >> >> >> It would be nice if any UUID in a URI you use can be resolved (e.g. >> >> to the avatar name) by any host that has the mapping (like the >> >> distributed nature of DNS works), so its not dependent on the host >> >> continuing to exist, or to be up at the time information on the >> >> avatar is sought. >> >> >> >> AS an example, we have shifted our data bases between machines and >> >> have done so 3 or 4 times since we started running OpenSim, carrying >> >> the UUIDs of avatars (and the UIIDs of regions we use) forwards to >> >> the new data bases. >> >> >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> [email protected] >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> [email protected] >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > _______________________________________________ >> > Opensim-dev mailing list >> > [email protected] >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> > >> > >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
