Roadmaps Announced

David-Sarah announced the roadmaps for 1.9.2, 1.10.0 and 1.11.0.

1.9.2 will be a bugfix release. Its focus will be fixing regressions in mutable file support. Although developers resolved several of the bugs, further testing and review is necessary. 1.9.2 will be released from the darcs branch and will hopefully release at the end of May.

1.10.0 will be released via git. It will include Brian Warner's introducer improvements, including Ed25519-signed announcements. This will allow for multiple introducers and accounting. Also this release will see a "move" operation added to the web interface.

1.11.0's features have not been set in stone. However, they may include

• improvements to share placement to meet the servers-of-happiness criterion in more cases;
• extending servers-of-happiness to mutable files;
• some form of accounting;
• a read-only mode for Tahoe gateways;
• support for AES+XSalsa encryption, which would remain secure even if a flaw were discovered in either one of its constituent ciphers, including if there were a timing attack against the AES implementation;
• a 'tahoe mount' command that simplifies mounting a Tahoe filesystem via sshfs;
• merging the S3 backend support (and possibly other cloud service
• support) developed by Least Authority Enterprises;
• extending the drop-upload feature to Windows;
• merging the patches for Tor and I2P into the main release.

Redundant Array of Independent Clouds

Diego "sickness" Righi created a Redundant Array of Independent Clouds (RAIC). Cloud services while simple and attractive, experience three major issues. One, what happens if they fail and lose your files? Two, how do they prevent someone from gaining unauthorized access to your files? Three, what recourse do you have to your files if the service stops providing access (i.e. bankrupt, government shutdown). Through the use of Tahoe-LAFS, sickness is able to overcome these issues with three large benefits:

"1) My files are encrypted BEFORE being stored on my local disk and BEFORE being sent to the remote cloud provider, so whoever stoles this local workstation or manages to hack the remote cloud servers will not get access to my files 2) I can configure a zfec factor of 3:6 so in the event that 3 cloud providers should lose my files, or close and go out of business, I'll still be able of recover my files from the remaining 3 cloud providers that still work, what we have here is effectively a RAIC (redundant array of inexpensive clouds) :) 3) I could instead configure a zfec factor of 5:6 so I can maximize the space that I have striping across multiple free "few Gb" accounts like in a RAID5 pool of disks, effectively building a cheap and inexpensive big cloud disk, and still being able to recover my files in the event that one cloud provider fails." [0]

Least Authority Enterprise (LAE) is also working on RAIC through the use of cloud services which support an HTTP API. Sickness' implementation works instead by letting the cloud service client sync the directory in which Tahoe-LAFS stores the encrypted shares.

Sickness's approach has the advantage that it can sync with services which do not provide an API. However, this implementation depends on the correctness and availability of the syncing implementation. For example, if the Dropbox process dies, the shares are still fine on your local disk, but they are no longer being synched.

End of Support for Python 2.4

Tahoe-LAFS is at long last going to stop being backwards-compatible with Python 2.4. The plan is for the Tahoe-LAFS v1.9.2 release to be the last one that works with Python 2.4, and starting with the v1.10 release it will require Python 2.5, 2.6, or 2.7.

Authenticated Data Structures

Andrew Miller wrote a dense technical post about a concept called "Authenticated Data Structures", which unifies concepts from Bitcoin, proofs-of-work, and Tahoe-LAFS append-only files or add-only sets. At press time nobody else had understood it well enough to write a reply.

New User Documentation

Michael Rogers suggested a few user-experience and documentation issues experienced by a new user trying to install Tahoe-LAFS for the first time. David-Sarah responded by creating trac tickets to track progress on Michael's issues. There was a pony involved.

Use the Source

A new user named Han Zheng asked how to get started studying Tahoe-LAFS's source code. Zooko suggested starting by reading the server implementation. Since servers aren't allowed to know anything about the plaintext in Tahoe-LAFS, they are dumber and easier to learn than the other components.