Communion v. Publishing

There is a lot of talk in the tech community of replacing services like Facebook and Twitter with more open, distributed alternatives. The idea is that you should be in charge of your data, not your social platform provider. This idea makes sense, except that there are two types of content that people publish online, and each provides a wholly different value proposition.

The perfect social network has always been the Web itself. We’ve got a variety of protocols to traverse it, from HTTP for the pages, to something like Atom for our subscription feeds. The only requirement to having your own presence? A domain name. You don’t even have to buy one, but getting a hold of one makes things easier. You can point it to a different server any time you like, so whenever you change hosting, you simply update the domain. You’re in control.

The easiest way to manage a contact list is to keep an address book. The simplest way to update your friends of your contact information like your email address is to keep your own website with that information on it (or with things like a contact form if you care about protecting yourself from spam). Yes, not everyone can set up their own website, but there are services that can help you do it (e.g., and perhaps this is an area that still needs to be improved. The simplest solution is often the best, and right now I’d say this is the simplest solution in the long run.

The real social network is of course the real world. The Web we use daily is an abstraction layer that goes over the top of the real world, and social networks built on the Web are in turn a sub-layer of the Web, that is, they provide a small piece of limited functionality of what the full Web allows, in some ways convenient, yet also very restrained.

The stuff that you want to keep, e.g. your writing and your photos, you should keep on your local computer, as well as backed-up somewhere else as well. You then publish it onto the Web via a variety of services. The separation is important because not only do you get to take care of your own data on your own terms, ensuring it is backed-up properly, you also have a selection filter to go through – in other words: you get to pick what is worthy of getting published, and what is not.

The Web is not a stream, contrary to what some people think of it or want it to become. It should never be a stream because in such a state it becomes an unfiltered flow of data, which is: 1) filled with noise, and 2) relieves people from their duty to judge and select – and no, my use of ‘duty’ in this context is not too strong because if you grant me that the purpose of morality is to help us become better people, then it follows that what is being published by us should also be scrutinized since it is reflected back on us, being the measure of us as creators of our world. It’s not a crime to publish something subpar, but it is an altogether different thing to avoid – or be incapable of – passing judgement on your work altogether, which is what a Web as a stream would accomplish.

That said, streams have their place on the Web as services that satisfy certain purposes. This is not contrary to what I’ve just said because the above is talking about the workings of the Web as a whole, rather than of specific sites. Those specific sites that work as streams accomplish goals that are quite different to that of publishing content that you want to last.

Microblogging streams such as that on Twitter, as well as streams of certain photos and videos, are transient content by their nature. This means that their value lies in the moment that the content is shared, being created by the experience of communicating the moment or thought with other people, and seeing their reactions. It’s a method of communication, of communion even.

But storing such content for later? That’s useless. Its value has come and gone, and now what remains are bits of noise that nobody wants to see again. A microblog like Twitter lives in the present, a good blog is written for the future. This isn’t set in stone, and there will be a mixture of content within any blog, some posts holding more value in the present, others retaining it just as well for the future. The measure of a good blog however is how much its content is skewed towards the latter, the more timeless it is, the greater its value. Microblogging content can too be mixed, but the amount of long-lasting content compared to transient content published on such sites is insignificant.

This does not mean it is valueless, only that its value lies in the present only. This contrasts with content that retains value in the future: good blogs, photographs, videos and so on, retained either as content worthy on its own merit, or as valued memories that you wish to keep with you as the time passes.

As such, people want to keep one, and discard the other. Discard is probably the wrong word here, what they really want is to derive the value in the present and then let the content fade away as it may, like old leaves floating away in the autumn having done a season’s worth of work, content to turn to dust knowing their job is done.

This distinction means that services catering for transient content like microblogging and photo stream sharing, are well suited to live on the Web under the banner of social service providers. Users are happy to give their data to someone else, and indeed won’t care whether they can even get it back at a later date. What they want is a service that facilitates an experience of sharing something with their friends, of experiencing something together as a simple conversation, not as a creation of something meant to last. People are not writing essays or articles here, just chatting. This means that as long as the Twitters and Facebooks of this world are able to deliver a good enough user experience, people will happily keep using their services.

On the other hand we have services that focus on publishing, like WordPress for your blog and Flickr for your photos. Here, you’re publishing content you want to last, either as memories for yourself for the future, or as something that stands up on its own. The effect of communion is still there: you likely get comments on your photos and on your blog articles, but the value proposition does not lie in that communion alone. It’s why these services provide ways to export and import your content. These types of services are foremost publishing, not social, platforms.

Here you still have the issue of who holds the data. In some cases you keep the data on your local machine and sync it to the server. This is the best option. In others, you create stuff on the server directly, like posting to a blog platform. This is less ideal because: 1) you don’t have all your stuff should you want to publish it somewhere else and 2) you don’t control the back-ups, meaning that someone else’s mistake may cost you your content. Publishing services, unlike social services, almost always give you export options, but the ideal is to have a sync mechanism that pulls selected content from your machine to an external server, rather than keeping all your on the server, like all the eggs in one basket. This is where having control over your data really matters, and the best publishing mechanism is the one that respects this.

The aim of social services is to provide communion, that is: to provide a shared experiences around the pieces of content that users post. The aim of publishing services is to let you publish content on the Web, with the ultimate purpose of that content being up to you. The former deals with transient content, the value of which lies in the experience of sharing it rather than in the content itself. The latter deals with a mixture of content, with the better types being longer-lasting. In the former case, the services that provide the best communication experience are successful, which is what the users care about, not the content itself. The latter case is the one where content ownership does matter, and where efforts should be made to make publishing of content easier through syncing rather than posting directly to someone else’s server.

August 2012