I am glad to see some replies to my intial post =) This email tries to cover what has been said and what I think that translates into regarding the SneakerNet transport method.
First, I think defining a set of goals is in order: * Augment Freenet's ability to transfer data * Provide transient node users with the ability to use plausable denibility Second, the lessons learned so far: * Routing has NO hope of working over sneakernet * SneakerNet needs to deal with speciliziation to be effective for permanent nodes We are just going to have to accept lesson number 1 as nothing we can solve but instead must work around. This is probably beter for SneakerNet as it means less code internal to fred would need to be changed to pull this off. I believe I also have a scheme to handle lesson number 2. I agree that SneakerNet needs to work with specilization instead of against it. I will provide information a little later in this email on how, first I would like to raise some points I thought up regarding sneakernet. Sneakernet's behavior can be modified quite a bit. I see the following options being available to a person that wants to engage in sneakernet: Import: * Import all keys on the CD * Import keys that seem to match the node's specilization (see below) * Filter out keys that are too "old" (compatible with previous choices) Export: * Export keys at random * Export the "newest" keys * Export the "most popular" keys The trick now is to use each of these behaviors where it is best suited. In regards to a person running a transient node I believe it makes the most sense to import as much information as possible. This is because their datastore is going to need the most "churn" to get rid of the stuff they requested as well the fact that old keys dropping out of a transient datastore won't effect the rest of the network. A transient node should export keys at random to avoid giving away their most popular keys which are probably the keys they have most recently requested. The behavior a permanent node needs is completely different. We need to be carefull not to push out too much old content as their are still hopes that it might get requested on the network. In this case, I would think that only importing content "close" to our specilization is in order as well as filtering keys by date. I can see any export method being usefull in this case, assuming the other nodes are selective in the correct way on their import. I believe a good way to think of sneakernet is to ignore the data transport method and think of fred having access to a vast ether of keys. Fred's job in this case is to pluck out the keys that will make the network the "happiest." The fact that the keys are comming over CD is really irrelevant. Now this round of ideas is dependent on fred knowing which set of keys to pluck from the ether and the idea is that keys closest to it's specilization are the correct ones. However, according to my understanding, specilization is not something a node "knows" about - in other words, specilization is a function of how the rest of the network deals with your node, not something your node has an active part in deciding. To make this worse, it is also my understanding that specilization is dynamic and can change rapidly. Neither of these make it easy to detect what your node's specilization is at the moment. I am hopping that the node would be able to make a fairly accurate guess at it's current specilization by examining the keys in it's datastore. If the node built a list of the keys it contained would it not be possible to do statstical analysis and look for the abnormality and assume this is the node's specility at this time? Sure, that is not perfect but it might give it a good enough guess to make a judgement about what data it would like to grab out of the "ether." To help hone things in, it might make sense to only analyze the keys of the past 5 (or what ever number makes sense) days to get a more accurate portrayal of it's specilization now, not 3 weeks ago. Finaly I would like to get everyone's comments on how to provide this to the end user. It seems to me that the best way to do it would be to provide a dialog for either import or export that provides all the available options. The "correct" set of options is selected by default for the user based on what type of node they are running. This makes sense because most users will take the default options anyway and anyone who knows what they are doing can tailor their import/export to their environment. I look forward to everyone's comments on this as well. Thanks for your support and I hope we can figure out a way to make the transient users safer then they are now! -- FLOG
