[tahoe-dev] Fwd: LAFS performance

[Nikita Borisov]

No, it's not the only reason, and not even the main one.  I think the
main issue is that the secure filesystem semantics do not match well
with the application I have in mind.

The basic structure we're thinking of for our decentralized social
networking is to have essentially objects with "annotations"
(objects).  Then, for example, a Facebook profile would be an object
that describes the owner, with annotations corresponding to wall
posts.  Each wall post could further be annotated by comments, and
possibly comments on comments, etc. etc.

The access control rules I'd like to have is that, for each object,
there are the standard read/write/verify capabilities, as in Tahoe,
but also an annotate capability, which allows you to add an
annotation.  This may be something that could be implemented with an
append capability, but you would also need to ensure some sort of
structural integrity; i.e., if an annotation is, say, a read
capability, you would not want someone to be able to append half a
capability; the annotation must be self-contained.

There are a few other things that make me reluctant to use Tahoe as a base.
* Tahoe does key management by capabilities; in our other work, we
have used attribute-based encryption to have a more structured way to
give people read (& possibly write) access, and I think it's a better
fit for social networks.  Or rather, I think the best design will
involve some mixture of ABE and ad-hoc capabilities used for access
control.
* Tahoe is designed for grid-based storage, whereas we want something
that is peer-to-peer.  We want to have millions of nodes with varying
degrees of availability.
* One of our eventual goals is privacy, so we want to ensure that the
cryptographic constructions and the lookup / storage algorithms are
designed to resist traffic analysis.

My current thought is to start with a P2P DHT implementation and build
on top of it, integrating some of the Tahoe concepts (i.e., some form
of cryptographic capabilities to control storage & updates).  It would
be great if we could use the Tahoe code base, since there's obviously
a lot of support behind it, but I think the modifications we'd need to
implement would be too drastic to make this worthwhile.

Of course, I'd love to hear any thoughts you have on this.  I Cc'ed my
collaborators on this project, please include them in any responses.

Thanks,
- Nikita

On Fri, Jul 16, 2010 at 3:31 PM, Chris Palmer <chris at noncombatant.org> wrote:
> Nikita, it sounds like the main/only? reason you tend to disprefer
> Tahoe-LAFS is performance. First, am I right about that? Second, what are
> your performance targets?
>
>



-- 
Nikita Borisov - http://hatswitch.org/~nikita/
Assistant Professor, Electrical and Computer Engineering
Tel: (217) 903-4401, Office: 460 CSL