diff --git a/Summit2Day2.md b/Summit2Day2.md
new file mode 100644
index 0000000..31aaf1f
--- /dev/null
+++ b/Summit2Day2.md
@@ -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.