[tahoe-dev] One Grid to Rule Them All

[Callme Whatiwant]

Hi Avi!

On Fri, Jun 28, 2013 at 9:56 PM, Avi Freedman <freedman at freedman.net> wrote:

>
> Dear Comrade Nathan,
>
> My first thought was that one could publish hashes of readcaps into DNS,
> where the DNS response would be the introducer for the cluster.  But...
> With the introducer furl I think they could upload as well as retrieve.
>
>
Oh, I like this idea!

I believe it's true that introducer's have only a single furl and that
grants access to both register a node as well as to retrieve the list of
nodes.

Having two separate furls for registration versus lookup seems like low
hanging fruit to me, although I wonder how that interacts with the
accounting feature set.  This wouldn't prevent uploads, because the storage
servers make that decision (and currently they always grant new uploads,
AFAIK).


So a complementary feature to that strategy is to make a
"multi-introducer-aware" web interface, and perhaps to have "global caps"
which include an introducer furl in the filesystem cap.  If there's also a
"registration separate from lookup" two furl feature, then this new "global
cap" scheme would only rely on the lookup furl (regardless of if a cap is
read or read/write).

I recall Brian Warner describing something like this, or something similar
involving separate federated grids, as one of the various alternatives to
the "global grid".  Brian, can you clarify your design brainstorms along
these lines?

We've been looking at something related for Havenco, which is getting
> ready to launch LAFS and S3 bucketed storage using private nodes per
> customer (to solve the lack of accounting).
>

Exciting!  I'll keep an eye out for future announcements.



>
> One question that's come up is how users could share LAFS-stored
> data without giving away the keys to their cluster (for uploads).
>
> We haven't implemented it yet but it'd seem pretty simple to have an
> nginx proxy that sat on a public port, accepted caps using the same URL
> as the tahoe-lafs web server:
>
>
> http://x.y.z.q:3456/file/URI%3ACHK%3Acbb4d3bb6dgiqwiygidqolabve%3Ag6jf2rutbf3pzeltxytm5tbf3f3xu2hhj2yrbnn4vcw2nvrrs4va%3A3%3A10%3A4720/@@named=/tahoe-test
>
> That just proxies to a local tahoe-lafs web server bound to localhost.
>
> Then you wind up sharing a URL instead of a cap.
>
>
As Leif mentioned, that's the goal of lafs-rpg (which is basically just an
nginx configuration template).



> Adding in basic auth would be pretty simple as well if desired, though
> in the LAFS religion that would be heresey (sorry, not sure if you believe
> in religion, Comrade).
>
>
Not at all.  The beauty of caps is that it's convenient to implement other
access control mechanisms on top of them.  For example, a "Web Drive"
product might be a thin layer between users and LAFS storage which maps
their user credentials to LAFS caps internally to express particular access
controls.


[snip...]

Complexity could be added with having a DNS db of cap <-> cluster
> public-facing web sever options.  If there was interest we could
> build and run something like that, at least to the level of millions
> of caps.  Doing so for billions+ would need some of the economic
> incentives to which you were referring.
>
>
One issue I see with this DNS service is that it's centrally administered
(or else the utility is lessened).  I like how it could be very usable
though, if done right.

[snip...]


> Avi
> (a part-time Havenco bit janitor)
>
> > The time has come to shed our conspiratorial pretense of being nothing
> but
> > small disparate bands of neighborly do gooders sharing storage with their
> > friends.  It is time to reveal to the world our true conquest of world
> > domination and announce our intent to create The One Grid to Rule Them
> All!
>
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130701/b7bb3ca0/attachment.html>