> Ian is of the view that this should be a separate application based on similar > principles to Freenet. I'm not. We agree that there are some significant > issues to deal with. I am of the view that these networks are mutually > complementary and therefore should talk to each other
I think the use-cases are too different for these to be part of the same application. I see a simple scenario where a "sneakernet" would be useful is in a situation like Burma or Tibet where stuff is happening, possibly a political crack-down, and the authorities are actively trying to prevent information from getting out. In this case, the role of the sneaker net would be to allow the covert transmission of information, probably large files like video and images, out of a hostile area and onto the Internet. The optimal strategy here is probably a simple one of spreading information as quickly as possible to as many "sneaker nodes" as possible whenever they come in contact, to maximize the likelihood that one of those will be able to connect to the Internet. I don't think this would require any sophisticated routing, its just a broadcast with an intelligent replacement strategy for older content (probably LRU). This might be combined with encryption and or steganography to protect the sneakers should they be inspected. The ideal hardware platform for this would be a small device with wifi and a lot of storage. The obvious example that springs to mind is an iPhone or iTouch, the iPhone being better as it has a camera, and it can transmit what it has as soon as it reaches a friendly cell phone network. >From there we could get more ambitious, trying to support bi-directional communication - but even here I think a key is to replicate the transmitted content as far as possible, because it probably won't be easy to predict which sneaker nodes will have opportunities to communicate with each-other and when. Spreading it far and wide maximizes the likelihood of successful transmission. It only starts to make sense to route, ie to limit which nodes will replicate data, if the size of the network is sufficient that global replication won't scale. When the data reaches its destination, another small response message can be sent which indicates receipt and causes nodes that receive it to delete the original data to make room for new data. With all of this, I just don't see why it would be any practical advantage to bundle this functionality with Freenet: 1. The platform for this type of thing is a small mobile device, getting Freenet to work well on an iPhone would be a world of pain - and doesn't buy anything for us 2. Most or all Freenet apps assume a few seconds latency on requests (Frost, Fproxy, etc), yet the latency with the sneakernet would be measured in days. Freenet's existing apps would be useless here. So, tying this to Freenet would be a world of pain, without bringing additional benefits. I know that some freenetters just love bundling everything under the sun with Freenet, but in this case it really doesn't make sense. Sneakernet is a great idea, and we probably have exactly the expertise needed to build it, but it doesn't follow that it should be part of the udp-based Freenet. Ian. -- Email: ian at uprizer.com Cell: +1 512 422 3588 Skype: sanity
