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.  Now, if my router doesn't know anything about *those*
routers, it then does another distributed hash table lookup for H(routerPublicKey).
 The result is a RouterInfo structure, and *that* contains a set of RouterAddress
structures - each of which represents a single method of contacting the
router (protocol for communication, hostname, port number, url, email
address, whatever).  [this description isn't exactly correct, as it doesn't
represent trusted links or Lease/RouterAddress revocations during delivery]

My router caches what it feels it can and should so this process isn't
repeated (often) for further messages to the same destination.  However,
 this means applications don't need to know anything about *how* to send
messages to each other.  In fact, applications *cant* know [as if they
could, they'd be able to harvest or track]

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



Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427