-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Well, my stock answer is that I2P is harvestable, and this is the > fundamental problem that we seek to rectify.
Hrm, but for the reason's we've discussed over this epic thread, your stock answer is not correct. I2P's restricted route topology isn't something new, its been on the roadmap as I2P 2.0 for the past 2 years. You need a new stock answer ;) > > Some may choose to connect with only trusted peers in A, while > > other peers in B may choose to connect with a wider selection of > > peers in A. That is, in addition to connecting with peers in B > > or C (for those peers in C which it has a trust relationship with). > > But since we source route, they must publish this information if they > choose to only connect to a few trusted peers, correct? Peers in B which need to be reachable by peers they do not have connections with need to publish their routerInfo, which has either their direct contact information (IP, port, etc) or their indirect contact information (tunnel gateways they can be reached through). For trusted scenarios, the routerInfo could be sent to a peer without publishing it in the overall netDb, but that peer would then technically be able to republish it again to the overall netDb (though doing so would likely violate their trust relationship) > > > - A node in B will only connect to a node in A which it has a trust > > > relationship with. > > > > Not necessarily. Its up to B to decide. Depends upon the threat model > > of B and the peers in C which it is helping. Not all peers in B have > > to be controlled by the same organization. > > Or any organization-as-such. So B's can directly connect to A's, or they > can connect only to trusted A's, and then have the trusted A's be the > first hop on an onion chain to wherever they want to go. Right. > On the whole, a node in B will not know many nodes in B, but will often > be able to contact all A's; I'm not sure why you say that. If B1 is a peer who only uses trusted connections to peers in A, then there's no reason to assume the peers in B it contacts are fewer than the peers in A it contacts. > even if it can't it will usually go through A even to contact C2, > because it is possible to route through A, correct? Depends upon performance - the tunnels are rebuilt based on what works best. There's code to allow the user to explicitly specify what peers they want to use in their tunnels too, but I don't tell people about that, as its hard to use and has anonymity issues, but may be useful for trusted links. > > > - If so, this would mean that all nodes inside the Wall must > > > be directly connected to nodes outside the Wall. > > > > Peers in B may be within the Wall, with peers in C contacting them. > > No they can't. Remember that all nodes in A are blocked by the Wall. > We could split B up into B1 and B2, and have B1 behind the Wall, > and B2 in the Free World. In which case B1 would have to either: > a) Publish its connections to B2 to C or > b) Transparently relay through B2 to A Exactly - option 'b'. When C1 tells B1 to send a message to A1, B1 has the liberty to do so however it feels is necessary. If B1 cannot talk to A1 directly, it will use its tunnels through B2 (etc) to do so. As mentioned before, however, B1 could optimize C1 a bit by giving it profiles ranking B2 up further (acheiving your option 'a'), but doing so is not necessary. > So most of the time, any contact between C1 and C2 will go through > A. Yes? Whatever the profiles say. If the tunnels through A are incredibly lossy or congested, tunnels not using A would be used. > If C1 wants to talk to C2 without going through A, the only way > to do this would be for all the B's to publish their connections > (stripped of IP addresses) to all C's directly or indirectly connected > to them. This does not scale, but might still work for plausible scales. > Is this the idea here? No, see above. > > > - If a node in C wants to talk to another node in C, it will probably > > > have to go through not only B, but also A. Correct? > > > > Not necessarily, but probably. > > 99% sure, from what I've seen. Unless the first B has a connection to > C2, it's very unlikely that it won't go through A. Depends on the profiles (as above). > Well... how does the network grow within the Wall then? New C's > have to be introduced to existing B's... Wetware, or whatever human trust networks exist. > Your topology is highly parasitic. Most data will have to go > through A, meaning that most data will have to go across the > firewall. Depends on the profiles. But its true that the peers in C aren't likely to contribute much in terms of bandwidth or CPU power to peers in A, but peers in B think their contribution in terms of content and liberty is more valuable. Peers in C wouldn't do filesharing, they'd do email, some browsing, and some content publication (syndie). If they needed to push some bulk data (1GB+), they could technically do so, but it might be worth talking to the trusted person to see if another means of transport could be arranged (sneakernet, etc). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDT6ZsWYfZ3rPnHH0RAg5xAJ4sGiNHHmjY2Op3i1Km3oUHqVsJRQCfZMbF cIPivB9e5oiNiiAInJwr1nE= =7+yI -----END PGP SIGNATURE-----
