Ian writes:
> I would like to avoid a break in compatability if > possible, and it seems that we are very close to achieving > this. Perhaps allowing 0.4 to accept connections from 0.3 > nodes if a configuration parameter is set to true, and > setting this to true by default in 0.4, but to false by > default in 0.5. I very much like the general pattern of putting some kind of label on a group of data that identifies what to expect in the rest of the data. A related concept is a sub-tag that says "this is for stuff used by newer versions; if you're an older version, just ignore it". To be sure, these techniques are hardly panaceas. For example, you still need to insure that new versions pass enough information for old versions to work properly. Still, I've found the general concepts to be very useful in many different situations. I doubt if anyone here seriously disagrees with that vague statement, but Ian's mention of a config flag prompted me to get on the soapbox and sing a short pean to the concepts. Oskar replied: > My concern to this is that we are adding extra latency > rather then using the system to cut down on it. I'm > worried about the time it takes per hop as it is - I would > almost consider sacrificing forward security if it means > we can save the seconds the keyexchange takes. > Of course, maybe caching session keys for several > connection is a better idea. Continuing my original vague pean, the ideal would be for nodes to select their own idea of what constitutes a good speed vs. security tradeoff, with a minimal impact on nodes using older/standard configurations. Putting some very generic hooks in the protocol for future extensions seems like a good way to help make such behavior possible. Oskar continued: > Another detail we should consider in the final crypto > system is making it possible to run an invisible node - ie > one that comes alive only when a it gets a signed request > from a recognized peer. Such a node should be able to > masquerade as another service while waiting for the > authentication. Yes! This sort of thinking is a Very Good Thing, IMO. I recognize how hard it is to mask the mere use of Freenet; but surely it is good to think about making it easier to build a true "dissident mode" variation down the road. --Will _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
