Freenet should register itself as a handler for two extensions/mime types. Type 1: Freenet reference, .fnr. Simply a freenet reference.
Type 2: Freenet invite, .fni. Freenet reference plus a cryptographic token that allows the node to connect, and send its own reference back. May also include a few temporary port numbers for the node receiving the invite to send from, in order to get past any NATs. The node which created the invite already knows the IP address of the computer the invite is being sent to, so it will send packets to try to punch on those port numbers on that address. If it receives a response (from any port/IP), with the right cryptographic token, then it will complete - it will accept the reference of the new node. We may require some sort of out-of-band verification. One option is to verify the pubkey fingerprints in both directions out of band (phone, floppy, printed, etc). Another is to password the process: Alice sends an invite to Bob and decides on a password. Bob installs freenet and gets connected to Alice. Alice tells Bob the password out of band (e.g. telephone, or in person the next day, or through the mail, or whatever), Bob types it in, and Alice and Bob do a challenge/response protocol. This may go both ways if Bob also creates a password and tells Alice it. Comments? -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060701/fd3aa0ee/attachment.pgp>
