devchat notes 09-May-2017

[Brian Warner]

Tahoe-LAFS devchat notes 09-May-2016

Attendees: warner, exarkun, liz, meejah, cypher

* warner will land exarkun's magic-wormhole dockerfile patch (PR 149)
  * also add dockerhub integration to MW account
* exarkun will look at tahoe's dockerfile situation
* warner will give dockerhub creds (for the tahoe account) to exarkun
  * add "exarkun" to the organization
  * also find out where the integration is pointing at
* ping ramki about namespaces
* warner will write up "federated grid" approaches to mailing list
* clearinghouse approaches
  * two features: help find foreign data, mediate payment
  * 1: clearinghouse maps short "area code"/grid-id to server access
       FURLs (and also mediates payment)
  * 2: filecaps include full verifying key as "area code",
       access/contact-info stored in DHT
    * foreign-filecaps get kinda big
    * DHT is pretty small: one record per grid, probably 1KB max
    * is the DHT sufficiently incentivized?
  * 3: clearinghouse keeps a giant table of storageindex -> home grid
    * filecaps remain small: one cryptovalue for mutable, two for
      immutable
    * to sign up with the clearinghouse, your servers must register all
      their storage indices
      * maybe clients can distinguish between "local" files and
        "remotely-available"/"shared" files
      * kind of a drag on the GUI, but maybe people would (like to) use
        this as a form of access control
    * clearinghouse provides obvious value
    * easier to implement on the client: add a special server (always
      the last one queried) which is backed by clearinghouse-provided
      data
* initial directions:
  * add "grid manager":
    * defined by a verifying pubkey
    * clients sign up with one grid manager via invitation process
    * grid manager chooses which storage servers are part of the grid
    * grid manager chooses which clients can use the grid
  * payments (if any) happen out-of-band
    * clients provide an accounting pubkey to grid manager, who delivers
      them to servers
      * maybe via the grid-membership announcement: include both
        authorized servers *and* clients
    * servers measure usage, indexed by accounting pubkey, provide
      reports to grid manager
      * so grid manager knows Alice's aggregate usage, across all
        servers, according to servers
    * server displays data to the server operator, who decides what/how
      to bill the grid manager
      * maybe add a price list to the server, so the report can be
        denominated in $/BTC/ZEC/etc
      * but don't publish this price list in any machine-readable
        format, for now
    * grid manager gets a report, decides what/how to bill clients
      * maybe do a similar internal price list
  * friend-net: somebody volunteers to manage the grid, runs
    grid-manager, adds everybody as servers and clients
    * usage reports but no billing
  * rent-a-friend-net: provide a pre-packaged grid-manager which uses S3
    * paste in AWS creds, grid-manager sets up a single server on S3
    * admin's job is to make sure the AWS bill is paid
  * initially, the only corrective tool is revocation
    * grid-manager can kick a client out of the club
    * storage server admin can kick out the grid-manager
* servers could lie about how much space is being used (to extract more
  money from grid manager)
  * can bound this by using finer-grained space delegation
    * instead of server granting all space to manager, then manager
      granting all space to Alice
    * server could give a token for 1GB of space to manager, manager
      gives to Alice
    * Alice won't ask for a new token until she's used up the first one
    * server can't claim alice is using more than 1GB unless the manager
      was asked for a second token
  * tradeoff of (network traffic, grid-manager involvement, complexity)
    against (server's ability to lie)
  * sounds like Macaroons, issued by storage server,
    constrained/attenuated by grid-manager, exercised by clients
* foreign-grid payment issues
  * should clearinghouse force members to charge a fixed rate for
    downloads? doesn't feel right
  * each grid can tell the clearinghouse what their rate is, must commit
    to it for some amount of time
  * like phone-call rates to different area codes costing more or less:
    expensive remote grid, cheap remote grid
  * local grid-manager can decide how much is too much, limit or forbid
    access to some grids
    * "sorry, that's a 1-900- number, completely blocked"
  * Alice shouldn't contact foreign grid directly: she should go through
    a gateway (specified by grid-manager)
    * use her accounting key to request the ciphertext of a foreign-grid
      file
    * gateway checks with grid-manager for permission, which decides
      based on price and Alice's quota
    * gateway talks to foreign grid's gateway (announced by
      clearinghouse), uses local grid's credentials
    * foreign grid gateway talks to its servers, does erasure decoding,
      delivers ciphertext
    * foreign grid tells clearinghouse about the charge, clearinghouse
      adds to local grid manager's bill
    * same issues about servers lying
      * aim for pairwise token exchange, limit total counterparty risk
* magic-wormhole "get token from URL" hashcash/captcha generalization:
  file issue, implement
* gridsync invitation body: start with exchange of abilities, make room
  for future "tahoe invite" with more keys
  * grid-manager will eventually provide a verifying key,
    grid-membership announcements will be signed by it
  * client will eventually submit a client/accounting verifying key,
    needs to be delivered to servers