devchat notes 06-Dec-2016

[Brian Warner]

Tahoe Devchat 06-Dec-2016
Attending: warner, meejah, liz, cypher

Notes:

* 1.12 release is still blocked on #2490 (connection-info), which is
  blocked on foolscap #267. Foolscap code landed last night (finally!),
  and needs some tweaks, but overall looks good. The tahoe-side branch
  needs some small API work before landing. Beta1 can be cut after it
  lands, then folks can review the UI changes.

* Goal is to get 1.12 released in the next few weeks.

* How many people are using tahoe? We don't know. We don't want any sort
  of embedded analytics, of course (privacy!), but it's be nice to get
  some sort of feedback. Please brainstorm about ways to help us (the
  tahoe project) learn more about who/how/when people use tahoe. Maybe a
  "mailto:" link on the welcome page that populates some information
  about number of servers? Maybe a link from the welcome page to a
  tahoe-lafs.org form-submission page? Maybe a "tahoe report-usage" CLI
  command that makes an HTTP call to a gathering service we run?

* warner described an idea for a "rootcap recovery flowchart builder"
  application: a standalone GUI program that would let you assemble an
  authority graph. It would have source factors like "key file" /
  "password" / "GPG/smartcard/YubiKey", conjunction nodes like "AND" /
  "OR" / "k-of-N" (Shamir secret splitting), and output targets like
  "writecap"/"readcap". Then you push GO and the tool creates the
  targets, derives the necessary intermediate factors/shards, then gives
  you a tool to deliver the source factors to the necessary locations.
  More details to come in an email.

* meejah+warner discussed extension ideas: we like how git does it ("git
  foo" looks for a git-foo executable on $PATH). That flowchart-builder
  could be invoked as "tahoe make-map", which could be delivered as
  "tahoe-make-map". Much of the current CLI could be split out this way
  (maybe a separate python distribution named "tahoe-lafs-cli", which
  uses the WAPI and some common alias-parsing code, but doesn't import
  anything from the rest of tahoe). We'd probably need some
  command-discovery code and maybe a way for extension commands to
  report usage information back to the main runner (e.g. "git help -a"
  shows all git-* commands, and "hg help" can ask extensions for a
  synopsis). Maybe proper man pages for each command.

* That branched off into "tahoe as a library" ideas, again with the
  mysql-vs-sqlite split (mysql is a daemon that must be running when
  your application starts, which imposes some packaging/deployment
  constraints, whereas sqlite is just a library you link against). If we
  split tahoe's storage server into a separate process, and magic-folder
  / periodic-backup tasks as well, then the remaining client-only code
  wouldn't need so much persistence. Using HTTP for the storage server
  protocol would help too. In general we're in favor of the sqlite
  approach, although client applications might still need to provide a
  MultiService to hang the tahoe Node object upon.

* Cypher is working on a GUI setup frontend, using Qt for cross-platform
  goodness


cheers,
 -Brian