The Free Network Project Summer Projects 2008

The Free Network Project is excited to take part in the Google Summer of Code 2008∞. This project endeavors to fund students to contribute to an open source project over the summer break AND get paid for it. This is the third time for us, the first was in 2006: Announce on @devl∞

We have been accepted as of the 17th of March. Google's guide to applying as a student: here∞.

General approach

Please don't be limited by the ideas list. Mostly a good student can do a wide range of projects, although sometimes there are good reasons to limit your options. Your first proposal will probably not be accepted as-is, that's nothing to worry about, we will negotiate a feasible and useful proposal during the application process. If you have a specific idea that you're very keen on, even if it's rather ambitious, by all means submit a proposal; last year you were allowed to submit many proposals, and I assume it will be the same this year. Candidates who contact us and submit a bug fix or two will be looked on very favourably. Last year we had very self-contained proposals in an attempt to reduce workload for mentors, the problem with this is it encourages students to be completely noncommunicative with the rest of the community. This year will be different: almost all communication between mentor and student should occur through the public forums, and more core-code projects will be considered. (Of course, big changes will generally be developed on branches). Some of the below projects are much more difficult than others, but a partial implementation of a hard project is usually a success.

If you want to send us a proposal prior to actually applying, email us at devl at freenetproject.org.

Example Proposal Ideas

• More friend-to-friend functionality. There needs to be a real value-add for adding your friends as connections, and it needs to be really easy to do so, while still being reasonably secure. Various forms of easy introduction have been proposed, and easier and more useful instant messaging, file transfer, bookmark sharing, Thaw index sharing etc would be highly beneficial in terms of growing the darknet as quickly as possible. An auto-installer package, ideally a small, self-mutating package that downloads the node itself via the Update Over Mandatory mechanism, and from which the noderef could be extracted if the user already has a node, would also be interesting.
• Browser problems. 0.7.0 will ship a Firefox profile, which will be configured for maximum security and performance for Freenet. Unfortunately, there is a bug∞ in Firefox which causes some problems with this. However, other solutions may be interesting too. Basically, the problems we want to solve are: 1) We need either a lot of parallel connections to fproxy, or ideally we would like to have not only web pages but also inline images show up as a loading graphic (perhaps even a progress bar) until they are loaded, which is then replaced when the data is found. 2) It must not be possible for a regular web page to access our browser history (via e.g. the CSS hide-link-if-visited property). Suggestions have included a plugin, an extension, or bundling a browser (this last is IMHO problematic in that we'd have to keep it up to date, and it would increase the download size significantly). It might even be possible to allow limited javascript via a plugin??
• More work on anonymous development. Finish pyFreenetHg (some major features are missing), identify any core changes that are needed to better support it (and ideally implement them), set up scripts to gateway the mailing lists to and from FMS or whatever forum system becomes dominant, access to the bug tracker over freemail, debugging on freemail, and build a system to publish a continually updated pyFreenetHg (or other freenet-hosted distributed VCS) tree mirroring the main SVN repository (with easy migration if we choose to switch the main repository to Mercurial). Demonstrate the full range of DVCS functionality on a mercurial (or other) tree hosted on Freenet (merges of bundles etc). Possibly implement some form of Freenet-friendly bug tracker system (maybe with a plugin).
• More work on searching. Last year's project resulted in the new XMLSpider and XMLLibrarian plugins, which were a great improvement on the old code, however there is much work to be done on user-friendliness, integration, features, long-term searches, and search accuracy/usefulness.
• Client layer: keep progress of requests and inserts in a database (probably not BDBJE, it has corruption problems), rather than in RAM. Store to a separate file only enough to restart from scratch if the database is corrupted. Would greatly reduce RAM usage on most nodes and decouple it from the size of your queue. There are some complications e.g. we should probably keep fproxy requests in RAM, we need to find a few keys-to-fetch in advance to avoid stalling on the database when we should be sending a request, etc.
• Better support for perverse connections: PMTU discovery∞, variable bulk/block transfer block size∞ depending on MTU, automatic detection when we are losing packets above a certain size∞, fragmented retransmission∞ as a last resort if a big packet keeps getting dropped, exchange MTUs if known during connection setup, NAT-PMP, TURN, better port forwarding detection∞, etc. And anything else that would help Freenet to work on a wider range of connections, but see the proposal on transport plugins below.
• Rebuild the low-level transport code. It should be a lot more TCP-like, at the moment it does pull-retransmission, has a severely limited window size, and has many other wierdnesses, not to mention a huge per-packet overhead (for smaller packets). See here∞ and here∞.
• More libraries for FreenetFCPSpec2Point0.
• A working wiki system for Freenet. There has been some work on this but afaik it wasn't finished / didn't have write support? Maybe ikiwiki∞ with mercurial over freenet∞ might be a good starting point.
• Easy publishing via WebDAV.
• Content filters for all the popular MIME types. At the moment we sanitise HTML reasonably effectively (but we don't support a lot of recent stuff; we do strip scripting and changing that is outside the SoC's scope), we let through text (after checking it for RSS), and we do basic sanitising of JPEGs, PNGs and GIFs. Everything else results in a warning to the user. We should have better support for HTML5/XHTML2, possibly with embedded SVG etc, and filters for RSS, MP3, Ogg everything, PDF (big job!), etc. Also, we should implement optional (but by default) filtering on insert to strip out potentially compromising metadata, using the same filters with different settings.
• A web forums system running as a plugin for fproxy, which could be embedded in freesites and themed according to their requirements, and internally would talk to FMS.
• More unit tests. Both on low level and high level classes. Last year sback did a great job dissecting some of our low level classes and writing a lot of low level unit tests for them, and finding a number of bugs along the way. He's now implementing auto-generated regression tests, but hand-written unit tests are also enormously valuable, especially for higher level stuff. For example, we have a number of whole-network-in-one-JVM tests in freenet/node/simulator/. These could be streamlined by for example implementing a non-encrypting internal transport as an option (this wouldn't require full transport plugins, it's just a matter of some interfaces), and it would be good to augment them with more tests of some of our mid level and high level classes. There are also plenty of important low-level classes that haven't been tested.
• Transport plugins∞. Make it both possible and as easy as possible to write a plugin for the node to talk to another node which has the same plugin, over TCP, HTTP, Jabber, etc, or a steganographic protocol: make Freenet traffic look like VoIP, computer games, etc etc. This is harder than it sounds. It will work best if a big part of the new transport layer∞ has been done first. But transports' requirements vary dramatically: stream, packet, reliable packet; variable latency, size and overhead. Obviously we won't have a complete solution in the SoC, but a good candidate could make a good start and write at least one plain transport and one steganographic transport. It's more important to make it easy to write stego transports than to write hundreds of them. :) The second phase is support for high latency transports - Sneakernet∞, pocket switched networking∞, parasitic VoIP, etc (including work in the core and the UI, and also work on supporting fragmented networks). But this is probably way beyond the scope of SoC 2008.
• Revamp the plugin system. The most fundamental thing is a clean, simple API, separated from the node and exposed as an external library that plugin authors can use without having to get into the guts of Freenet. A plugin should declare which rights it needs access to at load time, and we can enforce this through wrappers, class loaders and similar mechanisms∞. A really good plugin system would allow many kinds of plugins to be used with reasonable safety even from untrusted sources. And of course there are minor but important features like updating over Freenet for official and unofficial plugins. Note that this is a hard project! It may have to be done by a core dev, but we haven't found time before 0.7.0. We need a clean API, separate from the node internals; we need plugins to list the rights they need on load, and the user to be asked about them;
• Webmail interface for Freemail, plus potentially an interface for seeing delivery statuses of messages and so forth.
• Packages for all the major Linux varieties, and better support for Linux (e.g. at the moment the installer doesn't even add an init.d script). Likewise on OS/X. Specifically, linux doesn't install a startup script, there are no linux packages except for one unofficial ebuild, the OS/X startup script doesn't work, and we should have the bunny systray icon back (there was some progress on this but nextgens ran into some problems). Note this is a low priority and relatively easy project, apply for something else as well. We would expect maintainable scripts and templates so we can do daily builds of packages etc. Rewriting the installer is not a priority at the moment, although if you think you can make it much better then contact us.

How to sign up

Go here∞.

Requirements

(Partly borrowed from here∞).

• You must not overbook yourself. Working on your Freenet project should be your main activity for the entire summer.
• You must be willing to provide weekly status reports at a minimum
• You will be expected to learn how to use Subversion, Mantis, and other Freenet tools
• You must communicate with the other developers and to some extent (depending on your project) the users

Proposal Guidelines

Students are responsible for writing a proposal and submitting it to Google before the application deadline. The following outline was adapted from the Perl Foundation open source proposal HOWTO. A strong proposal will include:

Connecting to IRC (#freenet on irc.freenode.net) and asking one developer for guidance/advices is probably a good idea.

Frequently Asked Questions