[tahoe-dev] Sharing directories? Friendnet build/configuration?

[Brian Warner]

On Sat, 12 Apr 2008 09:35:06 -0700
Jed Donnelley <capability at webstart.com> wrote:

> As I mentioned in my first message shared to cap-talk and tahoe-dev,
> I believe the above semantics are missing the distinction between
> read-only and "deep read-only" and actually only providing
> "deep read-only" - namely anything that is fetched through a
> read-only directory is itself made read-only (file or directory).
> 
> This "deep read-only" I think is the more important of the two,
> and perhaps simple read-only isn't worth the complication?  With
> simple read-only I could share a directory with you and you
> could fetch anything out of it without diminution (e.g. fetch
> a read-write capability to a file or a directory), but
> you could not change the entries in the directory (e.g.
> delete or add anything).

Welcome Jed!

Our "mutable file" objects have both read-only and read+write caps, in which
the read-only cap is derived from the read+write one. In ocaps terms, the
read+write cap is a reference to an object which gives you two abilities: the
ability to change the contents of the file, and the ability to retrieve a
read-only reference. The read-only reference has only one ability: reading
the contents of the file.

(Immutable files, of course, have just the read-only cap).

Then we have "directory node" objects that are based upon mutable files.
These are really just a way of interpreting the contents of a mutable file.
By encrypting the write-caps of the child objects (whether they be files or
subdirectories) the right way, we achieve transitive readonlyness, aka "deep
read-only", which (as you've pointed out) is far more useful.

So there isn't really a "shallow read-only" cap. If we didn't do the
encrypted-child-write-caps trick, then the ability to read the underlying
mutable file would be a shallow-read-only cap, but then we wouldn't have any
way to provide deep-read-only caps. Choosing where to place and protect the
child write caps forces us to pick between the two options, and we went with
deep-read-only.

Incidentally, we're thinking about introducing another level in our next
design: see http://allmydata.org/trac/tahoe/ticket/308 for details. In short,
there are actually three levels of access for mutable files: write, read, and
verify. We're talking about adding a "deep-verify" cap to dirnodes, which
would allow the holder to verify the integrity of the directory, and all of
its children, but would not allow them to see the plaintext of anything. This
"deep-verify" cap would also allow the holder to total up the amount of space
consumed by the directory and its children, which is obviously of use to a
company which wants to charge for the storage being provided but which
doesn't want to be able to see the files being placed there.

> My main practical interest in the Tahoe file system is to
> set up what I believe your documentation refers to as
> "friendnet" - where I set up file sharing using Tahoe
> between, say, 10 friends/colleagues.
> 
> Can anyone give me a rough idea of how much work it is likely
> to be for me to set up something like that?  How much work
> on my system(s?) and how much will be needed for my
> friends/colleagues if I've done as much of the leg work
> as possible?  The discussion about the build didn't look
> too bad (which I assume I'll need), but at this point I
> don't know how much configuration will be needed and what
> I'll need for an "introducer" (just from memory).

It's quite easy, by design.

 1: build and/or install tahoe on all systems. When 'tahoe --version' works,
    you're ready. The pre-built debian packages might be useful to you.

 2: choose a system to host the introducer. Run
    'tahoe create-introducer ~/introducer' and 'tahoe start ~/introducer'.
    Copy the ~/introducer/introducer.furl file out of that node and publish
    it where all your friends can see it.

 3: each friend should do 'tahoe create-client' (which defaults to creating
    it in ~/.tahoe/, but you can override that), then copy the introducer.furl
    into their ~/.tahoe/ directory, then run 'tahoe start'.

That's it! The create-client step configures the new tahoe node to run a
webserver on port 8123, so once the tahoe node is running you can point a
browser at http://localhost:8123/ and see your node's status page. From that
same page you can create your first directory (don't forget to bookmark it!)
and jump to caps pasted in from others.

Take a look at the docs in the source tree
(http://allmydata.org/trac/tahoe/browser/docs), particularly the
"configuration.txt", to get a feel for what other knobs are available for
controlling your node.

Note that the clients must be able to see each other, at least, everybody
needs to be able to make a TCP connection to the introducer, and at most one
client node can be behind a NAT box or other one-way network filter. If that
is not the case, then some nodes won't be able to see each other, and
reliability will suffer as files are stored on a subset of potential
locations. Tahoe does not yet do any sort of NAT traversal or relaying.

hope that helps,
 -Brian