devchat notes 28-Mar-2017

[Brian Warner]

Tahoe-LAFS devchat 28-Mar-2017

Attendeees: warner, exarkun

Notes:

* Foolscap proxy server: LAE wants to host multiple customers (with one
  Introducer and one Server each) on a single host. This is much
  easier/cheaper if they can all share a single IP address and port.
  * Foolscap redirections: client says "can I connect to Tub XYZ",
    server says "please talk to IP/PORT=blah instead". Foolscap only has
    partial support for redirections so far (server knows how to emit
    them, but clients won't follow them).
  * Came up with "foolscap proxy": server says "sure, I can be Tub XYZ",
    but internally it opens a new TCP connection to some (probably
    local) IP and port, and relays all traffic to it
  * This will probably be deployed as a standalone process, using
    Foolscap but not Tahoe, one per host.
* Multi-tenancy: it's pretty easy to write a program that puts multiple
  Tahoe nodes in a single process: each one is an all IMultiService
  configured with a base directory, so just make a bunch and
  setServiceParent them to some containing MultiService.
  * sharing a Tub would be useful
  * Foolscap used to support this, but I stripped it out because it
    raised difficult questions about service lifetimes and ownership (if
    the last Tub associated with a Listener is stopped, should the
    Listener be stopped too?)
  * New approach: make a distinct MultiListener object. Creator must
    manage lifetime (startService/stopService) themselves. Then either
    tub.addListener(ml) or ml.addTub(tub).
* exarkun was learningabout StorJ: interesting JS-based project, not
  unlike Tahoe, uses DHT and some finite number of proof-of-storage
  challenges
* warner was learning about Dat: interesting JS-based project, not
  unlike Tahoe, uses DHT, shares directory trees, sort of has single
  writecap and multiple readcaps but no verifycaps
* want to write up a competitive analysis blog post about StorJ, Dat,
  Syncthing
* thinking about server provisioning again
  * want a single binary, e.g. "tst" = tahoeserverthing
  * want to run "tst init", "tst daemon" like with IPFS
  * view status through a web page
  * then "tst add-client [--petname=] [--quota]=", emits invitation code
  * on client do "tct accept INVITECODE"
  * that should cover the single-human run-my-own-server use case
  * server can require extra configuration if it doesn't have public IP
  * for client-uses-group-of-servers, get the invitation from a
    metaserver instead of from one specific server, the metaserver makes
    decisions about which servers you use
  * for "I want to run a public server that accepts BTC", you should
    configure the server to accept BTC somehow, then use some sort of
    invitation to get it published to a yellow pages
  * no idea how to have clients read the yellow pages and make decisions
    about which servers to use, maybe start by having that be manual
* warner wants to prototype something around provisioning, maybe
  omitting the tahoe-specific encode/encrypt/upload stuff entirely