Design Sharing & Permissions

Start by getting the shape right, because sharing at Dropbox is not a copy operation. When you share a folder with a colleague, their client does not receive a duplicate of your files. Dropbox models a shared folder as a namespace, a self-contained subtree of the filesystem, and mounts that same namespace into every member's tree. Two people who share a folder are pointing at one namespace from two places. A permission is then an edge in the metadata graph, a record that says this principal has this role on this namespace, and granting access is writing that edge. No bytes move. Keep that in front of you, because it is the fact that makes the whole design cheap. Sharing touches small metadata, never the huge immutable blocks the files are made of.

From there the problem has three moving parts, and the round spends its time on the seams between them. First, storage of the access rules: where do you record who can see a namespace, and how do folders inherit permissions down a tree. Second, the write side. When an owner changes a folder's members, that change has to govern every descendant, and a busy team folder can hold millions of them. You cannot afford to rewrite each one. Third, the read side: every file open, folder listing, and sync delta has to answer "is this person allowed" before it returns anything, at a rate that dwarfs the rate of permission changes. Build the model first. Then spend the back half on making the change cheap to apply and the check cheap to run.

The Dropbox angle

Because Dropbox stores every file as content-addressed blocks that are deduplicated in Magic Pocket, sharing is purely a metadata operation and never copies a single byte. A file is an ordered list of block hashes, and those blocks already sit once in the immutable blob store regardless of how many namespaces reference them. Adding a collaborator writes one access edge onto the namespace, and the blocks the file is made of are untouched.