This post is the third segment in my series on an architecture for the social web. Previously: How social networks can replace email, which is a non-technical approach to the issues, and my follow-up describing how to build a social web architecture using available technology today.

So what about direct messaging?

In my previous post, I described content notifications in the social web as being Activity Streams updates in response to requests signed with an OAuth key. Each individual contact would have his or her own OAuth key, and the system would adjust delivered content depending on access permissions I had assigned to them.

A private message in this architecture could just be represented as an item of content restricted to a small set of recipients (in the email use case, this is typically just one), with replies delivered using Salmon. The advantage of this approach is that the message doesn’t have to be text; it can be audio, video, a link to live software, or something else entirely.

However, while this is technically feasible, it may not always be desirable. We know from Google Wave, which also pushes the boundaries of person-to-person messaging, that an open definition of what a message contains can get very messy very quickly. Although I was one of the first people to have one, I no longer check my Wave account regularly. I believe this is mostly a user interface issue: Wave is an awesome collaborative document editor (what I’ve heard described as “a massively multiplayer whiteboard”), but not in any way the evolution of email that its development team claimed.

Therefore, I think it’s useful to think about the difference between a document and a message:

• A message is the body of a communication.
• A document is a bounded representation of some kind of information.

While in many ways they’re the same, I think it makes sense to make a separation on the UI level. As we’re discussing a decentralized architecture here, some kind of semantic marker in our activity stream feed to mark something as a message would be a useful feature.

Messaging “out of the blue”

You know where you are with an email address. Mine is ben@benwerd.com. Anyone who encounters that string of characters, whether on a website like this one, a business card or a scribbled note on a piece of paper, is able to send me a message from anywhere in the world. In the 17 years I’ve had an email address, the list of friendships and business connections I’ve made, and opportunities I’ve received and developed, through this simple mechanism has been uncountable. It’s also likely to continue far into the future.

Compared to this, visiting someone’s social web profile and sending them a message from their web presence is a hassle. Compare these steps:

1. Receive the address of someone’s profile
2. Click the “follow” button either on the profile itself or on the toolbar of your social web compatible browser
3. Wait for the contact to follow you back
4. Send your message

To:

1. Receive someone’s email address
2. Send a message to that address

It’s simple, ubiquitous, decentralized and universally compatible. In fact, it seems hard to improve on, doesn’t it?

However, as this is a thought experiment about how social networking can replace email, let’s see if we can simplify this process somewhat. In my previous post, I discussed how a connection could be established with OpenID and OAuth through a web-based interface on a social web profile. How can we make this as simple as emailing someone, and cut out most of the steps I’ve listed above?

Connecting programmatically

I propose two additions to my previously discussed mechanism. The first is to expand the connection protocol to include a message. If someone connects to me on LinkedIn or Facebook, I receive some explanatory text from them, so it makes sense to include this feature in our decentralized social web architecture. It is likely that this would be an added parameter to the OAuth request token procedure.

The second is to allow connections to be made programmatically through a custom application. Just as we use email clients now, a social web client could automatically send a connection request. In keeping with our principle of using existing technology where possible, this is a simple OAuth connection request from the application, which includes a user message as described above. The application knows our details because we’ve set our preferences, so we’re never visibly redirected to a web browser to complete authentication. (In fact, this could take place using xAuth, a version of the OAuth protocol being developed for just these sorts of browser-free use cases.)

Whether we can send a follow-up message now depends on the receiving party. We have our OAuth token, and while it remains valid, the receiving social web node may choose to ignore any follow-up requests.

Our procedure has become:

1. Obtain address of someone’s social web node (you could even infer it using WebFinger)
2. Send a message to that node, bundled with a connection request

This is significantly better, and is comparable to the simplicity of email.

You may be wondering about the wisdom of adding everyone you contact as a connection. In fact, there’s some precedent for this already in applications like GMail. It’s important to note that not every connection need be a friend: in some ways, you can think of your total list of connections as your contact book. Some are important, some can be safely squirreled away until you need to contact them again. In this context (or any context where people you have a relationship with and people you’ve contacted are merged into one set), an adequate person management interface – or CRM to you and me – becomes important.

Next, and finally: let’s make our distributed social web architecture reliable enough to use in enterprise environments, using message queue protocols like ZeroMQ and AMQP.

Jane McGonigal’s TED talk starts out a little bit hokey, but rapidly evolves into an important new idea that could genuinely change peoples’ lives.

Jane was the community designer for I Love Bees, the infamous Alternate Reality Game that was released as a promotional endeavor for Halo 2. Her later work recognizes the importance that games play in society, and harnesses our impulse to play in order to create solutions to real-world problems. Her slogan – reality is broken; games designers can fix it – challenges our assumptions of what is worthy, and immediately offers a new line of inquiry. It’s at once a beautiful acknowledgement of the human condition and a practical way to effect real change using technology in an innovative new way.

Want to learn more? She’s put her research online.

Intersection: Publishing 2010 is a BarCamp which aims to discuss the future of publishing. There are a bunch of problems with the current models (for example, Amazon’s attempts at digital lock-in), and we want to get people from different backgrounds – publishers, authors, geeks, lawyers, marketers, academics – in a room to try and solve some of them organically and create some new ideas. It will be an informal, creative day.

You should come too.

It’s on April 17th in London, and is completely free. All we’d like you to do is either add your name to the wiki or let us know you’d like to come. (Even if you don’t do either of those things, you can still turn up on the day, but it helps us estimate overall attendance.)

I’m a technologist / lawyer / author / publisher / marketer / academic, but I don’t know anything about electronic publishing!

Doesn’t matter. In fact, so much the better. This is an emerging space, which needs new blood and fresh ideas. Your experience will help – and you’ll meet plenty of new contacts, with the opportunity for future business.

This is a great idea. How can I help?

Intersection: Publishing is already sponsored by the Stirling Centre for Publishing and Communication, but there are still some vacancies for other sponsors. Check out our sponsor page, or get in touch directly at info@intersectionpublishing.com or +44 7773 385 490. We’re also interested in volunteers on the day.

I can’t attend, but these issues interest me.

We’ve started an ongoing blog that will cover related stories and discussion. We’ll be posting there regularly, and are on the lookout for both guests and further contributors. If you think this could be you, get in touch.

I’m interrupting my scheduled series of posts about social messaging, because this is important. (The final part should appear tomorrow.)

Here in the UK, the Digital Economy Bill looks like it’s set to be rushed through Parliament:

There’s plenty to oppose in the Digital Economy Bill, it gives the government the ability to disconnect millions. Schools, libraries and businesses could see their connection cut if their pupils, readers of customers infringe any copyright. But one group likes it, the music industry. In a leaked memo a few days ago they admitted the only way to get the bill through would be to rush it through without a real parliamentary debate. Let’s stop that happening.

According to the Open Rights Group, there have even been questions about the Bill’s compatibility with the Human Rights Act.

The following is a letter I wrote to my MP, Andrew Smith. If you’re a British resident, I recommend you do the same (Boing Boing has a sample letter, but generally it’s a good idea to avoid form letters if you can).

Dear Andrew Smith,

I’m very worried that the Government is planning to rush the Digital Economy Bill into law without a full Parliamentary debate. Despite claims made by the BPI and others, I believe it will have dire consequences for British businesses, and therefore for the economy as a whole.

In short, the Digital Economy Bill provides the mechanism to arbitarily remove anyone’s freedom to communicate – their Internet connection, and potentially access to their website or servers – without due process. This will immediately put us on an uneven footing with countries such as the United States, who are already well ahead of us in terms of digital business. If Britain is to remain competitive in the digital world, this must not go ahead.

This is not to say that piracy should be allowed. It is undeniably a criminal act. However, for an issue that has become so culturally ingrained that it requires precise tactics to undo, these measures are unsubtle and counterproductive.

At the very least, a proper Parliamentary debate must be had.

As a constituent I am writing to you today to ask you to do all you can to ensure the Government doesn’t just rush the bill through and deny us our democratic right to scrutiny and debate. As a digital professional, I would be delighted to help with any questions you might have.

Kind regards,

Ben Werdmuller
ben@benwerd.com

Want to read the Bill for yourself? Here it is.

My previous post was a response to Gartner’s prediction last month that social networking would replace email as the “primary vehicle for interpersonal communications for 20 percent of business users.” In it, I named some properties that would need to be held by any social networking system that would successfully replace email.

• Ease of use
• Ubiquity across devices
• Platform, service and infrastructure independence

My argument boiled down to the following statement:

Email has succeeded because it’s open, standard and decentralized; for social networks to replace it, they must also be open, standard and decentralized.

Email is useful because just about everybody has an email address. I can get in touch with my clients in London, my friends here in Oxford or my grandfather in Austin, Texas, with equal ease, even though all of them are using different infrastructure and software provided by different companies. I use Gmail, but there doesn’t need to be any kind of formal agreement between Google and whoever’s providing my grandfather’s email, say. It just works; nobody owns email as a communications method, and anyone can set up an email server. The same is true with websites: anyone can set one up, and nobody owns the web.

For social communications to be as popular and ubiquitous as email, there must be one social web, and it must be owned by nobody. That means that each socially-aware site or application must implement the same social communication standards.

The best standards aren’t dictated: they evolve through common usage. If you look at HTTP (the protocol that the web relies on), SMTP (one of the protocols behind email) and file formats like RSS and HTML, the common thread behind them is that they’re simple. It turns out that through excellent work at companies like Google, Plaxo, SixApart, Twitter, JanRain and – perhaps incredibly – JPMorgan Chase & co, we already have a number of technologies that collectively embody the properties I listed above.

Notes and server architecture for one possible social web

These are my ideas about how these standards might be used. These aren’t intended as replacements for existing social networking platforms or services; rather, they could easily be added as additional features both to those and to many other types of application. The ability to share isn’t a uniquely required feature of social networking software – think about its usefulness in applications like Word or Google Docs, for example.

With email, you use a software client (Outlook, say, or the Gmail web interface) that speaks to an email server which does the hard business of sending and receiving messages to and from the wider Internet. Here, I will be describing a system where everyone has their own node on the social web, which effectively acts as a client and server. Mine might be here at benwerd.com, for example. It’s my website – my profile on the social web – and it’s where I send social communications. That’s the server side. However, it also acts as the client when I’m accessing resources stored on other peoples’ servers.

Establishing connections and granting permissions

Let’s say I want to make a resource available to my clients. With email, I’d send them each a separate copy. This is both insecure and inefficient: I have no control over what happens to that copy, and each time I send it I create a new version. With some back-and-forth, there could easily be ten or twenty individual copies of a document floating around. (I often bounce software specifications – typically Word documents – around with my clients, and this is something that happens to me regularly. Google Docs is probably a better solution, but not everybody has a Google account.)

With the social web, only one version needs to exist, which I own. If my clients have established a connection with me, I can restrict that resource so that only they may see it. The tricky bit is that in order to know if it’s really them, they must be authenticated in some way.

In monolithic systems like Facebook, where everyone uses the same website, that’s easy: my client must be logged in, and we must have established a friend connection. In a decentralized system, that’s a much harder problem, but not insurmountable. Two technologies will help us:

• OpenID: the open, decentralized authentication standard, which currently uses a website address as a kind of universal username
• OAuth: an open protocol that “allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out their username and password.” OAuth provides a secret token to applications that they can use to access authenticated services and resources behind the scenes

Specifically, we’ll need OpenID Connect (or, until that’s up and running, the OpenID / OAuth hybrid protocol), because we’ll be using OpenID to authenticate, OAuth to power our decentralized access permissions, and a number of other protocols and endpoints along the way. It’s much neater if these are all established at once.

Making friends and getting updates

The process would work in the following way. Let’s say I want to make a connection with my friend Marcus Povey.

1. I visit his site, and see that he is displaying a “connect to me” icon, indicating that it is a node on the social web. Later on, perhaps my browser would detect that this was a social web node in the same way that most browsers detect RSS feeds today, and light up an icon. Chris Messina has started a five part series on the browser as a social agent, which is worth a read.
2. Either way, I click on “connect to me”. Marcus’s site prompts me for the address of my profile, which I enter. (Later on, my browser does this bit for me.)
3. My profile address is an OpenID, and through the authentication process my social web node receives an OAuth token from him. No further authentication is required.
4. On his social web node dashboard, Marcus sees that I’ve established a connection with him. He can ignore it, in which case nothing happens, or he can mark me as a friend (or any other arbitrary designation, which could be unique to the software he’s using).
5. My social web node periodically checks for activity updates from Marcus’s, signing each request with that OAuth token so it knows who I am. This may be at my direct request; through repeated polling, RSS-style; or the update may be pushed to me through a PubSubHubbub ping.
6. Depending on the assignation he’s given me, Marcus’s node either responds with just a feed of public activity (if he’s ignored the request), or with additional activity he’s allowed me to see, in Activity Streams format.
7. Marcus can change my assignation or withdraw my OAuth token at any time from his dashboard. (Of course, throughout all this, the OAuth token mechanism is invisible to both users: it’s simply presented as a social connection.)

Embedded content and interacting directly on other social web nodes

Activity Streams is based on Atom, so content for items like blog posts (and resources like photos, using Atom Media) can be embedded directly in the activity feed. (Rob Dolin from Windows Live has some great examples.)

However, not all content is standard enough to be embeddable. In those cases, I can simply click through from Marcus’s activity update to his site, possibly log in again using OpenID, and interact with the content there. Additionally, by allowing users to log directly into his site via OpenID, Marcus can show selected people restricted content even if they don’t have the full range of social web software.

Friends lists and commenting

Further standards help us add extra functionality. If Marcus gives me permission, I might be able to download his contacts via Portable Contacts. Salmon is a protocol for commenting on distributed resources and allowing those comments to find their way upstream to the original, which is compatible with Activity Streams. Using this, I might be able to comment on Marcus’s activity items from within my dashboard and have them show up in his. Through this mechanism, all his friends could have a conversation on his activity stream items.

Reliability

So far, so good: we have a simple technological basis for permissive social communications. But if the social web is really going to replace email, we have to address one of the most important features for enterprise users: reliability. Businesses will not accept their critical communications being subject to fail whales.

In my next posts in the series, then, I’ll discuss person-to-person messaging and the thorny issue of guaranteed delivery.