WordPress Multi User and ad hoc communities

May 30, 2009 | 4 comments

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.

Google Wave is exciting and transformative

May 28, 2009 | 3 comments

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 Open Stack and truly open APIs

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.

Supporting freedom of speech

May 13, 2009 | Leave a comment

BarCamp Transparency UK 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.

Next Page »