[ogpx] Unique identities (was: Names, Identity and Protocol elements)

Carlo Wood <carlo@alinoe.com> Sat, 20 March 2010 13:39 UTC

Return-Path: <carlo@alinoe.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5763D3A67AC; Sat, 20 Mar 2010 06:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.554
X-Spam-Level: *
X-Spam-Status: No, score=1.554 tagged_above=-999 required=5 tests=[AWL=-2.745, BAYES_80=2, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzYHKFrYYUjr; Sat, 20 Mar 2010 06:39:05 -0700 (PDT)
Received: from viefep12-int.chello.at (viefep12-int.chello.at [62.179.121.32]) by core3.amsl.com (Postfix) with ESMTP id 361C93A68A6; Sat, 20 Mar 2010 06:39:01 -0700 (PDT)
Received: from edge04.upcmail.net ([192.168.13.239]) by viefep12-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100320133913.JSGK19831.viefep12-int.chello.at@edge04.upcmail.net>; Sat, 20 Mar 2010 14:39:13 +0100
Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upcmail.net with edge id vRfB1d03F0FlQed04RfCSi; Sat, 20 Mar 2010 14:39:13 +0100
X-SourceIP: 77.250.43.12
Received: from carlo by mail9.alinoe.com with local (Exim 4.71) (envelope-from <carlo@alinoe.com>) id 1NsytT-0002nk-Cb; Sat, 20 Mar 2010 14:39:11 +0100
Date: Sat, 20 Mar 2010 14:39:11 +0100
From: Carlo Wood <carlo@alinoe.com>
To: David W Levine <dwl@us.ibm.com>
Message-ID: <20100320133911.GA9372@alinoe.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Cloudmark-Analysis: v=1.1 cv=SLkC287PFWo6d7eSEiSBB9255DBOWQ3bwOwHXJiyZoo= c=1 sm=0 a=3C0hmxYfFdwA:10 a=38zWk6xDZSoA:10 a=kj9zAlcOel0A:10 a=BjFOTwK7AAAA:8 a=2-kulcq-TMKT9jPrEMQA:9 a=Ug4_iTzse-yzVqmjvMMA:7 a=kNSUo7IYsqSSnm-dkX1zkx9UfbYA:4 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=JWQ9GxDHpgOJv84n:21 a=vDiJDGo_kDNv2yPk:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
Cc: ogpx-bounces@ietf.org, ogpx@ietf.org
Subject: [ogpx] Unique identities (was: Names, Identity and Protocol elements)
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Mar 2010 13:39:07 -0000

Uniqueness in general
---------------------

The generation of unique IDs is quite interesting by itself.
And quite a few unique IDs are needed in a good VWRAP protocol. 
The approach taken by LL is generating number so huge that
they are unique by chance. This has two disadvantages: it
increases bandwidth usage and it requires to look up those
ID's in huge trees, because these ID's cannot contain information
in itself. Finally, it is not always possible to have untrusted
parties (ie, the viewer) generate UUID's, because they can
be set to anything and therefore deliberately still match
another already existing UUID.

Another approach to generate unique ID's is to devide Unique
ID's over "Authorities" that can generate such ID's (these
would be servers). Each Authority would need a unique ID
by itself, and can then generate an arbitrary number of other
unique ID's by appending a locally unique number to it's
own ID. Likewise, the authorities ID could exist of an ID
unique for the administration running the server plus a
number unique within that administration and assigned by
that administration. This is, for example, the approach
that hardware vendors are using to identify hardware being
plugged into a PC. The ID itself contains a part that shows
one that the chip is made by nvidia (for example).
The advantage of that is, apart from that the ID's can be
much smaller, that each ID immediately contains a part
that reveals who is the authority, which then can be used
for routing the message to that authority, etc.

Authorities are very important concept as well. In order
to avoid collisions (making incompatible changes to the same
thing in different places on the network, after which
re-synchronization becomes a nightmare), it is necessary
to route all messages regarding 'X', to a single authority,
the authority of X. Changing 'X' then exists of requests to
change it, and the authority will inform the requester if
this succeeded or not. For example, if on a given grid
someone creates a new chat group, then the viewer sends
a request to the authority of that chat group name (which
can be distributed by using the first character(s) of
the name to assign it's authority). That way, if two
people try to create the same group at the same time,
only one will succeed.

Another reason that makes using authority-generated ID's
an advantage is that they are robust: it makes it impossible
to have a viewer generate an ID (see security problem above)
by accident; and it certainly makes it impossible to use
ID's in the protocol that also have the function of being
human readable! A mistake made many times in the current
protocol of SL: avatar names, region names, group names,
... all of them are not only the human readable texts that
we want to see, they are ALSO the ID's of themselves by
which they are recognized in the protocol :(. As a result,
it is impossible to change them. Human readable text should
be nothing more than meta data. Hell, you could even give
a region more than one name, depending on the language
of the one visiting it. All protocol should use authority-
generated ID's, which by nature cannot be human readable.
The server would include human readable meta data for each
ID that represents something in-world, and the viewer would
do ID <--> human readable name mapping back and forwards
locally. Changing the name of something would be as easy
as sending a request to the ID authority to change the
name (resulting in a message with the new meta data to
everyone using it, without the slightest risk of a desync
during that update. You could even just wait till the
next login before providing the new meta data).

-- 
Carlo Wood <carlo@alinoe.com>