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 _______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
