The cloud and the ground
Most of you will have an idea of what I mean by ‘living in the cloud’. The cloud is the internet, the web, ssh servers, http protocols and text boxes in browsers, accessible from anywhere, hosted on a server or many servers somewhere. Wikis, blogs, and bookmarking services like del.icio.us are the cloud. We travel to the cloud on a flying TCP/IP rug, whisking us from anywhere in the world to wherever it is the cloud is. The cloud is available to us everywhere, as long as we have internet access. Its non-local ubiquity is its virtue.
In contrast, the ground is our hard disk, .doc files and desktop applications, our personal computer, local, physical, heavy, awkward, something we carry around with us. Distance means something on the ground, because if you don’t have your laptop with you, you can’t get to your ground-home.
Perhaps I’m being crystal clear about what I mean by ‘cloud’ and ‘ground’. In case I’m not, we can boil the distinction down to this: the cloud is everything that we need the internet to access. The ground is everything that lives on our personal computer. The tradeoffs are obvious. The cloud is always there as long as you have internet. The ground is always there if you’re willing to tote around your computer.
The filesystem as carpet
We talked earlier of the network whisking us to the cloud like a many-threaded flying rug, a wizardly tapestry of protocols. But if the network is a rug that whooshes us from one location to the other, then perhaps we can think of the filesystem as akin to an everyday carpet – the flat, underfoot, non-vehicular kind that sits there as you wander about, so permanent as to remain quite unnoticed. On the ground, all of our files rest on the homely, woven fundament of the filesystem carpet. If you want to edit a document of any kind, you’re editing a file on the fileystem. This is what gives the ground its feeling of stable proximity. You can’t fall off the ground.
But what if, in the future, the faded paisley pattern of your local filesystem carpet hid a kind of quantum entanglement, where “the quantum states of two or more objects have to be described with reference to each other, even though the individual objects may be spatially separated”? What if the carpet in our home on the ground and the carpet in our home in the cloud were entangled? A long-standing, two-way, lightning strike beanstalk linking cloud to ground, and ground to cloud. I would be able to pootle about on the ground, knowing that the cloud is synchronized. So that when I leave my laptop home at home, the cloud has mirrored everything I need. I want my toothbrush to always be there, waiting for me, in my home and my home-away-from-home.
Every file appearing to rest so solidly on the filesystem-carpet would also sit on the cloud-carpet above. And vice versa. Every time you edit a file on the filesystem-carpet, the changes are propagated automatically to the simulacrum on the cloud-carpet, and vice versa. You think you’re editing C:\blog\my_new_post.doc, but when you save, http://gregdetre.blogspot.com/ updates. You just tagged a page with ‘superduper’ on http://del.icio.us/gdetre, and a new .xml file appeared in ~/del.icio.us/superduper/ at the same time. In this hopeful future, where our home on the ground changes in lockstep with our home in the cloud, the question of whether we live in one or the other becomes meaningless to the user – when you light one candle from another, which one carries the original flame? Equally both. Either. When I edit a document, on ground or cloud, I want that document to exist equally, indistinguishably on cloud and ground.
If and when the ground- and cloud-carpets do become temporarily untangled, while on a plane or because of a wireless malfunction, then any changes made in either cloud or ground are stored up to be replicated at the very first opportunity, bi-directionally, automatically, and in the background.
What would it be like to use an entangled filesystem?
Everyone will have some space of their own in the cloud. When you first install your operating system, it will ask you for your cloud-home Open ID address. When you post a comment on Slashdot, the sign-on process causes a new directory to appear on your hard disk. All of a sudden, ~/slashdot.org/article/492308/comments/2309109.txt appears on
Every directory on your hard disk will be mounted with a cloud-address that automatically provides a ground-cloud mapping schema for that directory. All websites will provide a unique URL for every state or view into the system – it’ll be the job of the ground-cloud mapping schema to map those URLs to files and directories, specify permissions, decide which file format your content will appear as, define the effect filesystem actions have, etc. So perhaps editing 2309109.txt would change the comment on the actual Slashdot page… unless the ground-mapping schema says that comments can’t be modified once written, in which case 2309109.txt will appear as read-only once it has been moved from the ‘drafts’ directory where you created it.
Right now, the browser is the main gate through which we pass to get into the cloud, but it needn’t be. No one wants to have to type a whole new wikipedia entry in a poxy text box. Much nicer to fire up MS Word or emacs, and work on c:\wikipedia\Carpets.wiki in comfort (effortlessly mounted as a wikipedia service).
We’re so close already. On the one hand, tools like Subversion and Unison handle synchronizing pretty well. On the other hand, we can mount remote filesystems over SSH with Fuse SSHFS or Emacs Tramp, so that they almost feel local. So there are tools that sync, and there are tools that make the remote feel local, but there are no tools that do both: automatically sync the remote and make it feel local … running in the background in perfect imitation of a filesystem.
Tim Bray sounds a stirring clarion call for ‘a “Publish” button on everything’. That’s a solution at the level of the interface. I’d much rather we build publishing into the very heart of the system. I don’t need a “Publish” button. Just let me save my files to a ground-cloud entangled filesystem, and have them simultaneously published for me.