[tahoe-dev] Accounting, 2010 edition

[Brian Warner]

On 12/20/10 7:53 AM, Greg Troxel wrote:
> 
> As a concrete situation, it would be nice to target a friendnet grid
> where we aren't particularly worried about malicious attempts to
> cheat, but we do want to be able to observe how much space is person
> is taking up.
> 
> That means we can leave out of increment 1:
> 
>   distribution of keys (can be manual)
>   how to prove alice really is providing 3GB to the grid

Absolutely. In fact, the first phase will just automatically create an
"account" for any key that shows up, without even pushing the idea that
the server should reject strangers. I guess the 1.5th phase is to
provide manual keying and start rejecting newcomers.

> It's probably worth figuring out how to deal with keying, since it
> seems like there is
> 
>   x509,  openpgp,  roll our own

Yeah, I hear what you're saying, but I'm leaning away from both x509 and
openpgp because I think they're a lot more complex than we need. All we
really want is a signing/verifying keypair, and a way to express the
verifying pubkey as an account identifier: no "Subject Names", no
chained signatures, no need for encryption. PGP's web-of-trust scheme
feels off, since we're talking about making "store data for this client
or not" decisions, rather than "I think key X is really owned by person
Y" decisions. There are similarities, but I'd worry that we'd be trying
to mold Tahoe's Accounting needs into the framework offered by one of
those keying schemes, rather than the other way around. Plus, I want to
avoid adding new dependencies (like libgcrypt bindings, or some sort of
x509 thing), or dragging too much new code into tahoe.

But take a look at the proposal and see what you think.. maybe there's
some easy-enough way to leverage an existing format.

cheers,
 -Brian