[tahoe-dev] using Tahoe-LAFS when you only have one server (was: default values of K, H, N)

Zooko O'Whielacronx zooko at zooko.com
Sat Jan 15 06:09:46 UTC 2011

Thanks for your letter, Greg. I'm not going to *directly* respond to
your statement of your preferences about H, K, and N, but you touched
upon a related issue that I am very interested in:

On Wed, Jan 12, 2011 at 5:38 PM, Greg Troxel <gdt at ir.bbn.com> wrote:
>  3) non-redundant grid: user sets up minimal private grid, wtih
>  intention to store files, but no expectation of redundancy/reliability
>  (beyond one disk).  At first glance this seems silly, but it gets one
>  better confidentiality properties than NFS.
> I would argue that case 3 is odd, because given how tahoe works, almost
> everyone would want to set up multiple servers (or multiple server
> processes on multiple disks) to move to 4, or at least be wanting to
> move to 4.

This is how I used to think, too! But recently I've started to wonder
-- why should people who have only one server to work with consider
Tahoe-LAFS to be an ill-fitting tool for their system? In fact, if you
set (H, K, N) to (1, 1, 1) then Tahoe-LAFS is a *great* way to backup
your files without being vulnerable to loss of integrity or
confidentiality, even in the case that your server gets compromised.
You can also dynamically choose to share some of your files and
directories with certain friends, or even to publish some of them to
the world.

Compare using Tahoe-LAFS for this to, for example, using rsync or git
or duplicity to backup your files to your server. Tahoe-LAFS looks
better than those other tools for the use cases I envision.

So, given that you have one single server to work with, Tahoe-LAFS
with (H, K, N) = (1, 1, 1) seems to be a great tool for all of:
backup, file-sharing, and hosting. Interesting. Maybe we shouldn't let
people think that they need multiple servers in order to use




[1] http://insecure.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/blog.html

More information about the tahoe-dev mailing list