add Day 2 report
[Imported from Trac: page Summit2Day2, version 1]
parent
3f9b1c8a9c
commit
a2515af2c0
100
Summit2Day2.md
Normal file
100
Summit2Day2.md
Normal file
|
@ -0,0 +1,100 @@
|
||||||
|
# [2nd Summit](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.
|
||||||
|
|
||||||
|
## 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.
|
Loading…
Reference in a new issue