[tahoe-dev] about private directory management in tahoe v0.7.0

Brian Warner warner at allmydata.com
Thu Dec 20 22:31:05 UTC 2007


> Brian:
> 
> Do you want to be free of tahoe-related e-mails over your winter  
> vacation?  

I'll opt-in, although I'm not online as much as I am when I'm in the office,
so expect some delays.

> So this "create a new directory" button is a better implementation
> of private directories than the automatic private directory is,  

yeah, I agree

> except that the command-line tool's "-r private" option will not know
> the URI (capability) for the newly created directory.  

Yup. Need to address that.

> I've already been thinking that the notion of a private directory  
> created automatically by the node when it first starts up is a bad  
> match for our use cases, because it makes the most sense when the  
> node is for a single user, and the node is running on the same  
> filesystem that the command-line tool is running on.  This does not  
> match most of our current use cases, where one node may serve  
> multiple users, and where the command-line tool might be running on
> a separate filesystem from the node.  

> I propose in v0.7.0 to remove the notion of automatic creation of a  
> private directory by a node and replace it by explicit creation
> using the "create a new directory" button.  Then I propose that for
> v0.7.0 the user chooses which directory they want the command-line
> tool to use by default, and they manually copy the cap of that
> directory into their "private/my_private_dir.cap" file.  

So, I'm mostly in agreement with you, but I remain concerned about usability,
and I think the local-node CLI use case is still an important one, especially
at this stage of the project where most of the users are hackers rather than
paying customers using some remote node.

I wanted to share a file with Peter earlier this week, and my natural
instinct these days is to upload it to our tahoe test net and IM him the URI.
With the removal of the public vdrive, and the lack of a button to create a
private dir, this was very difficult: I had to start my own node (this was
from my laptop), connect to the same testnet, open my automatically-created
private vdrive, create a new directory (so it would still be there once I
disconnected my laptop), then finally upload the file.

Having an easy-to-reach public directory makes it very very easy to explore
tahoe and figure out what it can do. The same is true for having an
easy-to-reach private directory. In some of the use cases we're designing
for, we'll be doing the directory management completely differently, but
without these easy ones I worry 0.7.0 will be a lot harder to use than 0.6.1
.. that some new users will set it up, run it, and then not see anything that
they can use, and then give up and walk away.

And the CLI tools without some kind of shortcut is, in my opinion, unusable.
Sure, you could always type 'tahoe ls -r 123abc456def...', but nobody would
use that. I intended the ~/.tahoe directory to be either a full local tahoe
node, or a place where the shortcut mapping lives (and containing the URL of
the remote tahoe node that's providing you with service). In either case the
usability of the CLI tool is derived from the secrecy of your ~/.tahoe
directory, since that's where the unguessable identifiers are stored.

In addition, I want to make absolutely sure that end-users can keep their own
secrets in all of our use cases. If a node serves multiple users, or if it is
on a different filesystem than the one the user has access to, this is
partially compromised, but I still want such users to be able to keep their
URIs on their own machine and only give them to the server node briefly and
when absolutely necessary.

So I like the idea of a button that says "you don't yet have a private
directory, press here to create one", which then takes you to the new private
directory. In this case, the easiest thing for the user to do is to create a
bookmark to this page, and use their browser to store their authority. Pros:
it only takes two clicks to set up, and there's no need to leave the browser,
and it gives the node enough time to connect to a bunch of storage servers
without needing to configure exactly how many it should expect. Cons: the CLI
tools don't get visibility, and if the user forgets to make a bookmark,
they'll lose their private directory forever (module browser history searches
and the like).

We definitely need to build a shortcut mapping of some sort for the CLI
tools. For folks who are only using the CLI tools, we could add a
'mkdir-root' command or something, which would make a new directory, print
its URI, and store it in a shortcut with a given name. The default name would
be 'private' (and of course it would not overwrite a shortcut by default). So
the first-time tahoe CLI user would do:

 tahoe create-client
  echo "BLAH" >~/.tahoe/introducer.furl
  (or maybe we make 'tahoe create-client --introducer BLAH')
 tahoe start
  (pause for half a second, let the connections get established)
 tahoe ls
  -> error, no private directory yet, use 'tahoe mkdir-root' to create it'  
 tahoe mkdir-root
  -> created directory, cap is 'BLAH', stored as shortcut 'private'  
 tahoe ls
  -> empty  
 tahoe cp ~/tractors.jpg ./
  -> copying file into 'private' virtual drive  

Moving secrets between the CLI realm and the web realm *does* require
explicit extra steps. The 'start.html' is a bridge from CLI to web. Modifying
config files or a hypothetical "tahoe add-shortcut 'name' 'URI'" command
would be the way to copy your web bookmark and set it as a shortcut that
could be used by the CLI tools.


So, having ranted for a while, do I agree with your proposal? Yeah, I guess I
do. I think we should add an error message to the CLI tools (displayed when
private/my_private_dir.cap doesn't exist) explaining what needs to be done to
make the shortcut forms work. Also, I guess my_private_dir.cap should
tolerate either a straight cap or an http:// prefixed one, to make it easier
for people to paste in their web bookmarks (also, we might need to
un-urlencode it if there's an http prefix, I think sometimes the browser's
address bar shows a form where the colons get encoded).

For 0.7.1, we need to create a CLI mkdir command, and we should settle on an
approach to shortcuts; then we can decide how easy-vs-manual the setup
process should be.

This implies that start.html will go away altogether, right? I like that. I
think it also implies that browser bookmarks will become more important than
they were in 0.6.1, being the most natural place to remember your top-level
directory.

cheers,
 -Brian



More information about the tahoe-dev mailing list