]> git.rkrishnan.org Git - tahoe-lafs/tahoe-lafs.git/commit
client.py: rename "server key" to "node key", use old name if present
authorBrian Warner <warner@lothar.com>
Mon, 11 Jun 2012 01:14:55 +0000 (18:14 -0700)
committerBrian Warner <warner@lothar.com>
Mon, 11 Jun 2012 01:14:55 +0000 (18:14 -0700)
commitbf416af49ed74057c84a05a65b12cd8cfac924f4
tree434ffe29bae8a80e2f95b532a46cd53f9e8f459e
parent26d3869076f02351a821a3e4dd7049fd234f6bb6
client.py: rename "server key" to "node key", use old name if present

This prepares for invitation-based reciprocal-permission Accounting. In
the scheme I'm developing, nodes publish "I accept shares from Y"
messages, which are assembled into a graph, and server will accept
shares from any client node reachable in this graph. For this to work,
the serverX->clientY edge must be connectable to the serverY->clientZ
edge, which means "clientY" and "serverY" must be connected. If clientY
and serverY are two distinct keys, they must be cross-signed. Life is
easier if there's just one key "Y", rather than distinct client- and
server- keys. Calling this one key "server.privkey" would be confusing.
"node.privkey" and "node.pubkey" makes more sense.

One-server-per-node is a pretty easy restriction. Originally I was
thinking that the client.key should be provided in each webapi call,
just like a filecap is, making a single node useable by multiple users
(Accounting principals), and not providing any ambient storage
authority. But I've been unable to think of a comfortable WUI for
that (at least without requiring javascript), nor a friendly way to
transfer account authority (e.g. writecaps that include storage
authority). So I'm more willing to have one-client-per-node these days.

(and note that this rename doesn't seriously preclude
many-clients-per-node or zero-clients-per-node anyways, it just makes
one-client-per-node less awkward)
src/allmydata/client.py