wiki:Summit2Day2

Version 2 (modified by warner, at 2011-11-12T20:03:15Z) (diff)

add whiteboard pix

2nd Summit Day 2

09-Nov-2011, Mozilla SF.

Attendees

  • Zack Weinberg
  • Zooko
  • David-Sarah
  • Brian
  • Shawn
  • Mark Seaborn

Ideas

  • Shawn: would be nice to have a more traditional username/password web frontend
    • I (warner)'m imagining an IService, listening for HTTP on a different port than the main WEBAPI port, with a public URL. You submit username+password, get a cookie, present a filename. The gateway translates that into a filecap.
    • maybe store one rootcap per username. use bcrypt/scrypt to defer exposure until user submits password.
    • adding ACLs: either put a table in the frontend (username->file list), or put ACL data in dirnode edge metadata and have frontend compare it against a username
    • sharing to public: tell frontend a filename/dirname and ask to make it public, it returns a tinyurl. Just like a tinyurl except it's a proxy instead of a redirect.
    • sharing to an individual: maybe have an encryption pubkey for each account, Alice tells frontend "share my ~/foo with user=Bob", frontend encrypts a note to itself with Kbob, later when Bob logs in, his password bcrypt-unlocks the decryption key Kbobpriv, decrypts the note, gets the dircap, adds to a table for Bob, lets him enumerate a list of inbound shared directories
  • zwol describing a Tor project, making Tor traffic look like other traffic: WoW, other web browsing. "Stegatorus"?
  • zwol thinking about censorship-resistance, content-centric networking

Control Panel

  • Brian explained requirements for a tahoe web-control-panel:
    • examine/control Agent things like periodic backup jobs (local dir, dircap, schedule, status, progress), lease-renewal/repair jobs (dircap, schedule, status, progress)
    • not using browser ambient authority, accessed through NODEDIR (iff you can read/write to NODEDIR/private, you should be able to get to the Web Control Panel),
    • not scoped to a particular filecap/dircap
    • yes scoped to "client authority" (i.e. an "Account", q.v. Accounting, for general uploads and maybe repair), or local-disk-authority (backup jobs), or server admin (for the server side of Accounting)
    • ok to have no-JS and yes-JS options, ok if the no-JS option is less pleasant
  • David-Sarah, Zack, Shawn designed a scheme
    • writes a "control.html" into NODEDIR/private/
    • "tahoe control" launches browser with file://.../control.html
    • yes-JS version:
      • it contains one big <iframe src="http://WUI/control#SECRET">
      • that page contains JS which pulls the secret out of the fragment, then does lots of XHR with the secret to present the control panel
    • no-JS version:
      • it contains a form with a big "Start" button and a secret in a hidden form-post argument
      • that returns a page with lots of forms, secrets in hidden post-args. All links are POSTs. "back" won't be pleasant (requires a 're-submit form?' confirmation each time).
    • benefits: keep secret out of address bar, out of Referrer header
  • other useful techniques:
    • to limit the lifetime of a powerful secret, 'tahoe control' can write a new secret into NODEDIR just before launching the browser, and the node can erase or change the secret just after accepting the resulting browser hit.
    • splitting the webapi into multiple origins is becoming more important: probably starting with one port for (control-panel, welcome, node-status, WUI-dirnodes, download-only WAPI), and a second one for (WUI-documents) that could be executable.
  • whiteboard

Accounting Review

  • Brian presented his Accounting branch (https://github.com/warner/tahoe-lafs/tree/accounting) , only looking at the delta between the '466-ed25519' branch and the 'accounting' branch (it builds upon the #466 work)
  • deferred discussion of leasedb crawler and race conditions, that requires more serious design work. David-Sarah and Brian will huddle on it, probably online later
  • approach seemed good, code is still incomplete
  • needs: more tests, usable control panel, refinement of "account message" concept
  • need to carefully plan the merge with LAE's s3-backend: they overlap a lot. Removing leases from shares helps a bunch. s3-backend introduces async share-crawlers, accounting removes one big crawler but adds a new small one, which might need to be async-ified if that still seems like a good idea.
  • consensus was that #466 should definitely land first. But then whether accounting should land before s3-backend, or other way around, was unclear. accounting needs more development work before it's ready for landing, s3-backend might be closer. But some co-evolution and anticipatory refactoring should make things easier for everybody.
  • brief discussion about branches in Git vs Darcs, specifically for working on projects like this. Brian anticipates pain and suffering trying to test merges of s3-backend (managed in a darcs branch) with his accounting work (managed in git branches). David-Sarah suggested applying the git/darcs bridge on a branch too, brian skeptical.

Attachments (1)

Download all attachments as: .zip