> The main problem with sneakernet is it's enormous latency. I would > suggest that sneakernet is better suited to bulk prefetch than a > pseudo-end-to-end protocol like Freenet is (NASA came to the same > conclusion when architecting the interplanetary internet - TCP is not > suitable if latencies are in the tens of minutes, you want an offline > bulk transfer protocol). So what you want is a client that lets you > browse a cached part of freenet, and build a query list. Then when you > go to the node with a connection to the real freenet, you have it try to > fetch all the keys you have flagged that you want, and those that it > does find, you return to the broken-off freenet. There is probably > offline-browser type software that does this for the WWW, you could > probably adapt something for freenet. It cannot participate in routing > however, because latency of minutes per hop is not reasonable, and IRL > it would probably be a lot more than minutes per hop on average.
The latency is definitly enormous - saying that it would be minutes is well beyond reason. The actualy latency would be on the order of hours at the minimum and days to weeks or even months at the top end. Routing obviously will not work with such delays but thats ok - I never intended for routing to be a part. I was thinking of a system that worked more on randomness. Something along the lines of taking 180 megabytes (or what ever the media size was) worth of keys from the datastore, at random, and putting them on the media. When you give the media to someone else, they import the keys (also possibly randomly if it does not make sense to import the entire cd). This would mix things up and give a person running a node even more plausable denibility that they did not request the content they are hosting - this might even work in the case of a transient node, if they participate in sneaker net their node will be full of all kinds of stuff they never requested. This is where the garbage collection of a fragile media comes into play - if the cds lasted for ever they would keep pushing new content out of the node. But if cds die off at some interval, that would be limited. People could also look at the dates of the files on the cd and skip anything that was older then what they wanted. The way I see it, this adds more randomness to the network as it now has an aspect that depends more on human behavior. > > With respect to running freenet in hostile environments, that is a > post-2.0 thing IMHO, but potentially interesting (potentially impossible > too, but "experts" have told me that about freenet :)). We would need to > find a way to implement a freenet-like network that could function with > only being able to use trusted links, and we would use steganography to > hide those links over the public internet, or we could use covert > physical links. > > > > Allowing freenet to use sneakernet would be wonderfull for a variety > > of > > reasons.... The act of allowing freenet nodes to communicate with each > > other off the internet is highly deseriable. At this time, assuming > > freenet encryption could be broken and trafic analysis became > > possible, > > freenet activity could be tracked and people could be located. > > Analysis > > of sneakernet would be impossible unless people were stoped with the > > media. Of course that is a paranoid example, but freenet is a paranoid > > system ;) > > > > Sneakernet offers other advantages also related to communication off > > the > > internet. Sneakernet currently has a bandwith cap well beyond anything > > possible on the internet. It might also be possible to run a freenet > > node with out any connection to the internet at all - this would make > > freenet extremly stealthy. > > > > Sneakernet raises it's own concerns that would have to be addressed > > and > > currently I am not sure on all of them. Mainly, how to protect the > > person carrying the physical media. Encryption is obviously needed but > > I > > am not sure of exactly how to implement it. Am I correct in assuming > > that each key in the datastore requires a public key to decrypt and > > that > > public key is not available in the data store? Does that mean that the > > standard datastore keys would be protected enough to burn dirrectly > > onto > > cd and import elsewhere? > > > > Aside from these issues which I hope we can work out I have thought up > > the following sample implementation of sneaker net (which is of course > > also up to comment and improvement). Sneakernet could be implemented > > by > > burning keys onto cdrom, in this case mini-cdr would be a good choice. > > They hold up to 180 megs and they are quite small. If your not > > familiar > > wity mini-cd open up your cdrom and check that dip in the middle, that > > is how big they are. The small size is great because it could be used > > in > > a "crack pass" fashion of clandistine trading and it holds a good deal > > of information. > > > > The issue of finding people to trade can be dealt with simply as well. > > Assuming that the fact that you are running a freenet node is not > > hidden > > each person willing to participate in sneakernet simply wears an easy > > to > > spot article of clothing or sticker. Say a freenet hat or a freenet > > pin > > or shirt, anything easily identifiable. When you notice someone else > > who is participating in sneakernet just trade mini-cds with them, go > > home, insert it into your machine, and tell fred to import it. > > Hopefully > > the same kind of interface could be adopted for the reverse - a 2 or 3 > > click interface to burning a new sneakernet cd. > > > > Using cdroms in this fashion has another great benefit - automatic > > garbage collection. Over time, the cdrom would get scratched and > > otherwise degrade from (mis)use. People would probably also throw them > > out, play frisbee with them and have a general lack of respect for it > > considering it is free and all =) > > > > What do you think of my concept? Please provide feedback positive or > > negative, I am interested in hearing it =) > > > > -- FLOG > > > > > > > -- > Matthew Toseland > toad at amphibian.dyndns.org > amphibian at users.sourceforge.net > Freenet/Coldstore open source hacker. > Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 > http://freenetproject.org/ >
