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

[zooko]

Brian:

Do you want to be free of tahoe-related e-mails over your winter  
vacation?  If so, disregard this one.  If you don't mind receiving  
this stuff, then please let me know -- it is "opt-in" after this one.

I still have an open issue with the creation of the private  
directory: #233 "work-around the poor handling of weird server sets  
in v0.7.0".  The current behavior is that when you create a new tahoe  
node and start it, it (usually?) creates a private directory with all  
of the shares stored on your node.  This means that if that node is  
not reachable later then you won't be able to access your private  
directory, and if that node's hard disk dies then the directory will  
be gone.  Ticket #233 says that we should work-around this behavior  
for v0.7.0.  There are other tickets to improve management of the  
private directory after v0.7.0: #213 -- "good handling of small  
numbers of servers, or strange choice of servers", #232 -- "Peer  
selection doesn't rebalance shares on overwrite of mutable file.",  
and #234 -- "Nice UI for creation of private directory."

It occurs to me that #115 -- "distributed dirnodes" -- which is also  
required for v0.7.0, has these these items remaining to implement:

  * add "?redirect_to_result=true" flag to request an "HTTP 303 See  
Other" redirect to the resulting newly created directory
  * add a form to the welcome page to create a new directory and  
redirect to it

Once this feature is in, then there will be a button on the welcome  
page that says "create a new directory".  When you push that button,  
it will create a new directory which is private in the sense of not  
being readable or changeable by anyone other than you, and whose  
shares have been spread out over all servers which were connected at  
the time that you pushed the button (up to M, where the default value  
of M is currently 10).  I remember you suggesting this as a cleaner  
way to solve the problem that the "wait_until_numpeers" argument  
attempts to solve.

So this "create a new directory" button is a better implementation of  
private directories than the automatic private directory is, except  
that the command-line tool's "-r private" option will not know the  
URI (capability) for the newly created directory.

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.

Having a manual step like that to set up the command-tool isn't  
ideal, but it is good enough for v0.7.0.

Regards,

Zooko

tahoe tickets mentioned in this e-mail:

http://allmydata.org/trac/tahoe/ticket/115
http://allmydata.org/trac/tahoe/ticket/213
http://allmydata.org/trac/tahoe/ticket/232
http://allmydata.org/trac/tahoe/ticket/233
http://allmydata.org/trac/tahoe/ticket/234