[tahoe-dev] One Grid to Rule Them All

[Avi Freedman]

> > I personally want to be able to email or tweet or inscribe on papyrus a URL
> > containing a read cap, and anyone who sees that and has Tahoe-LAFS version
> > Glorious Future installed should have a reasonable chance to retrieve the
> > content.
> 
> > Regards,
> > Comrade Nathan
> > Grid Universalist

As a followup...

I took a look at tinyproxy.

The config file I set up was:

http://38.118.79.85:8888/lafscluster1/file/URI%3ACHK%3Apr3tecemgw2t37fjo5gd7bo4bq%3Aj6ht6jhnetfdcjyjpwduns4rgqnxdq7slbrn4hjv5yiemt4skygq%3A3%3A10%3A10285/@@named=/tinyproxy.conf

(which is served using the proxy to a local node)

or

http://198.186.190.244/tinyproxy.conf

That's with a filter of:

root at introducer1:~# more /etc/tinyproxy.filter 
/file/*

Then just whomp in a filecap and it should work.  The first question
is whether there are other ways to get at the backend full web server
functionality under /file/

So I think that'd work as a way to expose files for download.
I wanted to explictly prohibit dirs since tahoe has more web logic
enabled about what to do with a directory.

For running as a service (commerical or otherwise), if every cluster
had their own proxy and every cluster only had one user (until accounting
comes to LAFS), cost accounting should be doable with traffic accounting.

In a federated way one could also have local web proxies to local
tahoe processes and do DNS round robin or more sophisticated load
balancing to make data available.

Criticism and warnings as to the vulnerabilies of tinyproxy or the 
setup are invited and welcome, or suggestions for alternative low-memory 
proxies. 

Avi