[tahoe-dev] Fwd: Tahoe

[Nathan]

On Wed, Apr 2, 2008 at 9:33 AM, zooko <zooko at zooko.com> wrote:
> Ben Laurie wrote:
>
>  > So, I'm quite excited about Tahoe, and I even managed to build it
>  > on FreeBSD (on which I will blog at some point soon).
>  >
>  > But ... the documentation sucks! I can get the web interface
>  > working, but I've complete struck out on the command line.
>

... (snip)

>  > Seems to me I should be able to do something like, say...
>  >
>  > bin/tahoe ls -d http://193.133.15.7:8124/uri/
>  > URI:DIR2:djrdkfawoqihigoett4g6auz6a:jx5mplfpwexnoqff7y5e4zjus4lidm76dc
>  > uarpct7cckorh2dpgq
>  >
>  > and get a directory listing. But apparently not.
>  >
>  > bin/tahoe:  --dir-cap must be a dir cap (or "root"), but we got
>  > 'http://193.133.15.7:8124/uri/
>  > URI:DIR2:djrdkfawoqihigoett4g6auz6a:jx5mplfpwexnoqff7y5e4zjus4lidm76dc
>  > uarpct7cckorh2dpgq'.
>
>  Ah, this isn't a problem in the CLI precisely, but in the parsing of
>  capabilities.  If your capability had started with a string matching
>  this expression:
>
>  # URIs (soon to be renamed "caps") are always allowed to come with a
>  leading
>  # 'http://127.0.0.1:8123/uri/' that will be ignored.
>  OPTIONALHTTPLEAD=r'(?:https?://(?:127.0.0.1|localhost):8123/uri/)?'
>
>  (code snippet from http://allmydata.org/trac/tahoe/browser/src/
>  allmydata/uri.py )
>
>  Then it would have worked just as you expected.
>
>  Perhaps that expression should be broadened to:
>
>  # URIs (soon to be renamed "caps") are always allowed to come with a
>  leading
>  # HTTP string that will be ignored.
>  OPTIONALHTTPLEAD=r'(?:https?://(?:[0-9]+.[0-9]+.[0-9]+.[0-9]+|
>  localhost):8123/uri/)?'
>
>  or even something like:
>
>  OPTIONALHTTPLEAD=r'(?:https?://(?:[0-9]+.[0-9]+.[0-9]+.[0-9]+|[^:]+):
>  8123/uri/)?'
>
>
>  ?

Something about including an ip address in the url has always bothered
me, and this exposes the issue.  The tahoe cap is only loosely related
to the network location field of the URL, and that mismatch will lead
to UI bugs (as well as potential security vulnerabilities, as in the
case of the local domain in IE6).

The wider regular expression will fix this particular use case, but
when a friend sends Ben a link he'll have to edit the URL before he
can follow it.  This undermines the concept of "sending a link" in my
mind, and further illuminates the mismatch between caps-as-links and
http urls.

Would it be feasible to make the urls which encode caps looked like this?
tahoecap://<encoded resolution data>[/<directory_path>][?<query_params>]

Three (and a half) questions:

a. How many contexts would fail to recognize this as a url because
those contexts only grep for well-known schemes?
b. How much work would it be to create a (web/file) browser extension
to support these urls?
c. In contexts which recognize this as a url but don't understand the
scheme, what is the user experience like?
(d. Does this proposal violate the spec definition for url?  And if it
can be implemented, who cares?)

In my mind the focus of b should be to pick a single target browser,
and once support is implemented try to use that as leverage to push a
standard.

A quick test reveals partial answers to b, and c, by typing
"tahoecap://a454lkj54/foo.html" into the firefox location bar: A modal
dialog appears which says "Firefox doesn't know how to open this
address, because the protocol (tahoecap) isn't associated with any
program."

This implies you can associate programs with protocols.  If we pushed
Firefox to treat missing protocol handler apps exactly as they do for
missing render plugins (by displaying a link to a page of well known
suppliers), that would be a major win for this approach (for this
single browser).

If that was the case, Tahoe could register a protocol handler with the
Firefox plugin directory.  Finally, if all this was accomplished, a
typical user could send a Tahoe link to another (firefox) user who
does not have Tahoe, and that user will be able to proceed all the way
to downloading that file starting with no outside information except
the link (and firefox).

Does anyone know any firefox developers?

Nathan