Naming service for the Invisible Internet Protocol

jrandom,

Thank you for explaining the way destinations communicate, and for correcting me. I still think a naming service will be valuable, but should be modified. It would allow for searching an entity's attributes as well as lookup. Since, as you pointed out, an entity could have more than one service running, with several destinations, the entity's record will now be:

1. Entity's name.
2. Public key for modifying this record. Updates to the record will have to be signed with the corresponding private key, and will not be made unless the signature is correct.
3. Personal information (blank if the entity does not wish to enter personal information).
4. List of services:
a) service 1 (for example, IM)
b) destination for service 1 (contact information)
c) service 2 (for example, a website)
d) destination for service 2 (contact information)
e) etc.

The entity would be responsible for updating the record if it changes. Other entities could search for whether that entity's entry exists, what services it provides, whether it provides a particular service (IRC, for example), etc.

As for who would maintain the name servers, I suggest that it should not be a single entity. The naming service should be available from multiple destinations, so a peer-to-peer network of name servers should provide the service. Then users of the I2P network could specify trusted name servers, as you suggest. The name servers would periodically synchronize information they have, and propagate updates.

I hope this answers your questions. If you have more, please post them to this list.

-----Original Message-----
From: <auto97841-revL73yDgGBWk0Htik3J/[email protected]>
To: <[email protected]>
Date: Sun,  3 Aug 2003 12:31:55 -0700
Subject: [iip-dev] Naming service for the Invisible Internet Protocol


Cool idea, and even though the key functionality you describe is built
into the spec, there is plenty of room for add on directory services.

> the first destination will have to know the second's IP address or
hash to communicate.

Not true - if I have your Destination, that means I have your public
key.  I then tell my router to send a message {"hello co"} to that destination.
 The router then says "hmm, I don't know where that destination is -
let me find out".  It does a lookup in the distributed hash table, keyed
by H(destination), to come back with a set of Lease objects.  These Lease
objects themselves do not have any physical contact addresses [e.g. ip
address], but they do say at what router messages bound for a destination
should be sent. ...

That said, your idea is still a good one.  Having a directory service
on top of I2P would be quite useful, allowing people to register nyms
(CA signed), manage/revoke Destinations associated with those nyms, as
well as what application runs on each of those destinations (remember,
 a destination goes to one endpoint - my IM app may have a different
destination from my web server app which may have a different destination
from my web browser app).  In addition, allowing people to publish general
profile information would be just plain cool, enabling community building.
 You'd allow searching with this too, right?  Or just plain lookup by
destination or nym?

Yes, having the ability to say i2p://jrandom:www/ or i2p://co:im/ would
be, well, wikked.

How would you suggest the naming system work - a central CA, plus a central
repository of all entries?  or a central CA plus a caching DHT of the
entries?  or a superpeer style network of entries with search for application/nym/destination/profile
attributes?  Or perhaps a peer to peer CA system, letting people specify
what CAs they want to trust to 'resolve' destinations?

Anyway, definitely cool
-jrandom