[tahoe-dev] Tahoe-LAFS v1.8 planning / Administrivia / Big Picture

Tue Jul 27 07:04:43 UTC 2010

Folks:

"I would not have made this so long except that I do not have the
leisure to make it shorter."

It's late here. I don't have time to write well-organized letters, but
I think it might be better for everyone to see an ill-organized letter
on this topic that to carry on without a letter, so here it is.

= Tahoe-LAFS v1.8 planning =

The current plan is make a 1.8β release six days from now, on Monday
2010-08-02. See The Roadmap [1]. Generally speaking, if a patch isn't
finished and ready for review by Saturday night (UTC-6) 2010-07-31
then I'll be inclined to put that patch into the "post 1.8" bucket. I
hope to do all of the "release chores" on Sunday so there's nothing
left to do but push the big red button on Monday. The release chores
include updating the wiki, writing the release announcement, writing
cover letters for the release announcement, etc. etc. [2]. Help is
welcome! I'm getting kind of tired of that job, but I don't want to
turn the job over to someone else because they might not do it exactly
the way that I like.

So what's going to go into 1.8?

== Brian's New Downloader (ticket #798) ==

A long-awaited rewrite of the downloader which will improve robustness
and probably also improve performance in many situations. Needs code
review with an eye to avoiding regressions vs. 1.7.1 including
performance regressions. Needs benchmarking to compare it to v1.7.1.

== "get rid of tahoe.exe launcher" (ticket #1074) ==

Let the tahoe cli run on Win64, make it possible to do non-ASCII
command-line arguments and outputs on Windows, remove a binary blob
from our build system and otherwise simplify the build system and
improve the tests thereof.

== update pycryptopp (pycryptopp tickets #18, #34, #37, #43, #44, #45) ==

See also this mailing list message [3].

== other bugfixes and usability improvements ==

See The Roadmap. And please help! Help needed. There are many tickets
on The Roadmap that desperately wish they could be fixed in v1.8 and
they need a loving hacker to help them get there.

In addition to the above, I'm hoping that each of the Google Summer of
Code students will try to land some patches for v1.8. That's because
it would be awesome if they got code committed for v1.8, and anyway
the best way to get patches committed into v1.9 is to try to get your
patches committed into v1.8 and fail. ;-)

== Kevan Carstensen's MDMF (ticket #393) ==

Kevan has done a ton of deep work on this (see the ticket history and
attached patches), but I don't know if any of it is ready to be
reviewed for committing to trunk. Kevan and his Mentor, Brian, should
probably think about whether there is anything likely to be ready by
Saturday and also whether there are any forward-compatibility issues
such that we should commit some changes to v1.8 just so that v1.8 will
interoperate better with the eventual v1.9 that has the complete set
of #393 patches.

== Faruq Sarker's Decentralized Introduction (ticket #68) ==

Faruq and his Mentor (me) should see if he can get the first part of
#68 committed this week. See also mailing list message [4].

== Yu Xue's 100 Year Cryptography ==

Per this mailing list discussion [5], I want Yu Xue to work on getting
a combined cipher into Tahoe-LAFS as soon as possible, and he is
willing to do that. I haven't heard from his Mentor, Jack Lloyd about
it yet. The next steps are:
1. Define some way to indicate in the cap itself that it is an
"XSalsa20⊕AES-128" cap which is just like the Tahoe-LAFS v1.7.1 cap
except that it is encrypted with XSalsa20⊕AES-128 instead of with
AES-256.
2. Implement a combined XSalsa20⊕AES-128 mode in a patch for pycryptopp.
3. Write unit tests for it like the analogous unit tests for AES which
are currently in pycryptopp:
http://tahoe-lafs.org/trac/pycryptopp/browser/trunk/pycryptopp/test/test_aes.py?rev=20100601041454-92b7f-aea971430644c5779d0abd128ee2ae85d1823919
4. Write "quick start-up self-tests" for XSalsa20⊕AES-128 analogous to
these "quick start-up self-tests" for AES-256:
http://tahoe-lafs.org/trac/pycryptopp/changeset/20091030222709-92b7f-49fea5a4bab83f10bd10fc2236ead238615ddcf8/trunk

== Josip Lisec's Tahoe-LAFS-hosted Music Player App ==

I don't know. Josip: is there anything that would need to be added or
not-added to Tahoe-LAFS v1.8 to facilitate your music player app? How
is it going, anyway?

= Administrivia =

The servers that run the web site, trac, darcs repositories, mailing
lists, etc. are sometimes unavailable. Suspicion currently falls on
Peter's router at The Undisclosed Location. Brian wants to move the
servers to a linode on which Brian has root and Zooko hasn't. Zooko
feels defensive and polarized about the prospect of giving up control
of his carefully configured tools. A company who I don't know if they
want to be named has offered to donate a few servers for our use. Lots
of options; it'll all work out somehow. I personally hope that we can
leave well enough alone until after 1.8β and that Peter's router is in
a good mood this coming weekend.

In other news some people want to donate money to Tahoe-LAFS. That is
very nice of them! That makes us feel loved. And we could use the
money for stuff like buying a new router for Peter's Undisclosed
Location. (If that turns out to be the problem.) Unfortunately Paypal
won't let people donate to us until we prove to them that we're a
non-profit. Peter is working on paperwork so that we can get paid by
Paypal, by the Google Open Source Programs Office (for GSoC), and by
Flattr users. That last thing is deeply cool (remember Mojo?) and I
will write a separate letter about it as soon as it comes to fruition.

Also, I applied to the Software Freedom Conservancy [6] for Tahoe-LAFS
to be a Member Project. The Conservancy would facilitate paperwork of
the aforementioned kind (accepting donations, filling out tax forms,
etc.) as well as helping with software licensing, project governance
(who's in charge here anyway?) and so on. They appear to have a good
habit of helping their projects implement the policies that the
project already chose instead of imposing their policies on the
project. There is a potential sticking point—they will probably have
to ponder deeply what they think about the Transitive Grace Period
Public Licence [7]. I'm hoping that they conclude that they can make
us a member project without requiring us to change our licensing, even
if they have reservations about the TGPPL. (I would be extremely
reluctant to stop offering Tahoe-LAFS code under the TGPPL. I think
the TGPPL is a beautiful idea, if I do say so myself.)

= Big Picture Stuff =

What do we want out of Tahoe-LAFS for the rest of 2010 and for 2011?
Oh shoot it is way too late to go into this now. Let me know what
*you* want out of Tahoe-LAFS for the rest of 2010 and for 2011! :-)

Regards,

Zooko

[1] http://tahoe-lafs.org/trac/tahoe-lafs/roadmap
[2] http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/how_to_make_a_tahoe-lafs_release.txt
[3] http://tahoe-lafs.org/pipermail/tahoe-dev/2010-July/004794.html
[4] http://tahoe-lafs.org/pipermail/tahoe-dev/2010-July/004817.html
[5] http://tahoe-lafs.org/pipermail/tahoe-dev/2010-July/004712.html
[6] http://conservancy.softwarefreedom.org/
[7] http://tahoe-lafs.org/~zooko/tgppl.pdf

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/393# mutable: implement MDMF
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/798# improve
random-access download to retrieve/decrypt less data
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1074# get rid of tahoe.exe launcher

http://tahoe-lafs.org/trac/pycryptopp/ticket/18# AES-CTR: easy way to
modify the counter for random-access decryption
http://tahoe-lafs.org/trac/pycryptopp/ticket/34# Segmentation Fault in
function X86_SHA256_HashBlocks
http://tahoe-lafs.org/trac/pycryptopp/ticket/37# Win64 and MSVC9
compilation fixes
http://tahoe-lafs.org/trac/pycryptopp/ticket/43# add a quick start-up
self test for SHA-256
http://tahoe-lafs.org/trac/pycryptopp/ticket/44# test what happens if
another Python module loads Crypto++ dynamic link library
http://tahoe-lafs.org/trac/pycryptopp/ticket/45# upgrade to latest
Crypto++ with SHA-256 bugfixes