Tahoe-LAFS

Tahoe-LAFS is a distributed filesystem which provides redundancy and security for files.

FAQs

Technical documentation on tahoe can be found at its website. However, for the prospective user, here's a simple explanation in Q&A format:

What does it do?

You set up a node with a few hundred gigs of free space and connect it to the tahoe grid. Then, you put files in it. It encrypts each file and puts part of it on ten of the nodes on the grid in such a way as to be able to recover the entire file even if up to 7 of the nodes are unavailable.

But what if I don't want people seeing my files?

They're encrypted, remember? Each file has an automatically generated key which also tells where the file is located. You can share this "filecap" with anyone else you'd like to see the file.

So the nodes aren't trusted?

No. Files stored on them are encrypted, signed, split into pieces, and distributed among the nodes. The only way to get the file back without the filecap is by finding the storage index, retrieving the pieces from the nodes, breaking the encryption, and reassembling the pieces. This is designed to be difficult.

And all these nodes are hooked together?

No. Groups of users set up grids, often arranged by geographical location for improved bandwidth and latency.

How do I access files?

When a file is uploaded (using tahoe put or tahoe cp), tahoe gives you a filecap. A filecap looks something like this:

URI:CHK:7fdtkb3smrcczbduzkg6nxex44:rvg2fwo7poziydflo5jmjmbejczunqe5emhcisxx6uefosw4in3q:3:10:102015

This string includes the location, or storage index, of the file (in this case 2zmhsnky3x34wz2c523vzery6e, which is cryptographically encoded), the keys used to decrypt the file and verify its signature, the file's size (in human-readable format), in this case just over 102kB, and the encoding of the file, in this case 3-of-10. 3-of-10 encoding means that the file is stored across 10 nodes and that at least 3 of these are required to recover the file.

The filecap does NOT include the name of the file or its type. Types may be found using the unix file utility. To retrieve the file, use tahoe get [filecap] [filename]. This will cause tahoe to get the filecap's shares from the nodes, reassemble them, decrypt them, verify the integrity of the file, and write it to filename.

How do I delete files?

You can't. The nodes are not trusted and therefore cannot be relied upon to remove the file's shares when asked. To render a file inaccessible, destroy all copies of the filecap. After 31 days, the file's lease will expire and its shares will be automatically garbage collected, or deleted, by the nodes.

Wait, files expire? But I thought...

Don't panic. To stop a file from being deleted after 1 month, simply renew its lease. The recommended way of doing this is setting up an alias using tahoe create-alias tahoe, adding the filecap to the alias, and setting up a weekly cronjob to run tahoe deep-check --renew tahoe. This will renew the leases on all the files in the alias, which is similar to a directory.

Directory?

Yeah, you can have directories. They are implemented basically as lists of filecaps with associated filenames. They are referenced using dircaps, which come in read-write and write-only forms. As a result of storing the filecaps of the contained files inside the dircap's shares (a dircap, remeber, is treated similarly to a file with regards to storage), all files may be read as a result of knowing only the dircap. This does not, however, work in reverse. If you give another user the filecap of a file (or the dircap of a directory) in a directory, they cannot find the names or contents of the other files in the directory containing the filecap.

How come there are no mountable filesystem frontends?

There are; they just aren't built-in. Tahoe's high latency makes it rather unwieldy for use as part of a conventional filesystem. It is recommended that you use the web and CLI interfaces to manage files stored in tahoe.