[tahoe-dev] organizing the notes about accounting/quotas/invitations

Brian Warner warner at lothar.com
Thu Mar 29 18:45:36 UTC 2012

On 3/22/12 8:24 PM, Zooko Wilcox-O'Hearn wrote:
> I don't think so. Although, of course, I'm not entirely sure because
> there are too many accounting designs. However, I don't think *any* of
> Brian's accounting designs so far have been centralized, unless I'm
> misunderstanding what you mean by that word. Could you please be more
> specific?

We've designed a bunch of different stuff over the last 5 years, both in
the AllMyData world and afterwards, so we've considered the gamut from
centralized to decentralized. The variety of historical artifacts from
these periods will paint a pretty confusing picture. I've pared down the
complexity (and features) each year, hoping to get something (anything!)
implemented, and then build back up to the features we thought we needed
back then.

My current plan is to start with the decentralized M*N form: each user
(aka client, a person who wants to store files and the 'tahoe
create-client' node they use to talk to the grid) has a separate
relationship with each server (person who provides disk space, and the
'tahoe create-server' node they use to offer disk space to the grid).
Clients have keypairs, servers have keypairs, they use the same one
everywhere (so they could be correlated, once there exists something to
do the correlation).

Each server will tell the client how much space they're using. Later,
the server can impose limits on that client. From the client's point of
view, their grid-wide usage is the sum of what each server tells them,
but they have to do that sum themselves. There's no central authority to
enforce a global limit. There's also no central authority to tell all
the storage servers about a new client: the first design is an "accept
and report" scheme: servers accept any new client that connects.

Later, we may add a mode in which the server rejects new clients by
default, requiring the server admin to explicitly add new clients to a
table somewhere. This would achieve better control of storage space, at
the cost of requiring more work to get stuff started. For an
AllMyData-like system, or indeed for a friendnet with more than maybe
half a dozen people, that work becomes a drag (doing something to each
server for every new client: M*N). The centralized components that we've
dreamed up in the past would try to reduce that to M+N: some central box
that gets storage authority on all servers, and then clients get acccess
to the central box.

My long-term vision is to have grid membership based on invitations,
where anyone in the grid can invite new members, but everyone ends up
knowing who invited them. Then collective gossip can provide information
on each user's total consumption, which can then inform individual
decisions about granting storage space. But if specific server nodes
want to delegate control to some central space (e.g. Allmydata servers
configured to just follow company policy), that should be an easy
one-liner in tahoe.cfg.

But, we've learned to start small. The first phase is just going to be
distinguishing one client from another, and monitoring individual usage.
Later, we'll add local controls over client usage. Then, once we've
learned how people use those tools, we'll add the next step, whatever
that ends up being.


More information about the tahoe-dev mailing list