Most recent edit on 2008-03-28 14:11:37 by MatthewToseland [javascript]

Additions:
- 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??

Deletions:
- 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).

Edited on 2008-03-28 14:01:16 by MatthewToseland [add browser problems]

Additions:
- 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).

Edited on 2008-03-27 18:46:34 by MatthewToseland [add anonymous development item]

Additions:
- 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).

Edited on 2008-03-27 16:56:11 by MichaelRogers [2006/7 were mislabelled as 2005/6]

Additions:
Summer of Code 2006 was very successful: Jerome Flesch built Thaw, a well-maintained and widely used filesharing app we have bundled with Freenet for some time. Florent Daigniere did a lot of good work on the installer and other boring stuff, and continues to be a core dev; Dave Baker did some good work on Freemail, although this is not very widely used as yet and is still somewhat buggy; and Michael Rogers' simulation work was of less value than we had hoped, but still useful. See NewTransportLayer for some related work. All of these were people we knew already to a greater or lesser degree.

Summer of Code 2007 was expanded and somewhat less successful: Notable successes include unit tests, searching, and more simulations (that helped to deal with a major attack vector amongst other things). Other projects included a C++ library (which wasn't finished or documented, and hasn't been widely used afaik), a blogging plugin (which works, but isn't currently bundled and may have been overambitious technically), and a new link layer encryption scheme (which was reworked by a core dev). However we did pass all of our students. Some of them still contribute.

Deletions:
Summer of Code 2005 was very successful: Jerome Flesch built Thaw, a well-maintained and widely used filesharing app we have bundled with Freenet for some time. Florent Daigniere did a lot of good work on the installer and other boring stuff, and continues to be a core dev; Dave Baker did some good work on Freemail, although this is not very widely used as yet and is still somewhat buggy; and Michael Rogers' simulation work was of less value than we had hoped, but still useful. See NewTransportLayer for some related work. All of these were people we knew already to a greater or lesser degree.
Summer of Code 2006 was expanded and somewhat less successful: Notable successes include unit tests, searching, and more simulations (that helped to deal with a major attack vector amongst other things). Other projects included a C++ library (which wasn't finished or documented, and hasn't been widely used afaik), a blogging plugin (which works, but isn't currently bundled and may have been overambitious technically), and a new link layer encryption scheme (which was reworked by a core dev). However we did pass all of our students. Some of them still contribute.

Edited on 2008-03-26 05:08:27 by NextGens [huh?]

Deletions:

Sugestions

Library in C or C

Wrapper transport to tor, mute or gnunet

Recompile java source code in gcc-java or bytecode similar Parrot

Edited on 2008-03-25 13:51:42 by MatthewToseland [link to google]

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

Deletions:
We have been accepted as of the 17th of March. Students can apply from the 24th.

Edited on 2008-03-20 17:45:12 by MatthewToseland [elaborate on packaging, and explain that it's not high priority]

Additions:
- 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.

Deletions:
- 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.

Edited on 2008-03-18 23:14:26 by MatthewToseland [email]

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

Edited on 2008-03-18 22:17:03 by TimesE [Sugestions]

Additions:

Sugestions

Library in C or C

Wrapper transport to tor, mute or gnunet

Recompile java source code in gcc-java or bytecode similar Parrot

Edited on 2008-03-18 15:41:53 by ArneBab [Link to mercurial over freenet and ikiwiki added]

Additions:
- 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.

Deletions:
- 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.

Edited on 2008-03-18 15:35:26 by ArneBab [note ikiwiki with the existing mercurial freenet backend to the wiki proposal.]

Additions:
- 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.

Deletions:
- A working wiki system for Freenet. There has been some work on this but afaik it wasn't finished / didn't have write support?

Edited on 2008-03-17 23:57:03 by MatthewToseland [we've been accepted]

Additions:
We have been accepted as of the 17th of March. Students can apply from the 24th.

Deletions:
(We haven't yet been accepted, since orgs cannot apply until Monday. We will update this page when and if we are accepted, however it is likely on our past record).

Edited on 2008-03-05 15:22:24 by MatthewToseland [progress-in-database]

Additions:
- 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.

Edited on 2008-03-05 15:03:45 by DaveBaker [add freemail webmail]

Additions:
- Webmail interface for Freemail, plus potentially an interface for seeing delivery statuses of messages and so forth.

Edited on 2008-03-05 14:56:13 by MatthewToseland [mention RSS]

Additions:
- 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.

Deletions:
- 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 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.

Edited on 2008-03-05 14:55:19 by MatthewToseland [formatting]

Additions:
- 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 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.

Deletions:
- 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 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.

Edited on 2008-03-05 14:54:56 by MatthewToseland [mention scripting stripping]

Additions:
- 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 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.

Deletions:
- 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, as well as of course stripping out scripting), 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 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.

Edited on 2008-03-05 14:53:25 by MatthewToseland [delete javascript filtering]

Deletions:
- Javascript filtering∞. It should be possible to implement a javascript filter: A lot of javascript is inherently safe, it's a question of defining those parts that are safe, failing on access to the rest, and creating libraries of sanitized functions that can be swapped in by the filter (possibly at a performance cost). Some of the security issues will be quite convoluted e.g. how do you prevent a message board app from doing timing-based profiling on your datastore? Upload rights should be restricted, and a possible solution would be per-client caches.

Edited on 2008-03-05 14:53:00 by MatthewToseland [link]

Additions:
- Javascript filtering∞. It should be possible to implement a javascript filter: A lot of javascript is inherently safe, it's a question of defining those parts that are safe, failing on access to the rest, and creating libraries of sanitized functions that can be swapped in by the filter (possibly at a performance cost). Some of the security issues will be quite convoluted e.g. how do you prevent a message board app from doing timing-based profiling on your datastore? Upload rights should be restricted, and a possible solution would be per-client caches.

Deletions:
- Javascript filtering. It should be possible to implement a javascript filter: A lot of javascript is inherently safe, it's a question of defining those parts that are safe, failing on access to the rest, and creating libraries of sanitized functions that can be swapped in by the filter (possibly at a performance cost). Some of the security issues will be quite convoluted e.g. how do you prevent a message board app from doing timing-based profiling on your datastore? Upload rights should be restricted, and a possible solution would be per-client caches.

Oldest known version of this page was edited on 2008-03-04 15:16:58 by MatthewToseland [first version]

Page view:

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 haven't yet been accepted, since orgs cannot apply until Monday. We will update this page when and if we are accepted, however it is likely on our past record).

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.

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.
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.
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.
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?
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, as well as of course stripping out scripting), 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 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.
Javascript filtering. It should be possible to implement a javascript filter: A lot of javascript is inherently safe, it's a question of defining those parts that are safe, failing on access to the rest, and creating libraries of sanitized functions that can be swapped in by the filter (possibly at a performance cost). Some of the security issues will be quite convoluted e.g. how do you prevent a message board app from doing timing-based profiling on your datastore? Upload rights should be restricted, and a possible solution would be per-client caches.
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;

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:

    * Name

    * Email

    * Project Title

    * Benefits to the Freenet Community - a good project will not just be fun to work on, but also generally useful to others.

    * Expected Results - It is very important to list quantifiable results here e.g.

          o "Improve X modules in ways Y and Z."

          o "Write 3 new man pages for the new interfaces."

          o "Improve test coverage by writing X more unit/regression tests."

          o "Improve performance in FOO by X%."

    * Project Schedule - How long will the project take? When can you begin work?

    * Bio - Who are you? What makes you the best person to work on this project?

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

Frequently Asked Questions

Am I eligible?
Please see the StudentFAQ∞ for all questions about eligibility.

When is the proposal deadline?
Your proposal has to be submitted before the 1th. of April 5PM PDT.

What projects were completed successfully by students last summer?
Summer of Code 2005 was very successful: Jerome Flesch built Thaw, a well-maintained and widely used filesharing app we have bundled with Freenet for some time. Florent Daigniere did a lot of good work on the installer and other boring stuff, and continues to be a core dev; Dave Baker did some good work on Freemail, although this is not very widely used as yet and is still somewhat buggy; and Michael Rogers' simulation work was of less value than we had hoped, but still useful. See NewTransportLayer for some related work. All of these were people we knew already to a greater or lesser degree.
Summer of Code 2006 was expanded and somewhat less successful: Notable successes include unit tests, searching, and more simulations (that helped to deal with a major attack vector amongst other things). Other projects included a C++ library (which wasn't finished or documented, and hasn't been widely used afaik), a blogging plugin (which works, but isn't currently bundled and may have been overambitious technically), and a new link layer encryption scheme (which was reworked by a core dev). However we did pass all of our students. Some of them still contribute.
We are not going to turn away anyone just because we don't know them, however past experience coding Freenet will be helpful in an application.

Valid XHTML 1.0 Transitional∞ :: Valid CSS∞ :: Powered by Wikka Wakka Wiki 1.1.6.2∞

Page was generated in 0.1910 seconds

FreenetWiki : SummerOfCode2008

Sugestions

Sugestions

The Free Network Project Summer Projects 2008

General approach

Example Proposal Ideas

How to sign up

Requirements

Proposal Guidelines

Frequently Asked Questions