File Synchronization (Dropbox)

Edsu is backwards compatible with the web (via websockets) but it's actually a sibling protocol. This, combined with the fact that it was designed with embedded systems in mind (i.e. <1MB memory, <100Mhz), makes it well suited as a bridge between all kinds of systems, including in this case long-running services for desktops.

For an OSS Dropbox replacement, there needs to be a daemon that monitors both the desktop filesystem and the online storage and synchronizes the two, as well as a web UI which can configure the service and download, upload, and create sharable file URLs using just the browser.

In terms of organization, at first glance one might be tempted to look at file paths, then look at Edsu names, and try to use them the same way: e.g. /home/jai/note.txt mapping to

But this would not only be impractical (permissions would be very cumbersone, for example), but also miss out on some of the major benefits of content-addressed storage.

Instead, if a filesystem is stored in a tree of blocks, with a single named block at its root, you get these benefits:

So a lot of the critical functionality of storage is addressed simply by Edsu being based on content-addressed storage (specifically a Merkle tree). On top of this, you can leverage Edsu's permission system so that only certain groups can access certain shares (with separate read/write permissions), use appendable block TTLs to automatically delete old snapshots, etc.

What's left is defining a filesystem storage format (essentially a block-based tar format, which would hopefully become a standard), then creating an Edsu-enabled FUSE-based daemon to run on the desktop, and finally building a statically-hosted webapp to configure the service and provide web-based file access.

Absolutely not trivial, certainly - this would be a big job. But it's a good example of Edsu's strengths in taking care of some of the most difficult parts of such a project: authentication, atomicity, and synchronization.