-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > This doesn't make sense - its like saying Tor can provide high latency > > comm if it turns into mixminon. Yes, if you build a different system > > with different characteristics 2 years down the road, that different > > system will be different. > > Same routing. Many of the same functions. We can still have requests, > inserts, and streams. I don't see the problem.
Streams, over high latency comm? Bidirectional FNP? What batching and mixing strategies will carry over into the high latency Freenet? > > What part of the above couldn't apply to I2P? > > All of it. I2P is harvestable. Any bored technician can block it. Hablas ingles? [1] or if you want more details, another link I posted earlier in this thread [2] [1] http://dev.i2p.net/pipermail/i2p/2005-October/000975.html [2] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/ techintro.html?rev=HEAD#future.restricted > How exactly is I2P going to route within a large restricted-routes > network? My understanding is that it's simply a system of proxies with > largely fixed routes. If they're not fixed, they'll be random, and > harvestable. If they are fixed, they won't provide much useful internal > functionality. Right? I2P will work as described in [2] above. Peers in the 'A' group will have a number of connections to trusted peers in the 'B' group, who in turn will have a number of connections to peers in the 'C' group. Peers in 'A' will still build its tunnels like every other router on the network, ranking them by their locally derived profile, but the first hop on their outbound tunnels will always be a peer in the 'B' group to which they are connected. How do peers in the 'A' group find out about peers in the 'B' group? Through existing trust relationships. 'B' would be peers run by groups like rsf who already have trust networks with people on the ground, or by western friends of people in the 'A' group who want to help out. > As far as I can see your restricted routes system will be a matter of > putting as many users behind one proxy as possible. Which in practice > will be very few. No, you're assuming |B| = 1. That would not be very fault tolerant. > And there is *no internal routing*. You only need exploratory routing if you don't know where you're going. I2P doesn't have that problem - it just passes a message to a tunnel gateway. > You have on many occasions explained that restricted routes is simply > a kludge to get around firewalls etc and it does not route That is [3], not [4]. [3] http://www.i2p.net/todo#nat [4] http://www.i2p.net/roadmap#2.0 > > Though at the scale such a network would run at, the anonet thing > > would probably work fine. > > The what? An OSPF VPN - http://anonet.fshell.org/ > Stego transports of the second type are also possible. You can for > example use irregular VOIP connections. Either you piggyback on real > VOIP connections at a lower quality level, or you have it randomly > connect in a plausible pattern. Since most people only talk to their > friends most of the time, any detection that did not do more-than-local > traffic flow analysis would produce many false positives. I'd love to hear some details of how you could automate such plausible activity in an open source project without giving an adversary a map to detect it. > And you haven't explained why freenet over sneakernet + wifi wouldn't be > useful, either. The postal system is great, and I'm sure some people are using it right now to transfer data anonymously. I'm not sure how Freenet fits into that picture though - with 1-5 day latency per hop, what sort of use case are we talking about here? > But what I really want to know is how I2P is going to do what Freenet > 0.7/Dark will do - you seem to be saying above that it will provide a > scalable darknet. Really? How? Thats exactly what I'm /not/ saying. As we've discussed, I2P and Freenet/dark offer the same level of obscurity. The difference is that I'm not calling it a scalable darknet, because it isn't. =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDTpkeWYfZ3rPnHH0RAisfAJwIlGrds/xnsvO5WtG5s2VO4r/ToACfTLuO F6RzQxTcNLtjJgZ5k46SpUM= =8SmC -----END PGP SIGNATURE-----
