[tahoe-dev] Tahoe-LAFS is widely misunderstood

[Brian Warner]

On 2/1/11 5:36 PM, Greg Troxel wrote:
> 
> After looking at your Octavio page, I think your simplifications
> relative to tahoe can be divided into several groups
> 
>   no erasure coding; just replication. This gives up some performance,
>   but seems like a reasonable tradeoff for many.

Note that it also gives up reliability: according to my math, 5-of-10 is
much much better than 1-of-2 when the servers are good (say >90%
availability). (on the other hand, 1-of-2 is much better when the
servers are bad). But yeah, it makes repair trivial, and is easier to
explain to users.

>   Removal of CLI and WUI, and using only FUSE. This is the aspeect I'm
>   most in favor of.

My problem with FUSE as the primary entry point is that it loses the
whole least-authority model. The POSIX filesystem APIs don't expose
things like retrieving a dircap for the subdirectory that you want to
share with a friend, so the easiest thing to do is to share your whole
rootcap with somebody, the equivalent of sharing passwords from the
bad-old-days. It also doesn't let you write programs that are restricted
to interacting with just a subset of your filesystem, so all the usual
Confused Deputy vulnerabilities are still around.

>   Removal of introducer; presumably each client has to be configured
>   with all servers; I'm not sure this is a win.

Yeah, I think we need something easier than manual configuration
(especially if you want to maintain proper security between the nodes,
which means you need to copy some cryptographic material from one box to
another). I'm not convinced that Tahoe's Introducer is the best approach
either, particularly with respect to grid-membership management: I'm
looking forward to experimenting with Invitations and similar
create-or-join-a-grid approaches.

cheers,
 -Brian