Big projects which are not part of the roadmap at present
These are large projects which might otherwise be suitable for a Summer of Code project, but because they are very large or very difficult, probably aren't. They are not part of the roadmap for expediency reasons, but they may be one day; and they should enhance Freenet is fairly significant ways.
Projects:
- XULRunner-based frontend (or maybe in java, or wxWebkit). This would talk to the node over FCP and would be the primary point of contact between the user and the node. Most of the interface would be similar or identical to the current fproxy, but some major changes would be much more efficient and cleaner with a dedicated application rather than a general purpose web browser, even with javascript: loading progress for a file/page, loading progress for inline images on a page, uploading files or directories from disk, no browser history worries, have the location bar show only the freenet key, no connection limit problems, etc. See bug 2830. * BIG PROJECT! *
- Transport plugins! Make Freenet able to use plugins for node to node communication to get around network obstacles and disguise traffic: TCP, HTTP, VoIP, etc. This will require several different types of plugins, each with its own crypto and retransmission, packet fragmentation etc rules, and probably with various parameters such as expected latency, packet size etc. * BIG PROJECT! *
- Untrusted plugins: Plugins downloaded from Freenet, run in fproxy. Probably in the form of compiled code. Use fixed, published, proxied APIs and custom class loaders to ensure that code can only do what it is specifically allowed to do. Note that this probably requires rebuilding the plugins system yet again: We do not have a proper plugin API at present. * BIG PROJECT! *
- Javascript filter: A really talented student could write a javascript filter, limiting the API available to scripts and allowing specific functionality to specific pages, ensuring that any new HTML is filtered, etc. Javascript allows you to grab a part of the API and stick it in a variable; there are various solutions to this, which generally involve code morphing (type tracking variables, substituting something from a "safe" API, etc). * HUGE PROJECT! *
- Filters for PDFs and office documents. The PDF spec is huge (approx 700 pages), the ODF spec is huge (approx 700 pages), OOXML is infeasible (5000 pages plus). Writing a fairly complete filter for PDF or for ODF (probably less useful than PDF) would be a plausible SoC project, although modern HTML, RSS, SVG and a couple of audio/video formats is probably more urgent; writing a filter for OOXML would be an exercise in masochism. * BIG PROJECT! *
