Create something shareable

My friend Joseph Perla is taking a year off from his undergraduate degree. Joe has created a rare opportunity for himself to spend his time any way he pleases. To be honest, I’m a little jealous of him – for a long time, I’d dreamed of living alone for a few months in a sunny, comfortable cave with high-speed internet access near a supermarket and a pub, just to think and read and write and code.

We talked about how to fill this period meaningfully. It would be pretty easy to fill a year reading RSS feeds and masturbating, though this would leave you with little to show for your time. I want to have some more substantive impact on the world around me. To be able to look back on my time spent with pride. To do something worthwhile. Joe and I talked about how to decide what projects would be worthwhile, and this was the metric I suggested:

Create something shareable.

Add to the sum total of human knowledge. Create something that others can use.

To be shareable, it has to be useful. It has to be trustworthy – if it’s flawed/buggy, or its conclusions are ill-founded then it could actually be of negative value. It’s probably going to require some effort, since if it was easy and quick, then it would be easier for other people to generate it anew than to internalize your solution. It probably needs to synthesize or improve upon what already exists, maybe surprising us or overturning existing intuitions.

The internet provides the medium for distribution, advertisement and collaboration. Commoditized hardware, open source software and freely available information provide the tools and raw materials.

This validates a whole host of online activities. Write carefully considered opinion pieces. Build up a corpus of entertaining posts to create an online persona. Gather interesting tidbits. Develop your art in whatever form it appears. Maintain an existing piece of open source software or create a Debian package. Write a new application or library. Edit wikipedia articles. Release your photos under a Creative Commons license. Put your notes online. Provide instructions for building cool things. Share your tools. Run a controlled experiment on yourself. Curate a dataset. Write a scientific paper and make it easy for others to replicate it. [These links are just some of my favourite examples of each activity].

Entangling the ground and cloud

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
the ground.

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.