[tahoe-dev] Tahoe visibly solving a problem with capabilities? (was: Re:Demonstration and engagement (was: If not God))

[Jed Donnelley]

On 4/9/2008 1:43 PM, Jonathan S. Shapiro wrote:
> On Wed, 2008-04-09 at 13:20 -0700, Jed Donnelley wrote:
>> On 4/9/2008 12:39 PM, Jonathan S. Shapiro wrote:
...
>> Why don't you consider Tahoe "production ready"?
> 
> Tahoe may well be production ready. It doesn't address a
> user-perceptible need by virtue of being a capability system.
> 
> My point, I think is that (a) we need a system that works, and (b) we
> need a system that visibly solves a problem.

While it's a bit early in my evaluation to be defending Tahoe,
let me make my argument that Tahoe does (at least attempt to)
visibly solve a problem by virtue of being a capability system,
to see what others think.

The argument is a bit complicated by the fact that Tahoe is solving
two problems:

1.  Backup, and
2.  Sharing

It's the sharing aspect that I argue is a user-perceptible
need solved by virtue of being a capability system in a visible
way.  Feel free to skip the backup section to begin with if you'd
like to focus on the aspect of meeting a "user-perceptible
need by virtue of being a capability system." -> 2. Sharing below.

My main interest in Tahoe is that for me it does seem to offer
at least the possibility of visibly solving these two problems
that I'm facing.  If my test and eval of Tahoe can also
help forward the capability message, then I can kill at least
two birds with one stone (backup and promoting capabilities)
and perhaps the sharing "bird" if Tahoe becomes more widespread
(or gets integrated with Waterken or ...).

1.  Backup:

My visible backup problem is that I have some 450GB of
data at home (~100GB pictures, ~150GB music, ~150GB videos
with other another 50GB of Jed's cap-talk comments ;-) )
that I need to backup to some place outside my home,
to be safe from fires and the like (perhaps a modest
home file system compared to others?).

To this point I've been periodically (every few months)
sending or carrying a disk with a full backup to a
friend's home or to work.  I then keep incremental
backups at home.

Needless to say this isn't very effective.  If I
lose what is at home (e.g. in a fire) I loose some
months of data.  Also it's awkward sending or carrying
such disks, I must encrypt the disks, the locations
aren't the best, and there is only one such location.

I've used network backup services before (e.g. at
work where I didn't have to pay for it), but I haven't
considered them cost effective.  I don't want to
cast aspersions on the Allmydata service, because I
really don't know whether it is better or not at this
point.

 From my perspective the configuration that they
refer to in the Tahoe documentation as "friendnet":

(e.g. from: http://allmydata.org/trac/tahoe/wiki/UseCases

) seems a win-win to me, if it works well.  I can easily
put together a group of 10 or so friends with large disk
systems.  We're all on the internet.  Instead of shipping
or carrying a disk to a friend's now and then we all agree
to use such disks for each other and have Tahoe move the
data around to reliably keep our data backed up (e.g.
it's 3 or 10 or whatever - I'll have to see about that).

I won't belabor the backup aspect of things here since
that isn't our focus.


2.  Sharing

Now to the issue of it visibly solving a problem *by
virtue of being a capability system.*

In addition to having all this data I often find myself
wanting to share it.  For example, I might want to share
the pictures I took at the Horton development meeting at
HP with cap-talk or perhaps the pictures I took of the
HP conference room with cap-conf.

Currently what I generally do is to post what I want to
share on the Web and give out pointers, e.g.:

http://www.webstart.com/projects/delegating-responsibility/HP-2006-12-01/
or
http://www.webstart.com/projects/cap-conf/

and send such URLs to people.  Of course this has many
problems, including the work to do the posting and the
fact that the posts have no access control.  Sure I
know about .htaccess yadayada.  Too much work to
configure and to use.

Enter Tahoe.  My imagination with Tahoe (again, it's early)
is that for my data stored in a Tahoe file system I
can just have it produce a capability to any file or directory
and send it to anybody I want - e.g. in an encrypted email.

They even have the access control aspects close to right:

http://allmydata.org/source/tahoe/trunk/docs/about.html
_________
A user who has read-write access to a mutable file
or directory can give another user read-write access
to that file or directory, or read-only access to
that file or directory. A user who has read-only
access to a file or directory can give another user
read-only access to it.

When linking a file or directory into a parent
directory, you can use a read-write link or a
read-only link. If you use a read-write link,
then anyone who has read-write access to the
parent directory can gain read-write access
to the child, and anyone who has read-only
access to the parent directory can gain
read-only access to the child. If you use
a read-only link, then anyone who has either
read-write or read-only access to the parent
directory can gain read-only access to the child.
_________

I say "close" because they haven't distinguished
between read-only and "deep read-only".  For Tahoe
it seems that (currently) the only read-only is
"deep read-only".  Because of that I believe that
I can't send you a read-only capability to a directory
that contains some read-write files that I'd like
to work on with you (there are other problems).

Still, until I get into it deeper I'm not going
to start quibbling (though I realize I just did in
response to your comment Jonathan).  We'll see
how it goes.  I recognize that of course anybody
I'm going to send such a capability to must have
a version of Tahoe running.  That will be an early
problem, but could be solved if Tahoe or something
like it "sell"s or if it can be integrated into
something that's available on more systems.

For me a particular appeal is that Tahoe seems to
solve this user visible sharing problem in essentially
the same way the Elephant storage system (1965 - 1995)
did (modulo that read-only vs. deep read-only business),
which I know was effective for users.  The fact that
it seems to add capabilities as data that I can
send in messages I regard as a plus.

The main issue for this email is my argument
that Tahoe at least has the potential to be solving
an important problem with a production system that
visibly uses capabilities in an essential way.

If it doesn't at least have that potential then
I'm wasting my time.  What do others think?

--Jed  http://www.webstart.com/jed/