[tahoe-dev] Accounting, 2010 edition

[Greg Troxel]

"Zooko O'Whielacronx" <zooko at zooko.com> writes:

> On Wed, Dec 22, 2010 at 6:34 AM, Greg Troxel <gdt at ir.bbn.com> wrote:
>>
>> I don't debate your point, but will observe that if you are right it
>> needs to be reinvented as a first-class project/protocol/etc. rather than
>> something tacked on to tahoe.
>
> Why do you say that? I don't think I agree.

"Trust management" is about knowing whether you believe the binding of
keys to actors, and what you think about those actors.  Right now we
have two approaches, the PKI mess (in implementation and social issues;
the standards seem ok) and the not-well-used-maybe-mess-too-hard of
OpenPGP.  The challenge is to figure out an architecture that is usable
in practice given the UI, social and legal problems.  Distributed
filesystems aren't particularly special -- the problem is of general
interest.  See the monkeysphere project for an example.  For reasons of
abstraction and reusability in the open source world, things that can
reasonably be separated shoudl be separated.

> However, that's sort of a philosophical argument. These sorts of
> discussions are often more productive when they focus on specifics.

Agreed.

> I really like how Brian start writing down specifics about the user
> experience:
>
> http://tahoe-lafs.org/pipermail/tahoe-dev/2010-December/005763.html
>
> (This is something that I've learned from Brian: that writing the docs
> first, and then the unit tests second, and then the code third, is a
> great way to launch the development of new functionality.)
>
> Perhaps we could ask people who want to influence the design of this
> new feature to publish their ideas in the form of end-user
> instructions docs, specification docs (in .rst form, please -- just
> copy some existing doc in order to get the formatting), or unit tests.
> :-)

On my todo list..

One point made clearly by Brian's examples is that the trust
management/PKI issues are not the key barrier to getting things working.

I'd like to suggest an expanded use case.  Brian's example is about a
server operator giving someone else permission to store shares.  That's
certainly the right primitive.  Consider a friendnet of 10 nodes, with a
leader (who talked people into joining).  Probably most people in the
grid would like to be able to load an acl that the leader publishes,
to minimize their effort.

If OpenPGP keys are used somehow, I think we also need to separate "key
is signed by authorized key" with "key has been delegated permission to
store data by authorized key".

Another relevant piece of work that already has been done is SPKI.  I
had forgotten about it but it's directly relevant to the storage
delegation problem.

  http://en.wikipedia.org/wiki/Simple_public_key_infrastructure
  http://world.std.com/~cme/html/spki.htlm

> By the way, does anyone here actually use GPG? I certainly don't,
> although occasionally I interact with build systems automation that
> uses gpg to sign debian packages, and very rarely (once every few
> years) I receive a gpg-encrypted email from a long-lost friend.

Yes, I use it routinely, for signing and verifying mail, for
communicating with some people, and for receiving vulnerability
pre-announcemnts from CERT as part of another project.  I am surprised
that it's not in wider use in the tahoe-lafs community -- why do people
who value the principle of least privilege and hide the plaintext of
their bits from fileservers think there's no reason to hide the
plaintext of person-person communications from intermediate MTAs?
-------------- 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/20101222/c83a7d75/attachment.pgp>