[tahoe-dev] storage-club URLs

[Ravi Pinjala]

On Tue, Feb 22, 2011 at 8:49 PM, Brian Warner <warner at lothar.com> wrote:
>
> 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.

Oh, I hadn't thought of that, I was really only considering relative
links. Hmm. Stable incoming links might be complicated, if we don't
want to depend on the DNS D:

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

Mmm. I'd still feel a lot better about it if there was something
Tahoe-specific in there. If "sha-256-*" is a common pattern for YURLs,
then the only thing really identifying a Tahoe URL would be the
"/u/filecap", which feels a bit thin. Issuing a request to a fixed
path on the domain sounds okay, though. As long as a modified client
can unambiguously tell that it's talking to a Tahoe grid, then it
should work.

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

Hey, neat! That might be something worth exposing to the grid admins -
I can think of a couple ways to use that. If I was running a large
grid for a business, for instance, I might want to give a key to each
group, and let each of them manage keys for their users.

YURLs actually remind me a lot of SFS
(http://www.scs.stanford.edu/~dm/home/papers/mazieres:thesis.ps.gz),
where key information is encoded in filesystem paths, and symlinks
authenticate resources just by referring to them. I wonder how related
the two actually are.

> 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
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>