The emerging news out of WordCamp 2009 in San Francisco is that WordPress and its Multi User cousin are to merge into one product (further discussion). This makes a ton of sense, and makes it even easier to create a community of blogs. I’m looking forward to this – I could keep my main blog at benwerd.com focused on technology, as it is now, but start a separate blog about my hometown at oxford.benwerd.com, using the same installation. Not a bad deal.

Of course, Automattic also own Andy Peatling’s BuddyPress, which is fast becoming a solid competitor in the open source social networking market. I’ve seen people have some installation difficulties with it (it’s apparently been simplified to a 13 step process), so it would make some sense to include it as an optional piece of functionality out of the box. But most importantly, I think there’s a change in progress, illustrated by the Google Wave announcement yesterday but not represented in this announcement.

Communities are forming around users, not users around communities.

In the web application model we’ve been using for the last fifteen years or so, you would install a piece of facilitative software in order to create a web community. That might be forum software or Microsoft Sharepoint depending on needs and context, but they’re both centralized communities. The user visits them to log in and participate; users swarm around a single community access point.

However, consider Skype. It’s not a web tool, but it’s often considered to be one of the new breed of applications. When you want to share something here, a community is automatically created between users, who can then have text discussions, call each other and share files – not dissimilar activities to those you might find on centralized communities like Sharepoint, but with the following advantages:

• It’s transient: there’s no need for the community to exist for longer than it has to.
• There’s no effort involved. Once you’re done with a community, you simply close the communication (but a backup is typically kept, so you can come back and reference the activity).
• It’s private: it’s very hard to share activity with the wrong people.
• It’s decentralized: the community is physically hosted between all the involved parties.

Google Wave also shares all these characteristics, and we’re going to see similar functionality crop up in a host of applications over the next year or two. The reason is simple: it’s a better way to communicate communally.

Of course, blogs are usually public entities, and in that sense WordPress Multi User does its job. But it’s tough keeping track of comment discussions, and there’s no elegant way to have a private, communal blog – something that intranet software needs and that tools like Elgg have done very well for years (disclaimer: I co-founded it). But even that sticks to a centralized model, and eventually, those ad hoc, transient communities are going to be everywhere. It’s going to be interesting to see how tools like WordPress evolve to cope.

For almost five years, I’ve had a dream of creating a decentralized social networking system with granular access permissions and a customizable workflow. It would be open source, with an underlying, decentralized open protocol based on XMPP that anyone could build on top of and extend. It would redefine the way we work on the web, and make social connections as much of a part of the Internet infrastructure as email is today.

Google just released it.

Damnit.

In all seriousness, Google Wave, and particularly the Wave Protocol, have the ability to completely change how we communicate on the Internet. That might sound a little over-enthusiastic, but so far the project seems to be getting everything right. It’s distributed, extensible, granular (as public or private as you want) and open. There’s been some talk about the interface for their sample client being a little cluttered, but the team are at pains to point out that it’s in the early stages – and this misses the wider implications of the technology.

I’m not the only one talking in superlatives. Tim O’Reilly points out:

Suddenly, familiar applications look as old-fashioned as DOS applications looked as the GUI era took flight. Now that the web is the platform, it’s time to take another look at every application we use today, and ask the same question [project founders] Lars and Jens asked themselves [with email]: "What would this look like if we invented it today instead of twenty-five years ago?"

It remains to be seen how the project will develop, but I’ll be paying very close attention.

The following is an expanded version of the short talk I gave in Oxford yesterday. My original slides follow the transcript.

There’s a new kind of web development afoot, which marries old-school object-orientated programming techniques with the distributed power of the web.

Application Programming Interfaces (APIs) are published sets of instructions for programmatically querying or extending a service. For example, the Google Maps API allows anyone with some development skills to build applications based around Google Maps; the Twitter API allows anyone to build an application that lets you interact with Twitter (like Tweetie or Tweetdeck). The act of allowing anyone to do this is generally thought of as being “open” – as in, open to anybody. While that’s true, in another sense they’re very closed.

The trouble is, if you write a microblogging application using the Twitter API, you’re locked into Twitter. If you want to write an application for another microblogging service, you have to use their API and start from scratch again. The formats produced by each service’s API are proprietary, as are the methods to query them. They’re incompatible with each other by design, because those services don’t really want you moving users’ data around between them. They want users to sign up with them and then stay there – a great proposition for the service, but a lousy one for the users, who have no real way of importing or exporting the content they’ve created.

Furthermore, there are some situations where this one-API-per-service model breaks down completely. Let’s say you’ve joined a social network and you want to check to see which of your friends is already there. The service provider could use a Gmail API to check your address book, but some users will use Hotmail for their email, so they’ll need to use the Hotmail API as well. Repeat for Yahoo, and every single email provider under the sun – there’s no way anyone could possibly write this feature without a generic API that works across all services.

Enter the Open Stack, which is a set of generic APIs designed to provide common tasks:

• eXtensible Resource Descriptor (XRD): allows an application to discover resources and APIs relating to a particular page (for example, an application could check a user’s profile page and discover that they have an OpenID). There’s no point in having open APIs if an application can’t find them, and XRD fills this gap.
• OpenID: allows anyone to log into any service that supports it using the same digital identity (potentially linking that user’s accounts on those services together). A Wordpress.com ID is an OpenID, for example; you can log into any OpenID-compatible site with it.
• OAuth: a way to authenticate access to API-based services without forcing the user to present their username and password for that service. Previously usernames and passwords were passed in order to authenticate APIs, which led to serious security issues. Here a user can easily and securely grant or deny an application’s access to their data. OAuth can also be used to apply granular access controls to a piece of data.
• Activity Streams: a way to broadcast your activity on each service (for example ‘Ben has published a blog post’, a la Facebook’s river) so that it can be aggregated at a central point.
• Portable Contacts: a simple way to transmit collections of contacts, like email address books and lists of friends, between services.
• OpenSocial: provides a framework for hosting remote application widgets on a service.

In programming jargon, a stack is a specific data or platform structure; actually, this is more of a pile of useful technologies that can (in part) be used together.

These generic APIs allow for a more distributed kind of web application. Suddenly, instead of writing support for a particular function from scratch, you can pick up an existing code library and slot it in. You can interact with any service that supports them without writing any further code.

However, there are some unresolved issues that need to be discussed. One major headache is the privacy implications. If I sign up to BensFabApp.com, I agree to the terms of service and privacy policy there. However, behind the scenes it might be accessing the APIs for AppOfEvil.com, which has a very different privacy policy and terms and conditions. How does that second set of terms and conditions apply, and what’s the legality of passing a user’s data across two services with two different sets of terms, when the user only knows about one of them?

A second issue is a user’s control over their data. When BensFabApp.com sends data to AppOfEvil.com, it may get cached and duplicated. What happens if I delete the original data on BensFabApp.com? So far in the open stack there is nothing to handle deletion of content. It’s a fair argument that when something is published publicly you lose control over its distribution; however, if access has been limited using OAuth or another method, there’s no way of reaching out an ensuring its removal from every system it’s been sent to. That would be fine if the data had been sent to another person or application with the user’s express permission, because they’ll be aware of the implications. However, if it’s been sent completely behind the scenes, they have no way of knowing that it was sent to begin with.

These are issues with any API-based service, but generalized APIs are likely to be used more frequently. Solutions to all of these problems will be found, but it’s important to note that they’re not there yet – which serves as a warning to applications developers and an opportunity for anyone who wants to step up and provide them. As this kind of open API becomes commonplace, new kinds of web applications will begin to emerge as developers spend less time reinventing the wheel and more time innovating. It’s just one of the things that makes the web as a platform so exciting to work with.

OutMap is sponsoring BarCamp Transparency by donating a portion of my time to developing the website (for which I’d already provided the copy), as well as providing Twitter walls and projectors on the day. If you’re in the UK and interested in open government, cyber activism or social media ethics, I highly recommend you keep the 26th of July free for a trip to Oxford. Some very high profile people are attending, and the discussions promise to be amazing. And, hey, if that’s not enough for you, mention that you found out about the event from this blog and I’ll buy you a beer.

On a not-entirely-unrelated note, I want to make you aware of GlobalVoices Advocacy, which aims to create a global anti-censorship network of bloggers and online activists in the developing world. This is important work; one of the really exciting aspects of the web is the way information can spread and undermine oppressive legislation. It’s also dangerous, as blogging in places where freedom of speech is not protected can have severe consequences. They provide tutorials on blogging anonymously, as well as blogging effectively for a cause.

Zemanta, a blogging tool that suggests content to include as you type, is offering a small funding award to the charitable cause that gets the most posts as part of their ‘blogging for a cause’ promotion. It’s a good idea, and if you like what GlobalVoices Advocacy do, maybe you could write about them too – or any other good cause that you think is deserving.

I vote for Global Voices Advocacy because freedom of speech and the fight against censorship is one of the most important fronts in the fight for human rights around the world. This is a fight that we can all participate in, without having to go through governments, and GlobalVoices Advocacy is one organization that shows us how.

This blog post is part of Zemanta’s "Blogging For a Cause" campaign to raise awareness and funds for worthy causes that bloggers care about.

I thought I’d share two small bookmarklets I’ve been using to find references for a page I’m looking at:

• Web references: page
• Web references: site

To use them, drag each link to your browser toolbar. This will create a couple of buttons that you can click when you want to find more information about whatever page you’re looking at; the first checks the full page URL, while the second just searches for the domain name of the site.

At the moment both open Google Blog Search and Twitter search as tabs. If you have suggestions for other searches I could add, let me know and I’ll update the code here.

Standards geek: “I think we need to establish a standard for representing poetry on the Internet. I’ve drawn up this draft which encapsulates stanzas inside an Atom feed. It’s pretty simple; the spec fits on a page, so it should be easy to implement.”

Visual poet: “That’s pretty cool, but what about visual poetry? You know, that Fluxus kind of stuff? Because you can’t really separate that into stanzas.”

Standards geek: “Hey, you’re right. I’d better create a new element for visual poetry.”

Visual poet: “Awesome. Thanks, man; now I can represent my visual poetry using your standard.”

Spoken word poet: “Hey, that is awesome. But I don’t have any way of representing my poetry, which is all spoken. I don’t write it down at all.”

Standards geek: “Good point; I don’t have anything for spoken word poetry. I’d better create a new element for that.”

Performance poet: “While you’re at it, could you create a sub-element for performance poetry? We’re like spoken word poets, but we also sometimes use music and elements of theater in our performances.”

Standards geek: “… Okay, I’ve added some new elements that represent performance poetry.”

Haiku poet: “Could we also have something for haiku? Although haiku can be thought of in stanzas, it’d be useful to draw out the kigo and the kireji and represent those explicitly. Also, haiku can be drawn as a line of Japanese characters or as three lines of Latin text, and it makes a difference to the overall interpretation of the verse.”

Standards geek: “I don’t really know what those are, but I’d like to support haiku, so okay, they can go in.”

Linguist: “This standard is only going to be useful to me if I can add interpretations to a poem, and group poems together to make a themed collection.”

Other linguist: “And I’d like to comment on other peoples’ interpretations so I can tell them why they’re wrong.”

…

Standards geek, two months later: “Okay, I think I’ve got every major representation of poetry that everyone’s asked for. We’re ready to lock down the spec and build some libraries for initial testing. The only problem is, the specification is now seventy-two pages long, so that might take a while.”

Kinetic poet: “Sorry, I just got here. Can we add a marquee tag?”

Photo by surrealmuse, released under a CC Attribution-Noncommercial-Share Alike license.

Congratulations are in order for the Curverider folks: over on the Elgg blog, Dave’s announced a new round of funding for the company. Additionally, Leonard Lin is working with the team on a consultancy basis.

Although I left to pursue other projects last month, Elgg is close to my heart. I headed technical direction through Elgg version 1.5 (the most recently-released version), co-founded both Elgg and Curverider, was co-author of Elgg’s vision and ethos, and remain a major shareholder in Curverider. As a result I’m absolutely delighted about this state of affairs, which should allow the project to realise its commercial and technical ambitions.

North Oxford is the wealthiest part of a wealthy city, where BMWs sit in gravel driveways and wine bars nestle amongst delicatessens and stylish cafes; a part of the city I always yearned to belong to as a kid, but never quite did. It was where I went to school, and where we had our first offices when we were building Elgg.

In keeping with the rest of Oxford, it’s suddenly begun changing dramatically over the last couple of years (I’ve joked a couple of times that someone at the City Council planning office must have died, but this may not be too far from the truth; despite a glut of brilliant minds and genuine creativity, the city itself has always been stiflingly conservative). One of the newcomers is The North Wall, an arts centre that actually sits a few doors down from that first Curverider office on South Parade, and is in some ways more exciting than any other arts space in Oxford. From hip hop comedy dance to puppetry, its events seem to bring new blood.

Ben’s Big Gig was probably the first gig of its kind. Ben Walker is Internet famous for his Twitter Song, an in-joke that, appropriately enough, has been bookmarked, re-tweeted and blogged all over the web, and attracted praise from the likes of Demi Moore. He’s also a genuinely talented songwriter and musician who has been playing around Oxford for years at various events, including a regular stint at the now-defunct QI Club (which was associated with the TV show of the same name). Together that was enough to sell out the arts centre, as well as attract hundreds of visitors who watched live over the web – Nick Gill’s gorgeous lo-fi poster, pasted up all over town, couldn’t have hurt either. A Twitter wall on the back of the stage read out feedback as it happened, forming a back-channel to the music and allowing the audience to heckle the comedy warm-ups with relative safety. All of this felt not like a technological gimmick, but an organic part of the experience.

Live web gigs happen all the time, but they’ve usually got major backing. Sandi Thom was famously discovered through webcasts, but it was a PR stunt: she already had a major publishing deal, and at the time the streaming technology would have cost tens of thousands of dollars. Times have changed: although it’s probably not free, technological improvements have brought live streaming within reach of independent artists. Ben’s the real deal, a performer with old-school talent who just happens to be using contemporary tools to reach his audience. We’re going to be seeing much more of this.

However, the first-mover advantage definitely holds water. At the end, as I was leaving, I told Ben that he needed to do it again. He confirmed that he will; I suspect the audience will be even bigger next time.

In the meantime, here’s the video feed from the gig:

The delightful picture of Hugh Fearnly-Whittingstall was released under a CC attribution license by Ben Walker.

Twitter is the darling of the tech scene, much as Facebook was a couple of years ago and Flickr and MySpace before that. Many would probably argue that it’s had more attention than it deserves: all it does is let you post, share and read 140-character messages. Despite this, there’s been more talk about why it succeeds than why it doesn’t, as well as finding flaws in its play to become mainstream: despite being featured on Oprah, from month to month only 40% of users come back to the site. (I’m one of them.)

I’m surprised to see how few people have mentioned what I think is Twitter’s real killer feature: it integrates with your real life in a way that no other web app comes close to matching. Sure, people post to Twitter from their desktop PC, but they also post from the park, on the plane, and even from space. With the increasing popularity of truly Internet-capable mobile devices, it’s no surprise that everyone’s copying the Twitter model, from big players like Facebook and LinkedIn down to newcomers like Yammer.

The genius of web applications really lies in the ability to access them from any connected device. As the Internet moves away from the desktop and becomes a ubiquitous part of life, web applications need to adapt to be able to cope with the varied changes in context that we deal with every day. Life is complicated; to cope, web applications need to get simpler.

Let’s take a quick look at how Twitter does this:

• Tiny barrier to entry, with recognizable touchstones. Twitter is designed around an existing method of communication that people are already familiar with. SMS messages, sent back and forth on cellphones, are 160 characters long; Twitter messages are 140 characters long to fit comfortably inside this limit, along with 20 characters of contextual information. (Like, for example, the username of the person whose message you’ve just received on your phone.) You don’t need to learn any new techniques to learn how to use Twitter, although @replies and #hashtags are there for more advanced users. The short updates also encourage people to post more often, as it takes them a matter of seconds.
• People are the feature. The Twitter team understand that their biggest feature is the userbase themselves. People use Twitter for all sorts of things, and although newcomers are often a bit bemused or even repulsed by the lack of functionality, it’s exactly this that allows people to harness it for whatever makes sense to them. As I’m fond of saying, the Internet is people: Twitter simply acts as a low-friction conduit to allow them to talk to each other.
• An open, welcoming business ecosystem. The API – a way for third parties to build new interfaces for the service, for example for cellphones or iPods – is almost as simple to use as the site itself. As a result, it’s been said that around 80% of Twitter’s traffic is through API-based third-party clients. I use Tweetie on the iPhone and TweetDeck on my PC; I paid for the former, while the latter is free. Neither pays any royalty to Twitter; companies are free to build business on the back of the service. In return, Twitter gets interfaces that cater to use cases they didn’t think of.

There is always going to be a place for all-encompassing desktop applications. I have no need or desire to use Photoshop on my phone, for example – but mobile devices are a perfect platform for everything from simple searching, low-barrier accounting like Quicken Online, and the kind of distributed data-gathering we’re building at OutMap.

This doesn’t mean that copying Twitter is a smart business model at all. Instead, it’s worth looking at the factors that made them successful and then analysing which core features will work for you.