[tahoe-dev] Tahoe-LAFS is widely misunderstood

[Greg Troxel]

"James A. Donald" <jamesd at echeque.com> writes:

> On 2011-02-02 11:04 AM, Chris Palmer wrote:
>
>> 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.
>
> Mismatch.  Browsing works, but manipulation has subtle
> differences.

So one can either understand the mismatches and consider if the VFS
layer needs to have the concept of capabilities (and perhaps
immutable/mutable file types), or reimplement an entirely new filesystem
interface.

I'm generally of the opinion that improving VFS for capability-type
filesystems is the better approach, but then I come from a research
group background.  I'm also used to BSD where changing the OS seems more
doable - I don't really understand why, but I run into a lot of thinking
in research projects about Linux that one can add modules but that
making significant permanent changes to the kernel isn't acceptable.

>> 2. There are clients and there are servers. There are no
>> gateways, introducers, WUI servers, helpers, et c.
>
> Most of these things turn up as a result of the need to
> pass capabilities around.  Clients and servers are only
> sufficient if your client already has its capabilities.

Presumably you are treating the furl to get to each server as a
capability, which it is.

In my usage, dir/file caps don't show up much at all on servers, just
clients.

> So far no one has proposed a capability system wherein
> capabilities are usefully and conveniently shared between
> several people, which is a serious flaw since capabilities
> are most useful when you want have interactions between
> several people, and administration and setup always requires
> passing some capabilities around.

And indeed, I scp config files around and kill/yank caps.

> You always wind up needing to pass capabilities around, and the
> methods for doing so always turn out to be surprising,
> cumbersome, and unexpected.  Typically you copy and paste a
> long incomprehensible text string from some place to another
> place.  No one has proposed a nice clean system for passing
> capabilities around, except in the vaguest and most general
> fashion.

Sharing capabilities is really something new in capability-based
filesystems.  Given the nature of tahoe caps (and I suspect in all
systems where they really are capabilities), one needs confidentiality
protection both in transport and at rest.

So (and I'm not saying this to try to tweak James), something like a
way to export a cap to a file and openpgp encrypt it to a recipient and
attach it to mail would be good.  Then the receipient's MUA can key off
the mime type and import it into the aliases file.

Of course, if there's some other transport encryption mechanism, that
can be used too.

As a start

  tahoe export-cap capfile path

  tahoe import-cap capfile new_alias

would reduce the problem to secure file transport.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110202/ac19514f/attachment.pgp>