[Opensim-dev] Global identifiers
Melanie
melanie at t-data.com
Tue Aug 31 19:49:39 UTC 2010
The concept is that OBJECTS require no authority. They exist apart
from it, which is why their data needs to be self-contained. Objects
are reflected as point-in-time of their creation.
The further uses are for communication, e.g. contacting a creator.
This may succeed or fail. I believe a grid should not look up
anything just to render an object, or provide object properties.
Melanie
Karen Palen wrote:
> 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
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
More information about the Opensim-dev
mailing list