On Sat, Oct 15, 2005 at 04:25:56PM +0100, Matthew Toseland wrote: > Okay, lets try to flesh this out a bit: > > 1. I2P can provide SSU as a library. We can use this for our transport. > This can be maintained by I2P, which is a benefit to us. It has packet > retransmission, authenticated DH etc. It will require very minor changes > to support darknet operation slightly more cleanly. We can use I2P > transports. It can feed us packets which we can parse much the same as > we do now. > > 2. Freenet is an I2P client. It uses the streaming library for bulk data > transfer. On opennet, it uses I2P for premix routing. On darknet, the > I2P node is essentially disabled; no DHT. Freenet tells I2P about peers > it wants to connect to. On a hybrid node, we have the DHT. > > 3. Freenet implements a DarknetProvider interface for I2P, for > small-world darknets. This provides a routing algorithm, and a node > selection algorithm. I2P has full restricted routes. It can use Freenet > provided APIs to route between nodes in the darknet, and it will ask > Freenet to choose nodes for mixnet tunnels. On a hybrid network, I2P > will consider both freenet routing within the darknet, and routing out > to the opennet.
At this point we have to deal with issues of fragmentation. Actually I rather think we need to deal with them anyway. It seems inevitable that we will have various network topologies, which may cause problems: - One big darknet, which is small-world - A darknet with a large number of links to a lightnet - A darknet with a small number of links to a lightnet - Two darknets, with few connections between them This is probably why I was uneasy about hybrid light/dark networks... The I2P aspect of this is "how do we get to the opennet, if any". > > Obviously we would want well-defined interfaces at each point: > 1 - freenet uses the SSU library > 2 - freenet uses the I2P client interface > 3 - I2P provides a plugin interface for darknets; freenet implements it > and provides it to I2P. It also uses the I2P client interface. > > On Sat, Oct 15, 2005 at 03:55:02PM +0100, Ian Clarke wrote: > > *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. > > > > > > > _______________________________________________ > > Tech mailing list > > Tech at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > -- > Matthew J Toseland - toad at amphibian.dyndns.org > Freenet Project Official Codemonkey - http://freenetproject.org/ > ICTHUS - Nothing is impossible. Our Boss says so. > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech -- 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/tech/attachments/20051015/bf02e57b/attachment.pgp>
