Google Summer of Code 2009
We constructed a set of use cases (roughly speaking) some time back when we thought we might have some funding. Many mostly small things are linked from this bug report, but many are not, please have a look around, also check the mailing list archives. Also, here is a detailed suggestion, which likely needs much work to look good and be functional...
And some debugging for the Freemail backend. Possibly with a common identity / single login with Freetalk (our chat forums system), and possibly using the Freetalk web of trust and/or CAPTCHAs to prevent spam/DoS attacks on Freemail.
Maybe loosely based on Thaw, but running in the web interface. This should allow people to publish indexes of files, link to other file indexes, search known good file indexes, possibly exchange info on indexes via a Web of Trust application using the WoT plugin on which Freetalk is based, set up long-term file searches, and so on. The problems of spam/deliberately corrupt content are very similar on Freenet to on traditional p2p, although the solutions may be different, especially as it isn't possible to trace spammers; trusted community maintained indexes have developed as a working means of solving these problems on web-based filesharing.
This should support uploading files of any size, should avoid re-uploading larger files on every update, but should be configurable to do so on a schedule, should work from within the freenet web interface as a plugin, and may support WebDAV uploads direct from authoring software. The ability to mirror stuff from the web would also be useful, possibly using external command line tools.
Freenet has a web interface, the ability to publish static web sites (freesites) and files, private messaging (freemail) and will soon have a forums system (Freetalk) which can be embedded in freesites. But very few users, even of freenet, can be bothered to edit HTML themselves even with the free tools available; we should make it easy to make an in-freenet blog (flog?), with an embedded discussion forum, links to other flogs, files, pictures and so on. There have been attempts at this in the past: Echo, a plugin that tried to use XSLT for themeing and didn't quite make it, and a freenet port of Thingamablog. It must be a web-based plugin so it can be part of the freenet user interface, and must be really easy to use.
A .dmg file for OS/X, packages for all the major linux distros, scripts to build these (from *nix) and maintain the necessary package repositories. There are issues to solve with updating, and generally we can't be part of a distro which is frozen for years on end, so we will probably maintain our own repositories for linux. Robust scripts to automate package generation are *essential*. Also, a system tray icon, enabling users to access the node, temporarily throttle its bandwidth usage and/or switch it off and/or put it into pause mode etc. Possibly make the java-based installer on linux able to run as root and create a user for Freenet.
This is far more difficult than it sounds, unfortunately: because of spam and DoS attacks, and not being able to ban IP addresses, it will probably have to be manually filtered, maybe combining elements of distributed version control systems and/or Web-of-Trust based chat systems. There have been a couple of unsuccessful attempts at this in the past. ikiwiki may be helpful with mercurial over freenet (already working).
And more to do when you have added them. There are various proposals for easier exchange of node references, such as shorter references, possibly with out-of-band password-based verification (ideas have been posted on the bug tracker or the mailing lists). And when you have added your friends, you should be able to (non-anonymously) chat with them, transfer files easily, share bookmarks, share file indexes and so on. Even hamachi-style virtual LANs with peers have been suggested and might be useful, although there are performance/security tradeoffs. Social networking style features, on an opt-in basis, have also been suggested; your friend is likely to be your friend's friend, so the ability to see your friend's friends, if they want you to, might be useful and result in adding them as a friend (we have to be careful here though!)
Lots of work has been done on this, but much more could be done, in terms of better user interface, support for multiple indexes, long-term searches, web of trust integration, support for file indexes and so on; somewhat related to the filesharing proposal.
We have to "filter" HTML, images, etc to ensure that they are safe for the web browser, and won't give away the user's IP address via inline images, scripting etc. Currently we support basic sanity checking and removal of unknown chunks (which might make the browser do something dangerous) for PNG, JPEG and GIF, and HTML 4. We need significant refactoring and implementation work to properly support HTML 4, HTML 5, XHTML 1.X and XHTML 5 (and XHTML 2 if necessary), parsing the XML-based HTML's as XML but keeping support for the non-XML variants, while reusing the actual filtering code where possible, and implementing any necessary sub-standards, including better support for CSS (currently we sort of support CSS2, but the filter really needs rewriting). SVG (including embedded) and RSS/ATOM (usually with embedded XHTML) are also very important. Some audio/video formats would be a bonus especially given HTML5 (traditional flash-based video embedding is very problematic security-wise on Freenet).
The current low-level protocol is home-grown and not sufficiently TCP-like. It is limited to 256 packets in flight at a time, which can be a problem for high latency and high bandwidth, it tries to be TCP-like but has explicit retransmits and lots of messiness. It is also bad in other ways. Also, because we have lots of different sized messages, we pad packets with random data; it would be much more efficient to pad with data transfers where possible.
Packet size problems. We do not detect path MTU; this is difficult from Java, although possible with some native code. Also, detection of when packets over a certain size never arrive, or statistically that they are highly unlikely to arrive above a certain size (in which case we should fragment the packet) would help us to establish the maximum safe packet size. Once we know this, streams aka padding with data transfers (also in the previous job) would allow us to efficiently adapt. This would help Freenet to work on weird connections (VPNs etc).
At certain times of day/days of the week, set the bwlimit to X. Should include a "pause" capability where the node would not exchange any network traffic, or possibly keep connections open but not route any requests, and tell peers that we are paused.
We do not have any simulations capable of telling us what the impact of different load management schemes would be, and we do not want to deploy any new load management without simulating it first. New load limiting/balancing could potentially improve performance significantly... we do have a couple of existing simulators, but they don't simulate load.
At a minimum it would be useful to publish a procedure that third parties can use to build bit-for-bit identical versions of Freenet Project build products (i.e. jars) to verify that they are buildable from the released source. You can find the outline for a more ambitious proposal to increase build integrity here: https://bugs.freenetproject.org/view.php?id=409
Various people have suggested a P2PBackup "backup" system over Freenet. Clearly Freenet cannot provide reliable data storage, so this is something of a contradiction in terms. However, a means to provide full system snapshots would be feasible: It would be unreliable for "unpopular" files (files not on many systems), but it might be possible to identify such files automatically and back them up on limited paid-for external backup space and/or hardcopy. For "popular" files, which many people have on their systems, it could be useful and relatively reliable.