[tahoe-dev] Tahoe-LAFS as web server file backend?

[Uncle Zzzen]

Hi.
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:

I happen to have a use-case. Mine :)
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.
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 http://nikola.ralsina.com.ar/ and http://blog.getpelican.com/ which is
what I use at http://dubious.org/blog
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.

When I first asked Zooko how to do it and whether there were any risks, he
recommended https://bitbucket.org/nejucomo/lafs-rpg - 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.

This is the setup Zooko uses at https://zooko.com

Zooko also has a TiddlyWiki (single-page static wiki) at
https://zooko.com/klog.html 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
https://tahoe-lafs.org/trac/tiddly_on_tahoe

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
https://addons.mozilla.org/en-US/firefox/addon/refcontrol/ to avoid such
accidents.

In hind-sight I'm not sure I'd install tiddly_on_tahoe today, but
http://dubious.org/ is already one, and I find the result mighty shiny :)

Hope this helps,
The Dod



On Mon, Dec 24, 2012 at 12:26 AM, Greg Troxel <gdt at ir.bbn.com> wrote:

>
> Alfonso Montero López <amontero at tinet.org> writes:
>
> > I was just thinking in a web server redundancy and/or load balancing
> > scenario, but having a hot-standby server it's another good use case.
> > It's not a matter of capacity, I would like every web server to have
> > the entire web root available locally to make it be as performant as
> > possible. Having remote dircaps mounted someway could be fit for other
> > applications I can't think of now. By Greg's comment, makes me think
> > that perhaps tahoe's encryption adds too much overhead and it's an
> > overkill.
> > However, Miles made a very good point in another feature I haven't
> > thought of. Each user's home dir would be just another dircap, and the
> > entire tahoe architecture would fit beautifully for handling user
> > separation and security. As tahoe is now, you should trust the users
> > somehow for space abuse, but that's a WIP in the accounting side. That
> > makes tahoe's encryption have sense again.
> > I'm still not sure if what I propose is too much overhead
> > performace-wise or an overkill approach. Maybe I'm dreaming awake :)
>
> A few comments:
>
>   I don't think tahoe's encryption is what makes it slow.  I think it's
>   the implementation in python and the number of round trips and lack of
>   caching.
>
>   For security, it's tricky since the web servers (many!) have all the
>   credentials, at least for read.
>
>   I agree that if you want a massively distributed/survivable filestore
>   and also want that the be web accessible, this makes sense.
>
>   If you're thinking about censorship-resistant publishing, I'm not sure
>   the above architecture helps all that much.  It might, but it's not
>   really one of tahoe's goals and analysis of censorship is very tricky.
>
>
>
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20121224/1c7f1abe/attachment.html>