devchat notes 06-Dec-2016
warner at lothar.com
Tue Dec 6 20:14:42 UTC 2016
Tahoe Devchat 06-Dec-2016
Attending: warner, meejah, liz, cypher
* 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
More information about the tahoe-dev