This note is about names for nodes including, of course, service providers. We have proposed that the public key of a node is secure; If the legitimate designee has kept his private key secret only he can decrypt messages encrypted to his ‘name’. It is highly conceivable that the number of things to be thus named is too large for most or many guides and the name of a guide who does recognize the designee’s name might be included. When space is dear the hash of the public key can be used. Guides are likely to know each other and have reciprocal arrangements.

If you have only the hash of the public key of a service provider that you would like to contact, your friendly guide may well send the provider a message which requests the provider to send you a packet with her full public key and that packet will have a return path suitable for beginning an encrypted dialog with the server. If you have a secure connection to your guide, then he is in a position to include your public key so that the server can encrypt her first message to you.

Even if the guide does not have your public key you are in a position to verify the public key of the server that she sent to you in the clear whereupon you can encrypt a request to the server encrypted under her public key.

Public keys, even fingerprints, are awkward to remember and quote. This scheme helps a little.

Reputations

An app on the machine of a typical user might accumulate reputations indexed by public key hash. When you hear of a plumber you might see who has recommended him. Networking this with friends would help here.