Concerning the sneakernet issue: The routing seems to be a problem. How does the sneakernet method exert preference over which node it communicates with? That would have to be dealt with, or shown to be irrelevant.
Also, there's a speed issue, for routing. Routing is based on human networks. The flow of information through sneakernet will be based on channels that shift so slowly (two friends or co-workers who swap CDs over the years, or swapping CDs with the folks at the elk lodge) that they are effectively concrete, compared to the routing-optimization that occurs over TCP/IP. The routing as it currently stands (direct communication via TCP/IP) garners such adjectives as "on-the-fly" or "wild". TCP/IP based routing finds the information it wants in a quicker, more efficient way than sneakernet routing would. TCP/IP based routing, however, is designed to minimize the flow of keys. It's designed so that when a node requests a key, it's likely to find it close by. Key flow is minimized, datastore churn is minimized, and the routing tends to stagnate some. However, the number of keys that move through a node that communicates via sneakernet will be large. If the node is looking for a key, it's going to have a vast choice of keys to dig through. Also, with the slowness of sneakernet-based freenet, keys would stick around longer. Say "KSK at text/philosophy/billofrights". Quite a static document, and not very popularly requested, but very important to keep around. In a slower-moving freenet it would be easier to keep it around. Each network excels where the other leaves off, and falls short where the other excels. More importantly, the two networks are complementary in some ways, and can certainly co-exist peacefully. If a datastore has the high churn of sneakernet and consequently de-specializes, then the quick-as-a-bunny TCP/IP routing of other nodes will route around the sneakernetted node due to never finding what it wants there. But, to the extent that a node is used for TCP/IP communication, the flow of keys through it will specialize the node again. And sneakernet is not the end of the issue. We can imagine 'sneakernet' to be simply a metaphor for the Great Unknown. Key flow could take place via physical media, via email attachments, via file sharing networks, via radio signals (interplanetary freenet anyone?), and even teletype, if you wanted. Key flow could happen over any number of networks in addition to the direct TCP/IP variety. For that matter, it could happen over TCP/IP in various states of performance. This seems to me to be an obvious benefit. NAT and some firewalls are already causing stoppages in freenet communication. What will the Chinese government do when they realize that freenet exists and what it is? What will the Department of Homeland Security do? What could alternate channels of communication do to combat that? Freenet should not grow incestuous with TCP/IP. The freenet node would be most helpful, and go furthest toward the stated philosophical goals of this project, if it worked *wherever* it was needed or wanted. Routing should be viewed as an entity independent of the medium of communication. The terms that frame the discussion of routing should be implementation-agnostic. Routing, if implemented properly, could work over a network with any degree of latency or any amount of datastore churn or any method of communication. Routing, along with encryption, is the central concept that constitutes freenet. Implementation of the routing algorithm in differing mediums, with differing performance characteristics, should be always possible in theory. Leave the 'in practice' part up to any who wish to try it. Can the freenet software be made to handle sneakernet? That's an issue I'd like to see the sneakernet proponents tackle. -Todd _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
