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 <[email protected]> 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 > [email protected] > http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > > _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
