[tahoe-dev] accounting and ambient client authority

[Brian Warner]

I was thinking a bit about Accounting this morning, as I've recently
been reviewing my notes and code branches from the last few years in
preparation for another development push.

Most of our designs concentrate "storage authority" (the right to
consume space on somebody else's server) in a private key, a short
string that represents power just like a filecap represents the power.
Some sort of interaction happens between a user and the operator of a
server (maybe one pays the other, or they trade space on each other's
machines, etc), and the user winds up with a "storagecap", and then they
somehow give the storagecap to their client node so it can upload shares
to that server.

One sticking point I keep running into is how exactly the storagecap is
given to the node. The easiest thing is to write it into the tahoe.cfg
file (or more likely a file in NODEDIR/private/ , since tahoe.cfg is not
currently protected as much as file in private/ are). This is easy
because then every upload by this client will use that storage
authority. It makes some of the my-space-for-yours trades easier to
automate, and would let us keep the existing webapi methods ("upload"
just works).

But it feels weird, because it'd be a node-wide ambient authority. This
becomes apparent if you consider a public gateway (like the old
allmydata one, or the public testgrid's gateway), and how multiple
people (each with their own storagecap) could use it. It also reminds me
of the long-dead node-wide "private" directory and the CSRF attack that
it enabled, when I unwisely made a webapi URL named "/private" which
mapped to some preconfigured dircap. Removing all ambient file/directory
authority from the webapi fixed that nicely: the user always has to
supply their own filecap.

So I'm wondering how we might make storagecaps work the same way: the
client node doesn't have any storage-authority built-in, and the
(webapi) user must always supply their own storagecap to do any
operation that consumes more server space (file-upload, repair,
directory modifications).

If they're small enough, we could include them as a query argument in
webapi operations. The CLI could read the storagecap out of
NODEDIR/private/something just like it reads NODEDIR/private/aliases.txt
to get a dircap, so 'tahoe put FILE' would still work nicely. When using
"tahoe webopen ALIAS", we might have it attach the storagecap to the
URL, and then change the WUI so that any writeable directory view would
include the storagecap queryarg on the URLs of child directories. That
would keep the storagecap around when necessary, but could chip it off
the URL when you view a non-writeable resource.

That WUI approach would cause problems with sharing though, at least
within a static no-JS WUI, because copy-and-pasting the URL bar would
also give away your storage authority. I think people would be happier
with either some clearly-marked "Share This Directory" links (which
would omit the storagecap), or with a dynamic JS-based frontend (which
could hold the storagecap in memory, instead of passing it through the
URL from one page view to the next). Bookmarking a writecap would
require deciding whether you wanted to include storage authority or not.

What do people think? Ambient storage authority or pass in a storagecap
with each request?

cheers,
 -Brian