[tahoe-dev] Tahoe-LAFS is widely misunderstood (was: odd comment about #shares and confidentiality)

[Chris Palmer]

The communication problem stems from two basic causes:

1. Incredible complexity of design and implementation and feature/option set

2. Unwillingness, quite understandable, to aggressively simplify the
description of Tahoe-LAFS' properties

For (1), we have a fundamental philosophical difference. There is a spectrum
of geek complexity-love. If I can characterize it religiously :) it'd be
like this:

    EEmacs/vim users    nvi/mg users    cat users ("ed is bloatware")

Tahoe-LAFS represents the Emacs-with-tons-of-plugins end of the spectrum.
I'm an nvi/mg fan. The suckless.org people represent the cat contingent.
Emacs, vim, Tahoe-LAFS, et c. are just plain hard to explain because there
is so much going on. "Oh sure, you can mount it like a normal filesystem.
Just use the FUSE module that implements SFTP to talk to your gateway which
in turn... Oh well there are some semantic impedance mismatches... Well of
course you'll need the FUSE kernel module, didn't I mention that? Have you
tried the WUI?  ... No, the WUI, not the gateway..."

I wish you guys would take a hard turn toward the nvi mentality. Then you'd
have less to explain, and people would have less to understand. (I don't
advocate going into cat territory.)

For (2), you can win here by shedding precision but carefully maintaining
accuracy. For example, rather than going into erasure coding, just say
"Tahoe-LAFS stores your data on many servers in the cloud. Tahoe-LAFS stores
your data redundantly, so that your data will still be available even if a
portion of the servers are unavailable." It's perfectly accurate, but not
precise. Over-precision can impede understanding, and I see that with some
of the examples Zooko mentioned. Normal people just get baffled, and geeks
get confused in ever more sophisticated ways ("I know about AONTs! This is
obviously that!" No...).

Unfortunately, Octavia remains a thought experiment, but I consciously made
the design have fewer new concepts and moving parts, in an attempt to head
off exactly the problems you are having. Relevant design points:

1. It's a FUSE program. The end. You mount a filesystem, and then browse
around. The UI is whatever your current filesystem UI is.

2. There are clients and there are servers. There are no gateways,
introducers, WUI servers, helpers, et c.

3. Inodes/caps are not exposed in normal usage. You need one to mount a
directory, and you should keep a backup copy of your root descriptor for
backup, but you can and should treat them as opaque (though they are UTF-8
text files).

4. The truth of redundancy is the same as the low-precision description ---
no erasure coding and no configuration-time tradeoffs or mathematical
decisions. I described the costs and benefits of this design in a previous
email.

Finally, complexity reduces security.


-- 
http://noncombatant.org/