[tahoe-dev] nanobarter redux

[zooko]

Folks:

My conversation with Nick Szabo about his notion of "nanobarter" has  
been slowly progressing:

http://unenumerated.blogspot.com/2007/06/nanobarter.html

In a related story, Brian and I started talking yesterday about the  
issues of "quotas", "file maintenance", and related topics for Tahoe.

The question is: how to allocate resources?  For example, if there is  
a storage server, and a client connects to it and requests that it  
store a gigabyte of data for 30 days, and if the server has the space  
available to write a gigabyte, then should the server grant or deny  
this request from the client?

There are currently two or three use cases that we care about in the  
short term:

1.  Allmydata.com owns the server, and Allmydata.com's customer owns  
the client.  The server should accept the request if and only if the  
customer has the right kind of contract with Allmydata.com.

2.  Your friend owns the server, and you own the client, and the  
server should always grant your request.

3.  Your friend owns the server, and you own the client, but your  
friend wants to share his space evenly among his friends, so the  
server should grant your request only if you are not using up more  
than your share.

My basic feeling at this point is that we can make an abstraction for  
the resource allocation decision, and that abstraction can be  
implemented as an account-server or token-server resolution for the  
first use case, and as local or bilateral peer relationship logic for  
the second two use cases.  Likewise, other use cases that might arise  
can hopefully fit into this same basic abstraction.

What I mean is, in the  
"please_allocate_some_space_for_some_duration_for_me()" message,  
there could be an argument named "why_should_you" which contains an  
object (i.e. a foolscap-referenceable Python object).  This object  
could be None for the second use case, it could contain a reference  
to an account server and an account id for the first use case, and so  
on.

This is still early days for this issue.  More to come as I  
understand it.

Regards,

Zooko