> Date: Tue, 29 Aug 2000 21:08:06 +0700 > From: Oskar Sandberg <md98-osa at nada.kth.se> >
> On Tue, Aug 29, 2000 at 03:18:42PM +0200, Martin Richtarsky wrote: > > On Mon, 28 Aug 2000 22:58:21 -0400, Michael Wiktowy wrote: > > > > >Let me know if you think that I am out to lunch with this. > > >More constructive criticism would be greatly appreciated. > > >Far future pre 1.0 ideas would be appreciated too. > > > > > >http://members.home.com/mwiktowy/roadmap.html > > > > > >Mike > > The history is a little fuzzy. I don't remember exactly in what order what > went in, but the changes to the node between 0.1 and 0.2 were pretty big, > especially in the protocol (support for data tunneling, keep alive > connections, etc). Basically 0.1 was "It's alive!", 0.2 was "It's alive > and it's organs don't fall out as soon you poke it", and 0.3 is finally > robust. I added those details. I was a little sketchy about what the specific changes were between 0.1 and 0.2 other than "doing the same thing ... better". I viewed documenting the history of Freenet less important than documenting the future so I spent less time on it. > Serapis is post-0.2 (it's where most of the code we did in June went). It is sort of a side project to help the node development. It is not truly a part of the reference implementation but I thought it was important to note. I am thinking that an auxillary timeline is needed to say what kind of applications are possible to build on top of Freenet given the mechanisms available. I will give some thought on how to best include that. > The fact that there is finally a decent client/client library is a big new > feature with 0.3. Included. > I'm not sure about the order of stuff between 0.4 and 0.5. I think a real > PKI is pretty high priority, and once that is in ARKs (which is address > resolution keys) should be very simple. Moved to 0.4. > I agree about making optimizing routing high priority, though I think that > "- decentralized node discovery " (which you have listed as 0.6) is > actually a big part of that since I believe the "backwards" only nature of > reference created through inform, and the fact that inserts are reversing > the datastore vector, hurts routing. I changed it to indicate the elimination of inform.php by 0.6. Other influences to request reliability that I can think of would be: - reference count - the more references available, the less change of a broken reference chain. - data propegation away from the key-space core - in my thought experiments, I can see data propegating to a donut around the key-space focus with the core nodes dropping it - sort of like an event horizon of a black hole, requests that originate outside will return data while the fewer requests that originate inside are lost forever. > "Bidirectional references" is NOT a set thing for update propogation. > Neither my nor Ian's argumented ways of achieving this used bidirectional > references (though it (bi-ref) is, in my opinion, less insane what Ian > wanted, though it suffers from the same basic flaw (any node should be > able to find data - data should not be able to find any node)). I agree that it is sort of a throwback to the "information is on a particular server" kind of mentality. However, all of this talk about people wanting to keep thier keys popular on thier nodes leads me to suspect that for some rare data we will have to effciently find that one node that the data originated from without searching the entire Freenet (since in the current self-sorting bias, that node will be one of the least likely nodes that will be searched) Regardless ... I don't view anything in the future as "set". I think that I will adopt the convention: current release verision + 0.1 will list currently agreed-upon mechanisms to be implemented current release + 0.2 will list proposed ideas for concepts to be implemented current release + >0.2 will be a wish list I listed bidirectional references in there since it stuck in my mind as a good clear idea. Could you please post the official "Oskar's Idea for Update Propegation" and "Ian's Insane Update Madness" since they are likely clearer in your mind than they are in mine (and in the archival debate). I will add them to the list of proposals for +0.2 development stuff. Bidirectional references might be handy for the perceived "event horizon" problem mentioned above also. > "Node stealth" belongs or 0.7 or somewhere down there, or even possibly in > further down (except maybe open sesame nodes which could be made part of > the PKI). I moved all of it to 0.7 ... there is nothing stoping someone from personally promoting items on the roadmap by implementing them. But the fact is that open sesame nodes should be done after PKI. > There is also the possibility of anonymity through an internal > mixnet/onion routing structure. That should be somewhere down there. Added to 0.8 along with other stealthifying stuff. > Otherwise this looks pretty correct - good work. You should probably adopt > a syntax to denote things that are a uncertain. Like I said, nothing is certain. I will add a note to mention my "certainty convention". > > Alternate transport protocols should be mentioned somewhere (unless you > > mean that with 'protocol spoofing nodes '). Examples: UDP, HTTP, > > perhaps even FTP? > > UDP is an alternate transport. The current Freenet Protocol over plain UDP > will not be possible, since it assumes the transport is not lossy - > another presentation/application layer protocol would have to be used. > > HTTP and FTP are alternate presentation/application layer protocols. They > are not useful for Freenet, but one could imagine hiding Freenet's traffic > inside the data part HTTP and FTP traffic. Not now though. That was a subset of what I meant by node stealth but I added some clearifying words. Thanks for your feedback and I hope it will continue from all the developers. Once I get access to the CVS, I will plunk it the webpage in there somewhere under the development section. Mike _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
