Ian Clarke <ian at freenetproject.org> writes: > For a while now, we have been working on the distribution servlet, which > is basically designed to allow people to give copies of Freenet, together > with seednodes, to their friends - effectively augmenting the current > centralized pull model of software distribution with a decentralized push > model. > Fair enough. I'm pretty happy that someone will come up with something that works if/when it's necessary. But I really doubt it'll be necessary.
> There is at least one question that hasn't been answered yet : when you > push a copy of Freenet to your neighbor - should it be the latest jar > (perhaps distributed over Freenet using a DBR), or should it be the jar > that you are using? > There's no way to enforce that it's the jar you're using, so we might as well send the latest jar. > The advantage of distributing the latest jar is obvious, but the > disadvantage is that it creates a danger that whoever has the private key > with which these jars are inserted - could be compromized, allowing > future Freenet jars to be corrupted. > This is starting to sound like a trusted 3rd party. It's not a bad idea, but people should definitely be able to disable auto-updating. > IF we do the latter (or even just offer the latter as an option), we need > a way to defend against a situation where the jar is compromized. One > way would be to give a number of people "veto" rights over a jar. So lets > say I or Oskar noticed that the current jar was corrupt in some way - we > could veto it by inserting a message into our private veto-subspaces. > This message could possibly contain a new subspace which nodes should use > instead. If multiple veto subspaces are disagreeing with each-other, > then the subspace given by the majority of those veto subspaces should be > used. > The idea of veto subspaces corresponds closely to certificate revokation; something that very few clients check. Of course there's a performance penalty to checking all veto subspaces, which should be considered. > Thoughts? > > Ian. My main thought about veto subspaces is that if there's multiple contradicting vetos, the user should be presented with all the information and allowed to make a choice however they want; a simple majority algorithm seems like a bad idea. Thelema -- E-mail: thelema314 at swbell.net Raabu and Piisu GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
