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 prv.app.example-com.sync.files.home.jai.note-txt.

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:

• You can monitor changes to the entire filesystem with a single subscription
• All changes are atomic - it's easy to avoid having files and/or file hierarchies in inconsistent states (e.g. when renaming a file there is no a scenario where both the old and the new filenames exist)
• Automatic deduplicating - since identical files will resolve to the same hash, they won't be stored more than once
• Trivial snapshots and rollbacks - if the root block contains the hash of the previous root, it forms a linked list of every revision to the filesystem since its inception. Retrieving or rolling back to a snapshot is as simple as using an old root block as the current root. And because of the inherit dedeuplication it's only storing deltas between the revisions.

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.

Next: Social Media (Facebook)