Hi All, Pardon my long proposal but I just learned about freenet and I'm fairly excite to see if there is anything I can do for you folks.
EXECUTIVE SUMMARY What I Want To Do: Create a freenet client that adds versioning, interactively and indexing to freenet data - allow arbitrary documents within freenet to be viewed as "message boards" with HTML, updatable documents and links. What I Need: My "BBS language" application already exists and I believe it can interface with freenet fairly easily. No changes would be need to the present freenet protocol - indeed, it would be better if none were made. The BBS language application is written in python. I need feedback about entire plan and perhaps some understand of where free-net client feed their information to. (url - http://www.crucialquestions.com/) PROBLEMS AND SOME IDEAS FOR SOLVING THEM 1. THE VERSION PROBLEM The apparent inability to update documents once on freenet **APPEARS** to be a serious drawback. Since there is no central freenet document that can be updated to give a list of recently posted documents, as it is, freenet cannot stand alone. It SEEMS to prevent the kind of growth which the world wide web experienced as users began at a central node and gradually migrated as found out about other sites. SOME SOLUTIONS: * External information - Dependence on external pages on the web is clunky and seems to at least partly defeat the purpose of freenet. * Versioning implemented within the freenet nodes - The use of signed versions of a document has been proposed but this solution seems to give "low-level" nodes too much "high-level" activity to do - as well as being hard implement (though I really don't know how hard). * Document display language - Instead of expiring any documents at all, a time sensative document could have an embedded tag specifying where it's further versions could be found. This tag would describe what the key of a replacement document would look like - it would be either the largest key of the form string+Num. Where Num+1 does not exist or it would be the document tagged with a timestamp closest to the current time. A user wishing to create a validated version could specify that the version would be signed - the sequentially highest correctly sign value would be taken. The document display language solution is one that can placed "on top of" the present freenet protocol rather than modifying it in any way. I believe this is an effective solution to the update problem as well as several other apparent problems with freenet. 2. ADDING INTERACTIVE CONTENT Unlike the web, Freenet cannot use conventional CGI applications because there is no fixed webserver server on which to run them. Also, a system such usenet with a single hierarchy of topics would seem to go against the freenet philosophy. However, it is quite possible to add interactivity by using various client-side applications reading various protocols off freenet nodes. One could run a message board-type application from a node if the CGI application ran on the client side and treated freenet as something like a file system. This could work if everyone using the system would have to have a compatible client program. If this were to happen, it is more likely that single protocol would evolves, since no node would not want to have many separate client programs. But most existing message boards suffere from a limit number of pre-existing views of their data. What is required is a flexible interactive protocol to give an abitrary view of the data. A display language would again be the key. The simplest model of a BBS would one document which tells the client "display the documents with a key of the form "discusion/here/N", starting with N = 1 and increasing till you can't find a key or until you go past a thousand. If you look at it, with sufficiently rich display language, it would be possible to over-come any limitations of documents never being removed or of different parties inserting documents for different purposes. The interactive display language include HTML and also specify ways in which multiple documents and keys would be searched, combined and added-to. It is important that our description language be highly expressive but not so general that it could allow viruses - a bad thing. Ideally, a language of this sort would conform to the XML/XSLT standard. However, these standards do not by themselve have conventions that are yet specific enough to for our purposes. 3. CCQ - One Display Language I have been working on a display language that fits the general requirements I outline above for about the last year. The CCQ BBS system is a python-based display language distributed as source open. The CCQ system has evolved to the point that it has a working message board written in it (see www.crucialquestions.com). Essentially, the CCQ has an interpretter which loads language statements and uses them to display further statements. This series of search commands and if-else logic from the document, it loads the different sub-documents and determines what links will change which options and how further document will be written by user action. Thus it allows arbitrary HTML pages to be displayed as well as linking and interspersing web pages within these documents. Because, like freenet, the entire system essentially involves a key-document architechture, the system should be fairly easy reconfigure so that it is "pointed" at a base key of freenet rather than "pointing" at the servers' file system. Because it generates html, ccq client could then be fed to a web browser. PORT DETAILS. CCQ runs on generic python on a web server at the moment. The Client object could run either as a webserver on the local machine or as a mozilla plugin. I don't know how netscape pluggins work so I'll assume it will run as a local http server. As such, it could run under apache or use the python http libraries. Assuming it can treate freenet just two functions that write and return documents from keys, it should be able to run with just a few modifications, changing some search logic, caching and such. I would be willing to put the effort into porting the application to freenet if folks were interested in making the completed result part of the freenet distribution. What do you think? Joe Solbrig jsolbrig at webcom.com _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
