On Thu, Oct 13, 2005 at 07:30:53PM -0400, jrandom at i2p.net wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > It would probably be lower than that on average, but certainly some hops > > would be a week latency. Probably most requests would have 6 hops at > > most for success... more with premix. > > When you've got latency like that, you really want to optimize the > throughput - for instance, replicate entire data stores, rather than > waiting a week to fetch the key, only to find a dozen other keys in the > metadata and having to wait another week to ask for those.
That's called "streams". :) Some sort of trusted, prenegotiated push system. But I maintain that request/insert would still be useful for many things. > > Such a high latency system is really, really useful, but it'll look > very, very different from today's Freenet or I2P. At least, from my > understanding. It could still use routing. I don't think a system which relied solely on global broadcasts would be as useful as one which could do things you can do with routing - selective broadcasts, request/retrieve, etc. > > > The point is that the dark-freenet architecture has a future. > > Whatever you build will have a future - you're a good coder, and > while there are some technical issues I disagree with you about, > as long as you're working on it, you'll be able to keep it alive. > > This thread however, was about redundancy - whether Freenet was > moving towards reinventing something that can already be done with > existing tools, or could be done cheaper by extending systems. > > Redundancy makes sense if there is a fundamental problem with the > alternatives, or if there's a new idea that'll work better for > people. Well, my stock answer is that I2P is harvestable, and this is the fundamental problem that we seek to rectify. I certainly wouldn't muscle in on your territory without a good reason, but I believe I have one. Now, certainly it is worth discussing the details of I2P's alternative restricted-routes topology, which is why I have spent some time doing so; I would be interested to get that sorted out. > Your time is scarce, and as we're all on the same side, > its reasonable for people to want to make the most out of your > contributions. Doesn't mean you have to agree with their > conclusions, but reasonable to expect people to ask why. Agreed. > > > So some peers in A have a trust relationship with peers in B? > > Thats up to peers in B. 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? > > > You haven't answered the point, anyway - client nodes are supposed to be > > able to contact anyone, right? > > All routers (in A, B, or C) can contact anyone, but not all routers > can contact each other directly, and a router needs to know another > one's public keys to reach it. > > > > Ok, so you now agree that Freenet/dark and I2P with restricted routes > > > both offer the same amount of 'dark'ness as long as there is a West? > > > > Well... > > > > Some things we need to get straight in order to make a proper > > evaluation: > > - A node in C will only connect to a node in B which it has a trust > > relationship with. > > Right. Or, in theory, they could connect to another trusted node in > C, but that blurs the line between B and C. Lets just call peers that > C trusts and contact B, for simplicity. > > > - 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. > > > - All chains from C start C, B. The second hop, outgoing, is always in > > B. No? > > The first hop from C reaches a peer in B. The second hop may reach a > peer in A, B, or C. How B delivers that message to the next hop may > vary. Practically, C will get better performance out of peers that B > can contact directly, and hence, rank their profiles better than peers > they must reach indirectly. > > Now, if you want to look at a wacky situation, if peers C1 and C2 are > connected to the peer B1, its not implausible for C1 to profile C2 as > a "fast and high capacity" peer, but its not likely, since to do so, > C2 or B1 would have to had given C1 the routerInfo (public keys) to > C2 (which doesn't necessarily have C2's direct contact information). > > But thats kind of goofy, so for the most part, you can just say that > the second hop from B1 will be to another peer in either B or A that > B1 has a connection with, since that'll get profiled as being the > 'best' path by C. On the whole, a node in B will not know many nodes in B, but will often be able to contact all A's; even if it can't it will usually go through A even to contact C2, because it is possible to route through A, correct? > > (how does C1 know which peers B1 is connected with? it doesn't! At > least not necessarily - C1 will start up with some pretty bad > profiles, and pick some slow peers at first, but the iterated hill > climbing of I2P's peer selection should improve that over time. Or > B1 could cheat by giving C1 some profile data to start off with, since > they're trusted) Okay. > > > - 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 Also we can't do any real routing until we get to A. So most of the time, any contact between C1 and C2 will go through A. Yes? > > > - Both traffic analysis and traffic sanctions (as opposed to arresting > > people) are *much* *much* easier on the border. > > Unsure. Insufficient data for me to answer. It's true in real life, it's true in cyberspace. It's just more cost-effective to surveil the border. Hence the Great Firewall. It's external, not internal. > > > Freenet/dark could have a substantial internal darknet; this is not > > possible with I2P, correct? > > Peers in B and C may contact each other, build tunnels through each > other, without crossing the Wall. I'm not sure if this answers the > question, but "substantial" is a bit fuzzy. This assertion is equally fuzzy. You can only freely route once you reach A. 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? > > > - 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. > > > If B is a scarce resource relative to C, it has a *serious* impact > > on performance, and therefore on usability. > > Peers in B and C would have a trusted relationship, which makes me > question whether they'd have the scarcity issues found on an open > network, as they know the impact and value of that scarcity. The > likelyhood of running I2Phex instead of susimail or Syndie is > probably low. Peers in B also know which peers in C exceed > reasonable usage too, and could take corrective measures (aka talk > to them, remove the spyware from their computer, etc). Well... how does the network grow within the Wall then? New C's have to be introduced to existing B's... > > > It also has a significant impact on security, in that EVERYTHING has > > to go over the border at least once. > > Not necessarily, but it'll do so if the performance measurements > suggest it. I would suggest that the performance will be severely constrained by everything having to go over the border. Please explain how it would not go over the border? Aren't we source routing? Is the idea to randomly set up tunnels, and then use them instead of direct contacts? > There are further tweaks we can do (e.g. offering > different tunnels to other peers in C that do not cross the border), > but thats beyond the horizon of reasoning about (I'm a pretty good > coder, but I'm not that fast ;) > > > Are my assumptions above, and my analysis, reasonable? > > Reasonable, though there are the clarifications above. Well, can you see my concerns then? Your topology is highly parasitic. Most data will have to go through A, meaning that most data will have to go across the firewall. -- 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/20051014/3b3f2769/attachment.pgp>
