[tahoe-lafs-trac-stream] [tahoe-lafs] #1200: package up Brian's New Visualization of immutable download

[tahoe-lafs]

#1200: package up Brian's New Visualization of immutable download
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:  nobody
         Type:           |     Status:  new
  enhancement            |  Milestone:  1.9.0
     Priority:  major    |    Version:  1.8β
    Component:  unknown  |   Keywords:  unfinished-business immutable
   Resolution:           |  download statistics performance transparency
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by warner):

 Replying to [comment:11 drewp]:

 > That seems extreme. Surely there's a scheme for loading the lib from
 > google and then checking it against a small local fingerprint that you
 > package with your main sources.

 Hm, are you thinking something like this?

 * browser hits WEBAPI/jQuery.js
 * tahoe server does a reverse-proxy to fetch a copy from google
 * checks the contents against a fingerprint,
 * returns it to browser or throws error
 * server caches the file for later use

 Feels kind of weird, but I suppose it *does* satisfy the goals of not
 including a copy in the source tree, nor fetching it during build. It
 would mean that the viz display wouldn't work unless the server could
 reach the internet, which is probably not a real constraint (I run tests
 on my offline laptop all the time, and I'd like viz to work there, but
 I'll admit that most grids aren't like this). It feels morally
 equivalent to having the server fetch those files from google at boot
 time, which feels pretty similar to having it fetch the files at build
 time.

 > This might even be doable in the browser, which would be cool since it
 > defers the download until you actually show you were going to use a
 > browser.

 Hm, *that* sounds challenging. If Zooko's PMAGH project really existed
 (and browsers would enforce hash-of-contents in URLs), then we could
 just use a link that routed to google but which identified a specific
 version of jQuery. Lacking that.. sounds tricky. A normal <script> tag
 won't protect you. Sounds like the page would need to XHR to google
 (which is prohibited by the annoying same-origin-policy), retrieve
 jQuery.js as data, hash it (in javascript: slow but possible), then,
 what, document.write() it into the page as a new <script> tag? Something
 like that?

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1200#comment:13>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage