[tahoe-dev] Accounting, 2010 edition

[Ravi Pinjala]

One thing I can't figure out: how do you handle losing your caps for a
share? In that case, it'd still count against your storage limits, but
you wouldn't be able to delete it. Having a backup method for deletion
wouldn't work, because then anybody could potentially delete a share
without having the writecap.

Now that I'm thinking about it, what might work is to give users the
ability to move shares to a new account. Then, if you lost the
writecap for half your data, you could move the other half to a new
account, close the first account, and not be charged for data you no
longer have access to. Thoughts on this?

--Ravi

On Mon, Dec 20, 2010 at 7:53 AM, Greg Troxel <gdt at ir.bbn.com> wrote:
>
> I'll have to digest your note later, but a quick thought: There's a
> grand ultimate vision, and there are incrementally useful steps.  It
> would be nice if we could both do something limited that was immediately
> useful, and also have that work be on the path to the eventual right
> answer.
>
> 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
>
>
> It's probably worth figuring out how to deal with keying, since it seems
> like there is
>
>  x509
>  openpgp
>  roll our own
>
> My vote is for openpgp because it has socially compatible assumptions,
> and I almost always vote against roll your own.
>
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>