Kevin Atkinson: > The only thing I have implemented is storing and retrieval of data > keys.
There isn't much else! > One should not have to worry about bandwidth considerations at > all. Somebody has to pay for it. > General searching based on keywords will be build into the > protocol from the beginning. You should stick to simple file publication for now. > And if it does delete it it will first try uploading it to other > nodes with more disk space available. Probably a bogus optimization. > 5) Streaming Media > 6) Online Chat (with possible IRC or similar gateway) You probably won't be able to get the latency low enough without throwing away most of your other features. > Please note that I still wish to allow for anonymous posting of > content. However, without encryption, it probably won't be as > anonymous as Freenet or your GNet. Link encryption is far less critical than the overall anonymizing properties of your design. (And that design could simply be an optional mixnet pre-route stage.) It only helps to prevent your ISP from analyzing the content of your traffic. Encryption is not very expensive either. > I have nothing against complete anonymity, it is just that I am > afraid that both Freenet and GNet or more designed around the > anonymity and privacy issues then they are around the performance > and scalability issues. Yes, but note that significant anonymity is inherent in Freenet's design. > I also believe that knowing what is in one owns datastore and > being able to block certain type of material from one owns node is > not that big of a deal. It is a big deal, and node operators could very reasonably be held accountable for refusing to block known illegal files. > There will not be anything like freenet's KSK keys as those proved > to be completely insure. Instead Map keys may be requested with > out a signature. That is nearly as bad: although I can't actually overwrite your file, I can insert bogus files with similar descriptions, and the user will have no means to discriminate between yours and mine. > For efficiency reasons a node can be asked which blocks it has > based on a given index block rather than having to ask for each > and every data block. And that only helps on the off chance that the node you're requesting from possesses the index block already? Dubious optimization. You're never going to be efficient at all if you have a high ratio of attempted to successful requests at each hop, anyway. > A block size of just under 32K was chosen Gnunet's blocks are under 1500 bytes. They fit in an ethernet frame. So how are you coping with the probability of failure given so many blocks? _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech
