devchat notes from 07-Feb-2017

[Brian Warner]

Tahoe-LAFS devchat 07-Feb-2017

Attendees: warner, liz, dawuud, meejah, exarkun

Notes:
* dawuud and meejah are rewriting the #1382 severs-of-happiness branch
 * markberger did a clever set-rearrangement thing, makes it run much
   faster than the algorithm we wrote up at the summit
 * they're rewriting his code as functions, bringing it up to date with
   our coding standards
* accounting for S4-like services (shares on S3, tahoe server on EC2)
 * need to reconstruct lease data without EC2 state
 * could store lease data in small files next to shares, keep sqlite
   cache on EC2 box, rebuild when necessary
 * make it part of the pluggable storage backend
 * should it be an external command? or a built-in do it automatically
   at startup if the DB is missing?
  * it will take a while: must fetch all lease records from S3
 * not just leases: also accounts and account attributes
 * just dump whole .sqlite file into S3?
 * backend should be responsible for this: could choose to use a cloud
   DB service
  * maybe add an exception type for backends to raise during setup that
    means "please tell the operator to run a recovery command"
  * for upgrades and recovery
  * backend also has the option to do recovery automatically
 * Accountant is shared, but its state is stored in a backend-specific
   way
 * S3 has "immediate consistency" for reading new objects that were not
   read before being created
  * and eventual consistency for everything else
  * so try to avoid modifying shares
* goal is to allow a copy of .tahoe to serve as a backup
 * node can modify the contents for a few seconds after startup, but
   should then stop
 * should not require continuous backup of .tahoe
 * exarkun points out that it'd be better to be able to have a "tahoe
   init" command
  * All the state that is part of the node identity is created by this
    step
  * If you backup .tahoe after running this, you can always reconstitute
    the same node from that backup
* "node state storage subsystem"
 * not just shares
 * accounting info, runtime-discovered config data
* exarkun thinks about storing this in a DB for analytics
* could we use tahoe to store its own config/state?
 * worried about performance
 * would introduce extra dependencies: server A would depend upon server
   B for its own state
* maybe just use storage-backend for it
 * SI=accounting-thing-1
 * account manager asks share storage backend to write data to a
   known-SI
 * needs to be encrypted
  * general principle: protect server against its own storage backend
  * part of .tahoe/private/ is a key that encrypts that data
  * refactor file encoding/decoding code to be able to use it locally
   * "please encrypt this (state thing), one share only"
   * then turns around to write the ciphertext into the storage backend
 * goal is for .tahoe/private to be snapshotted once, right after
   startup, and that should be sufficient as a backup
* storing things in different ways depending upon how fast they happen
 * "low rate": node init
 * "medium rate": accounting changes: Alice is given permission to
   write, etc
 * "high rate": shares being modified
 * we're willing to make the operator do a backup of .tahoe/ for
   low-rate changes
 * willing to make S3 writes of databases/etc for medium-rate, but not
   high-rate
 * must be willing to make S3 writes (of flat data) for high-rate (share
   changes)
* maybe deployment makes a decision
 * speed of local sqlite, but not persistent
 * security of local sqlite: not exposed to other cloud users
 * persistence (but low-performance) of S3-stashed .sqlite files
 * persistence (but low-security) of real AWS cloud -DB
* starting point: add API to storage server for "local data"
  (config/private/etc)
 * must be async
 * code in Client or Node that uses self.write_private_config could be
   changed to use Client.write_something, which delegates to new
   StorageServer API
* related to replacing tahoe.cfg with tahoe.sqlite
 * must write "tahoe config" CLI command
 * lose ability to edit config with text editor
 * most users don't want to use a text editor
 * you can instruct someone to copy+paste a CLI command, but not
   instructions for a text editor
* talking about Petmail, Vuvuzela, rerandomizable tokens
* I2P problem
 * both sides were being TLS clients. TLS requires one client and one
   server.
 * could change Twisted's .startTLS() api to let you specify the side
 * or could change Foolscap to wrap the underlying protocol itself
  * this would enable foolscap-over-X, where X is an ITransport but not
    real TCP
  * maybe some new protocol that's implemented in pure Twisted, rather
    than TCP to a local daemon
* http://www.lothar.com/blog/55-Git-over-Tahoe-LAFS/