[Opensim-dev] Global identifiers

Karen Palen karenpalensl at gmail.com
Tue Aug 31 17:57:08 UTC 2010 

I agree that hypergrid does not introduce any new concerns over what we see
in ordinary web pages. However that leaves a lot of room for problems!

My concern is that we are storing those "web pages" in a database and making
decisions based on that information. I see the potential for the data to
simply degrade over time as more and more references become "bad" in one way
or another.

Maybe I have missed something, but I have not seen any discussion of how
issues of stale or misguided references are to be handled!

Do we just accept that over time our "authorities" will disappear? What does
that imply for the objects which depend on those authorities?

If the "authority" can simply disappear with no effect, then why bother
recording it at all? A simple UUID would serve the same purpose - globally
as well as locally.

My understanding is that we DO use the "authority" for various things beyond
simple identification. Authentication, updating of information, and DRM
management come to mind.

This may or may not be an issue, but I think we need to examine the
possibilities and implications carefully.

Karen

On Tue, Aug 31, 2010 at 9:30 AM, <diva at metaverseink.com> wrote:

> Domain names that existed before cease to exist, and domain name transfers
> happen. This doesn't affect the Hypergrid only, it affects the entire
> Internet. As much as I would like to think that we are smarter than everyone
> else who has been designing and improving the Internet architecture for the
> past 40 years, I think we need to consider the possibility that we aren't
> smarter, and so we probably are not going to solve the general issue of
> stale, or otherwise misguided, references on the Internet...
>
> Karen Palen wrote:
>
>> The problem arises when the original URL no longer exists and one must
>> attempt to find the new authority somehow.
>>
>> Unless of course we are willing to accept that the URL/UUID merely
>> reflects a "point in time".
>>
>> Even then we get a problem if http://XYZ.com goes away and some time
>> (years) later a NEW http://XYZ.com appears and starts doing business on
>> the hypergrid. The new owner of the URL may or may not have any affiliation
>> with the old one.
>>
>> Karen
>>
>> On Tue, Aug 31, 2010 at 6:01 AM, Melanie <melanie at t-data.com <mailto:
>> melanie at t-data.com>> wrote:
>>
>>    This isn't an issue, the URL includes the authority, so no malicious
>>    collisions are possible unless the UUID is used in isolation. That
>>    should not be done. If a resource is to be used in a contect where a
>>    local identifier is required, a new UUID should be generated and
>>    attached to the URI, then that should be used. Never trust the UUID
>>    in the URI for anything but calling the URI itself.
>>
>>    Melanie
>>
>>    Karen Palen wrote:
>>     > It was buried in another post, but I maintain that the definitive
>>    problem is
>>     > not th eone where the "authority" simply disappears (wait to
>>    update the
>>     > cache), but where there are multiple "authorities" claiming the
>>    same UUID!
>>     >
>>     > There are numerous reasons why this could happen, ONE of which is
>>     > "malfeasance" (fraud)!
>>     >
>>     > More likely is the case where the cached "authority" is very much
>>    out of
>>     > date and there have been several changes since the last cache
>>    update! In
>>     > some situations this could happen in only a few minutes!
>>     >
>>     > Every other case resolves to (a) it is in the cache (update
>>    whenever we can)
>>     > or (b) the (single) authority can tell us what we should use as the
>>     > "name"/UUID
>>     >
>>     > While Diva has pointed out that EVERY "name" is really a UUID
>>    (not obvious
>>     > in the "global" case) many of the comments imply that the "name"
>>    is some
>>     > arbitrary text string!
>>     >
>>     > I claim that Diva is exactly correct - the UUID *IS* the name
>>    BOTH global
>>     > and local, and the "text string" (of whatever form) is merely the
>>    "human
>>     > compatible liveware" version.  ANYTHING else leads to an enormous
>>    number of
>>     > identity collisions!
>>     >
>>     > I think that it is all available in the "open" literature now,
>>    but in the
>>     > 1960's/1970's the US Military spent an enormous effort ($$$) to
>>    be certain
>>     > that the person with the badge "General Jack D. Ripper" really
>>    WAS that
>>     > person! With Nuclear Weapons the stakes really ARE that high!
>>     >
>>     > Our problem is very similar although not with such dramatic
>>    consequences.
>>     >
>>     > Karen
>>     >
>>     > On Tue, Aug 31, 2010 at 1:17 AM, Ai Austin
>>    <ai.ai.austin at gmail.com <mailto:ai.ai.austin at gmail.com>> wrote:
>>     >
>>     >> myticaldemina makes a lot of good points... one thing that could be
>>     >> problematic though relates to this comment...
>>     >>
>>     >>  From: <mysticaldemina at xrgrid.com
>>    <mailto:mysticaldemina at xrgrid.com>>
>>
>>     >>> ...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 agree with the first half... no chains, just hand over the
>>    external
>>     >> system "authority" and its given identifier pair for the
>>    identity involved.
>>     >>
>>     >> But I don't agree at all with the idea that you then have to get
>>    the asset
>>     >> from that original authority.  The permissions could have changed,
>>     >> corruptions could have occurred or much more likely the
>>    authority simply
>>     >> will no longer be there.  The asset "as is" (with its textures,
>>    scripted
>>     >> content and what not) should be provided to the destination
>>    location/grid if
>>     >> the object permissions allow it, with proper transfer of the
>>    permissions to
>>     >> next owner exactly as if an avatar to avatar transfer or rez in
>>    world took
>>     >> place on the local grid, without trying to reload the asset from
>>    an original
>>     >> source.
>>     >>
>>     >> .
>>     >>
>>     >>
>>     >> _______________________________________________
>>     >> 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 <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 <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
>>
> _______________________________________________
> 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/20100831/5b65a456/attachment-0001.html>

More information about the Opensim-dev mailing list