Re: [tahoe-dev] Accounting, 2010 edition

> GPG requires more clicks, more thought, and more administration than > insecure communication. and jumping off a cliff is easier than a long march. i.e. different goals and different results. > The way secure communication should work is that > > 1: a hash of a rule identifying a public key

Re: [tahoe-dev] Accounting, 2010 edition

On 2011-01-05 4:06 PM, Randy Bush wrote: we know gpg/pgp is unfashionable. but i got used to being unfashionable many decades ago. so what is in fashion? cleartext email? cleartext files? The problem is not fashion, but architecture and user interface. GPG requires more clicks, more though

Re: [tahoe-dev] Accounting, 2010 edition

By the way, does anyone here actually use GPG? >>> daily >> Likewise. > I use gpg once in a blue moon. Long ago, I considered this a failing, > but now take the view infrequent use allows me to perceive the reasons > why gpg is used infrequently. we know gpg/pgp is unfashionable. but i got

Re: [tahoe-dev] Accounting, 2010 edition

On 2011-01-05 6:23 AM, Ben Laurie wrote: On 23/12/2010 02:58, Randy Bush wrote: By the way, does anyone here actually use GPG? daily Likewise. I use gpg once in a blue moon. Long ago, I considered this a failing, but now take the view infrequent use allows me to perceive the reasons w

Re: [tahoe-dev] Accounting, 2010 edition

On 23/12/2010 02:58, Randy Bush wrote: >> By the way, does anyone here actually use GPG? > > daily Likewise. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Wood

Re: [tahoe-dev] Accounting, 2010 edition

> By the way, does anyone here actually use GPG? daily ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] Accounting, 2010 edition

On 2010-12-23 2:48 AM, Zooko O'Whielacronx wrote: By the way, does anyone here actually use GPG? I certainly don't, although occasionally I interact with build systems automation that uses gpg to sign debian packages, and very rarely (once every few years) I receive a gpg-encrypted email from a l

Re: [tahoe-dev] Accounting, 2010 edition

"Zooko O'Whielacronx" writes: > On Wed, Dec 22, 2010 at 6:34 AM, Greg Troxel wrote: >> >> I don't debate your point, but will observe that if you are right it >> needs to be reinvented as a first-class project/protocol/etc. rather than >> something tacked on to tahoe. > > Why do you say that? I

Re: [tahoe-dev] Accounting, 2010 edition

On Wed, Dec 22, 2010 at 6:34 AM, Greg Troxel wrote: > > I don't debate your point, but will observe that if you are right it > needs to be reinvented as a first-class project/protocol/etc. rather than > something tacked on to tahoe. Why do you say that? I don't think I agree. However, that's sor

Re: [tahoe-dev] Accounting, 2010 edition

"James A. Donald" writes: > On 2010-12-21 11:56 PM, Greg Troxel wrote: >> >> My real point was not that openpgp should be mandatory, but that >> whatever tahoe does should be compatible, and avoid reinventing the >> trust management wheel > > Trust management is rather broken. We need to reinve

Re: [tahoe-dev] Accounting, 2010 edition

On 2010-12-21 11:56 PM, Greg Troxel wrote: My real point was not that openpgp should be mandatory, but that whatever tahoe does should be compatible, and avoid reinventing the trust management wheel Trust management is rather broken. We need to reinvent trust management. _

Re: [tahoe-dev] Accounting, 2010 edition

On 12/20/10 7:01 PM, David-Sarah Hopwood wrote: > On 2010-12-20 22:16, Brian Warner wrote: >> The other API would be used in a similar way, right after you build a >> manifest, but it would mean "immediately cancel all my leases on >> shares that weren't in the manifest". This would even be safe i

Re: [tahoe-dev] Accounting, 2010 edition

On 12/21/10 5:56 AM, Greg Troxel wrote: > > and avoid reinventing the trust management wheel > > Your comment made me realize more crisply that the real property I want > From pgp is to be able to manage keys via pgp and then easily insert > them into tahoe. I really do mean "manage via and inse

Re: [tahoe-dev] Accounting, 2010 edition

On 2010-12-21 3:35 AM, Ravi Pinjala wrote: 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

Re: [tahoe-dev] Accounting, 2010 edition

On 2010-12-21 13:56, Greg Troxel wrote: > > My real point was not that openpgp should be mandatory, but that > whatever tahoe does should be compatible, and avoid reinventing the > trust management wheel > > Your comment made me realize more crisply that the real property I want > From pgp is to

Re: [tahoe-dev] Accounting, 2010 edition

My real point was not that openpgp should be mandatory, but that whatever tahoe does should be compatible, and avoid reinventing the trust management wheel Your comment made me realize more crisply that the real property I want From pgp is to be able to manage keys via pgp and then easily insert

Re: [tahoe-dev] Accounting, 2010 edition

On 2010-12-20 23:42, Greg Troxel wrote: > > Brian Warner writes: > >> On 12/20/10 7:53 AM, Greg Troxel wrote: >>> >>> 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

Re: [tahoe-dev] Accounting, 2010 edition

On 2010-12-21 03:01, David-Sarah Hopwood wrote: > On 2010-12-20 22:16, Brian Warner wrote: >> The two additional APIs we've thought about are batch-renew and >> batch-cancel-everything-else methods. The batch-renew is what you'd use >> after you've done a deep-traversal of your directory tree (i.e.

Re: [tahoe-dev] Accounting, 2010 edition

On 2010-12-20 22:16, Brian Warner wrote: > The two additional APIs we've thought about are batch-renew and > batch-cancel-everything-else methods. The batch-renew is what you'd use > after you've done a deep-traversal of your directory tree (i.e. "tahoe > manifest"), and then you (or somebody you'v

Re: [tahoe-dev] Accounting, 2010 edition

On 12/20/10 3:42 PM, Greg Troxel wrote: > > Even if I could do a 'tahoe show-usage' and get something that is > > blocks pubkey > > and then a 'tahoe remove-all offending-pubkey' as a server admin that > would be a great start. Yeah, that should be part of Phase 1. I've been thinking of a web

Re: [tahoe-dev] Accounting, 2010 edition

Brian Warner writes: > On 12/20/10 7:53 AM, Greg Troxel wrote: >> >> 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.

Re: [tahoe-dev] Accounting, 2010 edition

On 12/20/10 7:53 AM, Greg Troxel wrote: > > 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 ou

Re: [tahoe-dev] Accounting, 2010 edition

On 12/20/10 9:38 AM, Shawn Willden wrote: > On Mon, Dec 20, 2010 at 10:35 AM, Ravi Pinjala > wrote: > > 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 would

Re: [tahoe-dev] Accounting, 2010 edition

On Mon, Dec 20, 2010 at 10:35 AM, Ravi Pinjala wrote: > 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. If lease expiration is turned on, your shares will go away

Re: [tahoe-dev] Accounting, 2010 edition

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 th

Re: [tahoe-dev] Accounting, 2010 edition

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 concr

[tahoe-dev] Accounting, 2010 edition

It's December, which means it's time to talk about Accounting again[1]. Each time we cycle around this topic, we chip away at the complexity, prune back some of the loftier goals, haggle for a couple of weeks, then throw up our hands and go back to our day jobs for another couple months. This ti