In attendance: Brian, David-Sarah, Zooko (scribe), Andrew, PRabahy (silent)
The meeting started about 10 minutes late and ran more than 30 minutes past its scheduled stop-time. (Because we were too engaged to stop at the stop-time since we were sorting out the question of whether Zooko's "Strong Proof-of-Retrievability" concept was inherently as inefficient as simply downloading the whole file.) Caveat Lector! I might have forgotten some stuff. I haven't taken the time to add explanations for most of what follows. My own biases shine through willy nilly. * The LAFS-PoR.rst text file was cleverly hidden behind an obstacle course. * 'Ephemeral Elliptic Curve Diffie-Hellman‽ My friend Zooko excels at redefining "What 'everyone' or what 'no-one' uses."' * leasedb+cloud-backend * LeastAuthority.com has at long last delivered Milestone 3 to DARPA. Milestone 1 was a design document Milestone 2 was Cloud/S3 backend, and Milestone 3 was leasedb. * https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1818 / https://github.com/davidsarah/tahoe-lafs/tree/1818-leasedb is the implementation of leasedb against trunk (disk backend) * https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1819 / https://github.com/davidsarah/tahoe-lafs/tree/1819-cloud-merge is the merge of that with the cloud backend * The 1819-cloud-merge branch passes all unit tests, and passes manual testing by David-Sarah. It is currently being evaluated on behalf of DARPA by their contractors, BITSYS. * next steps: * Keep 1818-leasedb and 1819-cloud-merge out of Tahoe-LAFS v1.10. * Let Brian review them. * David-Sarah is still re-recording the patch series for 1819-cloud-merge. * Zooko is still code-reviewing the patches. * Check for the transition experience — what happens the first time you upgrade, for example. * There is at least one incomplete detail about transition: starter leases don't get added (there isn't a ticket for this — we should open one). * Zooko and David-Sarah want to implement #1834 and related tickets — not necessarily before we land it on trunk, but before we release 1.11. Or we could do it on the branch before we land it on trunk. * Tahoe-LAFS v1.10 * Let's package up what we have currently on trunk (plus, Zooko added to these notes after the meeting, possibly a few other good patches that are basically already done, are very non-disruptive — such as documentation-only patches — and/or have forward-compatibility implications, such as #1240, #1802, #1789, #1477, #901, #1539, #1643, #1842, and #1679). * Everyone review pending tickets! https://tahoe-lafs.org/trac/tahoe-lafs/milestone/1.10.0 * The next Weekly Dev Hangout will be about Tahoe-LAFS v1.10 * goal: get trunk to meet our desires for Tahoe-LAFS v1.10, release from trunk * Brian wants to fix #1767, which has forward-compatibility implications. * tarcieri's new HTML * not for 1.10 * It changes only the front page and so the other pages are inconsistent with the new front page. * But commit it to a branch ASAP and demonstrate to tarcieri that we're serious about merging it to trunk as soon as it is complete. * Proof-of-Retrievability * Zooko has written a rough draft of a tahoe-dev post/science paper, arguing that real "Strong" Proof-of-Retrievability is possible, that the current exemplars in the crypto literature fail to provide Strong Proofs-of-Retrievability, and that Tahoe-LAFS combined with Tor would make a nice basis on which to build a Strong Proof-of-Retrievability, and that if it did, it would be a practical censorship-resistance tool. * Brian posed some good challenges in practical terms about the performance and bandwidth costs. * The key difference that makes this new concept of Proof-of-Retrievability different and better than previous attempts is that it uses multiple storage servers (which are hopefully not colluding with one another), and erasure-coding in order to keep total upload and storage costs fixed even while scaling a single file, horizontally, to a large number of storage servers. * That's also the key to answering Brian's challenge — that sort of spreading across storage servers alllows one to gain verification assurance — *even* against Adaptive Malicious Storage Servers — at a fraction of the aggregate bandwidth cost of a full download. If there were only a single storage server then Juels-2009 and Brian-in-this-meeting would be right that no efficient Strong PoR is possible. * Next steps: Zooko needs to rewrite the second half of the current document to emphasize these insights gained from this meeting and to streamline it. Several experts have volunteered to review it already. Then: post it to tahoe-dev? * David-Sarah has some idea that Brian and Zooko don't quite get about improving the quantitative advantage to the defender by increasing erasure coding parameters and storing multiple shares per server. * Let's get drunk and argue about whether God can see into the future. _______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
