*If* I2P's low-level crypto, and reliable messaging over UDP layers can be modularised, then we should use them below our messaging layer (the waitFor() stuff and message serialisation etc). Ditto for I2P's data transport code.
After a long conversation with Matthew, it is far from clear that adapting I2P's mixnet code for our needs would be less work than doing it from scratch, and given my general experience with merging high-level functionality in that way, my strong suspicion is that it would be a world of pain. That being said, if, when we get around to implementing mixnet functionality, we should of-course look at I2P to see if there is anything we can conveniently reuse, just as we should look to other projects. Ian. On 15 Oct 2005, at 13:27, Matthew Toseland wrote: > There has been a major debate recently, which has now rather > degenerated, over whether i2p and freenet can do any business > together. > I would like to provide a technical perspective. > > Messaging: > Ian is concerned that we would have to ditch our messaging layer if we > wanted to use I2P. This is not actually true. Freenet can sit at the > client layer, and I2P will provide it with reliable out of order > delivery of byte[] packets over zero hop tunnels (i.e. direct > connections). We can easily run our Message formatting system, and our > waitFor() system, on top. I2P can also provide congestion controlled, > zero overhead, block transfers through its streaming API. It would > provide us with the lower layers - retransmission, authenticated > Diffie-Hellman negotiation, etc - and allow us to concentrate on the > higher levels, reducing maintenance. > > Premix routing on opennet: > Furthermore, it would provide us with essentially free premix > routing on > the open network. This is based on an any-to-any model, but it is > believed that tunnel creation is not particularly vulnerable to > traffic > analysis: > http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel- > alt.html?rev=HEAD > (obviously I would want to read this!) > > Harvesting and darknets: > On the opennet, it is irrelevant that I2P is harvestable. So is > freenet/open. I2P has had planned functionality called "restricted > routes" for some time. This would be used on the darknet. This means > that the nodes do not register themselves in the netDb, except > possibly > through a tunnel to a node which did. Jrandom estimates that > restricted > routes would take "1 week to implement, 8 weeks to test". The thing > is, > I2P doesn't have a routing algorithm for darknets; it is therefore > limited to very small ones which are a fork off the main network. > HOWEVER, if we provide one as a plugin (some darknets may not be small > world), then we can work together for mutual benefit; large small > world > darknets can be used with i2p, and traffic need not go over the border > to the open network if there is no benefit to it doing so. Darknets > without an open network would also be possible. > > Premix routing on a darknet: > We also get significant assistance with premix routing on a darknet. > Jrandom, and i2p, have a lot of experience and expertise in > mixnets, and > we have very little. It is to our mutual benefit to together come up > with an algorithm which actually works. We have discussed various > cellular options, and it looks promising. > > In conclusion, IMHO there is a lot that I2P and Freenet can do > together, > for mutual benefit. The result would be reduced overall code size, > reduced maintenance, reduced redundancy, a lot of free stuff which > would > otherwise have had to be written for 0.7, increased anonymity > because of > a larger network, I2P gets a distributed data store and the ability to > work on large, small-world darknets which may not be connected to the > open network, and we get free premix routing on opennet, and a lot > of help > on darknet premix routing. > -- > Matthew J Toseland - toad at amphibian.dyndns.org > Freenet Project Official Codemonkey - http://freenetproject.org/ > ICTHUS - Nothing is impossible. Our Boss says so. >
