| | 1 | Historical document -- from Google Summer of Code of 2009. |
| | 2 | |
| | 3 | |
| | 4 | [http://code.google.com/soc Google Summer of Code] |
| | 5 | |
| | 6 | UPDATE: The [http://www.python.org/psf Python Software Foundation], a GSoC umbrella organization, will sponsor Tahoe! |
| | 7 | |
| | 8 | Students: you don't have to use one of the following Ideas. You can come up with your own Ideas, either inspired by these or your own Blue Sky idea. The important things to remember are: 1. E-mail the Mentor team (listed at the bottom of this page) ''immediately'' saying that you are interested. 2. Submit an Application to Google by Friday at 19:00 UTC. That application doesn't have to be final and polished -- you will be able to update it after the deadline, if you get it in before the deadline. |
| | 9 | |
| | 10 | See also the [http://wiki.python.org/moin/SummerOfCode/2009 PSF Ideas page], which includes a subset of these ideas, and a lot of other Python-but-not-Tahoe ideas. |
| | 11 | |
| | 12 | Please read this page on the PSF wiki about [http://wiki.python.org/moin/SummerOfCode/Expectations what will be expected of you]. |
| | 13 | |
| | 14 | = Ideas = |
| | 15 | ''What could a smart student do in one summer, if they didn't need to worry about getting a summer job to pay the bills?'' |
| | 16 | |
| | 17 | == Server Selection == |
| | 18 | ''Which servers are connected to your client, and which of them have which shares of your files?'' |
| | 19 | * Dynamically migrate shares to maintain file health. |
| | 20 | * Use Zeroconf or similar so nodes can find each other on a local network to enable quick local share migration. |
| | 21 | * Deal with unreliable nodes and connections in general, getting away from allmydata's assumption that the grid is a big collection of reliable machines in a colo under a single administrative jurisdiction |
| | 22 | * Abstract out the server selection part of Tahoe so that the projects in this category of "grid membership and server selection" can be mostly independent of the rest of Tahoe. See also [http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html#2009-02-06 this note about standardization of LAFS]. |
| | 23 | * Write a GUI to visualize and manipulate the set of servers connected and the set holding shares of files. |
| | 24 | |
| | 25 | == Networking Improvements == |
| | 26 | * Dealing with NAT, ideally making it as easy to ignore as possible (taking advantage of upnp-igd and Zeroconf NAT-PMP). |
| | 27 | * 'tahoe sync'. The proposed #601 bidirectional sync option would be great for using tahoe as we would with dropbox (http://www.getdropbox.com/). Like the latter, the user could have a daemon which keeps things in sync in pollings within a one or two seconds schedule (maybe using inotify for uploads). In practical terms an user could have many machines pointing to the same tahoe:dir, each machine mapping this resource to a local directory, and all these machines could then have their local copies in sync, via tahoe:dir. I think this is good when someone has many machines and alternates use between them, like a notebook, a home desktop and an office desktop, for instance. |
| | 28 | * Optimize upload/download transfer speed. |
| | 29 | * Implement storage server protocol over HTTP. #510 |
| | 30 | |
| | 31 | == Free The Windows Client == |
| | 32 | * Make the [http://allmydata.org/trac/tahoe-w32-client Windows client] use only free open-source software. |
| | 33 | |
| | 34 | == Deep Security Issues == |
| | 35 | ''Want to implement strong security features which advance the state of the art? It isn't easy! To tackle these you'll need to think carefully and to integrate security and usability, which are two halves of the same coin. But you'll have excellent mentors and the support of a wide community of interested security hackers.'' |
| | 36 | |
| | 37 | * Fix Same-Origin-Policy design issue. Web content from different authors can interact in unintended ways in the victims browser, such as Javascript iterating over open windows, or peeking at a referrer header. Before this project is undertaken, the problem description and proposed solutions need careful design review and consideration! The solutions should be considered prototypes and should be backwards compatible with the Tahoe network. tickets: #615 (Can JavaScript loaded from Tahoe access all your content which is loaded from Tahoe?) |
| | 38 | * Domain Mangling approaches: |
| | 39 | * HTTP proxy approach |
| | 40 | * Special scheme handling in browser add-ons |
| | 41 | * [http://code.google.com/p/google-caja CAJA] approach: Require all Javascript to pass the CAJA verifier in the Tahoe web frontend, then create an interface to the tahoe webapi which matches the intended capability semantics. |
| | 42 | * Tahoe Cryptography: |
| | 43 | * Help us author a paper proving the security of the "Semi-Private Keys" construction from http://allmydata.org/~zooko/lafs.pdf . Implement small, secure Tahoe capabilities based on Semi-Private Keys. #217 |
| | 44 | |
| | 45 | == Building Things On Top Of Tahoe == |
| | 46 | * an interactive tree browser web frontend in !JavaScript (Nathan has written most of one -- what can it grow into?) |
| | 47 | * a blog-like web app (perhaps addressing tiddly wishlist items) |
| | 48 | * Extend and improve the {{{tiddly_on_tahoe}}} implementation. |
| | 49 | * Retarget the [http://tiddlywiki.org/wiki/TiddlyWeb TiddlyWeb] to use Tahoe as its backend storage. |
| | 50 | * Port another light-weight open source web app to Tahoe+javascript (calendar, photo album, [https://bespin.mozilla.com Bespin]). |
| | 51 | |
| | 52 | == Connecting Tahoe To Other Things == |
| | 53 | * Help with the C client library [http://allmydata.org/trac/libtahoeclient_webapi libtahoeclient_webapi]. |
| | 54 | * Explore running a Tahoe grid over [https://torproject.org Tor] or [https://i2p2.de I2P] to provide anonymity to servers and/or clients. |
| | 55 | * Integrate Tahoe with the operating system kernel through FUSE. [source:contrib/fuse source code], [http://allmydata.org/pipermail/tahoe-dev/2008-November/000885.html mailing list thread], ticket: #36 (FUSE integration), #621 (Make automated fuse tests run against blackmatch.). |
| | 56 | * Integrate a distributed revision control tool such as {{{darcs}}}, {{{git}}}, {{{bzr}}}, {{{mercurial}}} or {{{monotone}}} with Tahoe so that there is a single distributed, secure revision control repository stored on a Tahoe grid. ticket #663 |
| | 57 | |
| | 58 | = Mentors = |
| | 59 | ''Who is willing to spend about five hours a week (according to Google) helping a student figure out how to do it right?'' |
| | 60 | [[br]] |
| | 61 | * [http://ndurner.de Nils Durner] (C/C++, Windows) |
| | 62 | * Brian Warner (warner-tahoe at allmydata dot com) (core coding, Python/Twisted/Foolscap) |
| | 63 | * [http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html Zooko O'Whielacronx] (core coding, Python/C/C++/JavaScript, cryptography) |
| | 64 | * [http://www.randombit.net Jack Lloyd] (C/C++/Python, cryptography) |
| | 65 | * Nathan Wilcox [mailto:nejucomo@gmail.com email address]: nejucomo (at) gmail.com (frontends Python/JavaScript/C/C++, security) |
| | 66 | |
| | 67 | = Tasks Too Small To Be A Whole Project Unto Themselves = |
| | 68 | |
| | 69 | ''But they could perhaps be the starting point of a summer project -- i.e. get into the code by fixing this bug and then build a solid addition to this part of the system.'' |
| | 70 | |
| | 71 | * sshfs working properly in linux boxes. Yeah, my Fedora 9 isn't ok with trunk revision, it keeps showing me the same first level directories in any level :) |
| | 72 | * Shell friendly errors. When cli (the shell command tool) is failing, it would be good, for shell users, to have a nicer output in text format, not html/css. The latter could be kept for webgui errors only. ticket: #646 (CLI should report webapi errors better) |
