<div dir="ltr"><div><div><div><div>Hi.<br></div><div>I've been out of touch with you Tahoe-LAFS folks lately (boring work reasons), but since this is something I've had some experience with (and since writing this serves as a well-deserved procrastination), here goes:<br>
</div><div><br></div>I happen to have a use-case. Mine :)<br>I use Tahoe-LAFS for storage, but once in a while I want to share a file or a folder (read only) with friends and colleagues. It's like a cut-the-middleman version of yousendit.<br>
As a byproduct, this also serves as a public static web server. There's no php/cgi/etc., but there are pretty cool tools that generate static html, like <a href="http://nikola.ralsina.com.ar/">http://nikola.ralsina.com.ar/</a> and <a href="http://blog.getpelican.com/">http://blog.getpelican.com/</a> which is what I use at  <a href="http://dubious.org/blog">http://dubious.org/blog</a><br>
</div><div>I could also add also add some dynamic content as iframes (disqus, twitter widget, etc.), but because of the risk of leaking write caps (and because those things track users), I'd rather not explore that direction.<br>
</div><div><br></div><div>When I first asked Zooko how to do it and whether there were any risks, he recommended <a href="https://bitbucket.org/nejucomo/lafs-rpg">https://bitbucket.org/nejucomo/lafs-rpg</a> - a script that configures nginx to be a proxy for the Tahoe-LAFS web-api. Such a proxy is needed because although people who only have a read cap can't change the file they can read, they can still create new files and DoS the grid's storage space.<br>
<br></div><div>This is the setup Zooko uses at <a href="https://zooko.com">https://zooko.com</a><br><br>Zooko also has a TiddlyWiki (single-page static wiki) at <a href="https://zooko.com/klog.html">https://zooko.com/klog.html</a> that comes with a plugin he wrote that lets you edit the page in the browser and save it to the grid. If you want one - see <a href="https://tahoe-lafs.org/trac/tiddly_on_tahoe">https://tahoe-lafs.org/trac/tiddly_on_tahoe</a><br>
<br>Note that this trick requires working on the write cap, and - as public sites go - you may sometimes want to include an external image (or you may accidentally click an external link while viewing the write cap), so this should only be done on a browser "rigged" not to send refer[r]er. I use <a href="https://addons.mozilla.org/en-US/firefox/addon/refcontrol/">https://addons.mozilla.org/en-US/firefox/addon/refcontrol/</a> to avoid such accidents.<br>
<br>In hind-sight I'm not sure I'd install tiddly_on_tahoe today, but <a href="http://dubious.org/">http://dubious.org/</a> is already one, and I find the result mighty shiny :)<br></div><br></div><div>Hope this helps,<br>
</div><div>The Dod<br></div></div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 24, 2012 at 12:26 AM, Greg Troxel <span dir="ltr"><<a href="mailto:gdt@ir.bbn.com" target="_blank">gdt@ir.bbn.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
Alfonso Montero López <<a href="mailto:amontero@tinet.org">amontero@tinet.org</a>> writes:<br>
<br>
</div><div class="im">> I was just thinking in a web server redundancy and/or load balancing<br>
> scenario, but having a hot-standby server it's another good use case.<br>
> It's not a matter of capacity, I would like every web server to have<br>
> the entire web root available locally to make it be as performant as<br>
> possible. Having remote dircaps mounted someway could be fit for other<br>
> applications I can't think of now. By Greg's comment, makes me think<br>
> that perhaps tahoe's encryption adds too much overhead and it's an<br>
> overkill.<br>
> However, Miles made a very good point in another feature I haven't<br>
> thought of. Each user's home dir would be just another dircap, and the<br>
> entire tahoe architecture would fit beautifully for handling user<br>
> separation and security. As tahoe is now, you should trust the users<br>
> somehow for space abuse, but that's a WIP in the accounting side. That<br>
> makes tahoe's encryption have sense again.<br>
> I'm still not sure if what I propose is too much overhead<br>
> performace-wise or an overkill approach. Maybe I'm dreaming awake :)<br>
<br>
</div>A few comments:<br>
<br>
  I don't think tahoe's encryption is what makes it slow.  I think it's<br>
  the implementation in python and the number of round trips and lack of<br>
  caching.<br>
<br>
  For security, it's tricky since the web servers (many!) have all the<br>
  credentials, at least for read.<br>
<br>
  I agree that if you want a massively distributed/survivable filestore<br>
  and also want that the be web accessible, this makes sense.<br>
<br>
  If you're thinking about censorship-resistant publishing, I'm not sure<br>
  the above architecture helps all that much.  It might, but it's not<br>
  really one of tahoe's goals and analysis of censorship is very tricky.<br>
<br>
<br>
<br>
<br>_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a><br>
<a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
<br></blockquote></div><br></div>