[tahoe-dev] storage-club URLs

[Brian Warner]

On 2/22/11 7:32 PM, Ravi Pinjala wrote:

> There is a lot about this that I like. :D A few questions:

Excellent questions!

> - When you talk about the tahoe-lafs.org dyndns service, you really
> mean a federated system where anybody can host a grid on their own
> domain, right? :) I feel like that's probably what you mean, but it's
> not actually clear from the text.

Oh, absolutely. I think we (as the tahoe project) should operate the
default dispatcher for the common good (so users don't need to do
anything special to get up and running), but it should be easy for
anyone who wants it to override the default and use someone else's
dispatcher, and/or run their own. Imagine "tahoe admin
create-gateway-dispatcher BASEDOMAIN". I dunno if that's what
"federated" means here, but I think we're thinking the same thing.

> - In that same vein, it'd be really cool if grids could use multiple
> independent dyndns services, running on multiple domains. (Ideally,
> they'd be domains from multiple countries, so that the grid isn't
> dependent on any one country.)

Yeah, good idea. The problem I imagine is how to decide what hostname to
use for the URLs. I can easily imagine grid-123 registering both as
$PREFIX.club.tahoe-lafs.org and $PREFIX.club.random.fr, such that any
URL path that works on one also works on the other, but I don't see how
that benefits a static HTML page with a link pointing at the
tahoe-lafs.org URL when .org is taken down. Maybe it'd be enough for
publishers to tell their users to edit their URLs to point at the new
domain, and then use relative URLs in the content so the links still
work.

> - When you talk about clients recognizing the "tahoe-ness" of URLs,
> what did you have in mind? Pattern-matching on the URL would be pretty
> easy to implement, but fragile

Yeah, I was thinking pattern-matching. The "sha256-..." prefix of
$PREFIX and the /u/FILECAP in the path are pretty distinctive. Or maybe
the plugin should be configured with a list of "*.club.tahoe-lafs.org"
DNS suffixes which might possibly be used in this fashion. Or maybe if
the plugin sees "sha256-" and "/u/FILECAP" then it does a GET at the
parent domain: http://club.tahoe-lafs.org/are_you_a_dispatcher and does
the tahoe-like path iff that GET returns a magic number that tells us
this domain really is for dyndns stuff.

> the best solution I could think of would be a Tahoe-specific TXT
> record on the domain, but that raises the bar a bit for running a
> dyndns dispatcher. Using tahoe:// as the URL scheme would be pretty
> cool, but I suppose it wouldn't work for unmodified HTTP clients.

Right. For modified clients, we can just use filecaps.. the goal here is
to make something that works for unmodified browsers, but works even
better for tahoe-aware ones.

> - Having a shared SSL key makes me nervous, if the key is going to be
> encoded into publicly-visible URLs. It seems like it would be very
> difficult to change the key if it leaked. Maybe a multilevel scheme
> could work, where there's a secret key held by a few trusted grid
> members, and individual gateways have unique private keys that are
> signed by the secret grid key.

Oh, good point. Yeah, that ought to work: each gateway creates a
separate key, the "gatekeepers" share another key, they sign the gateway
keys, and $PREFIX is the hash of the gatekeeper key. I think Tyler's
YURL scheme actually works more like that: the client will accept any
cert chain that contains the $PREFIX cert, even if it's not the leaf.

None of the invitation/storage-club schemes I've pondered so far
establish a multilevel scheme; they've all been completely egalitarian.
I'll have to think about what the UI would look like for that: you'd
mark some peers as "gatekeepers", and everyone else gets the "gateway"
flag turned on by default, but gatekeepers can turn off the gateway
flag.

cheers,
 -Brian