[tahoe-dev] LAFS Weekly Dev Hangout notes, 2012-12-06

[Zooko Wilcox-O'Hearn]

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.