There are certainly many advantages to having your own social networking site. A facebook or myspace presence may attract attention, but the data you’ll be able to gather about your supporters and the potential for inserting your own branding are limited. Set up your own social network and you have full flexibility to integrate that data with your supporter databases, and to tune the site to your very specific requirements. But not only are they a significant investment of resources, there’s also a significant cost of time for supporters who will need to sign up for yet another site, identify their friends once again and give their attention to even more online data. Online campaigning’s great strength so far has been its low barrier to entry; for cause-specific social networks to really make sense their barriers need to fall.

That desire is definitely not unique to non-profits. As Brian Suda’s “Portable Social Networks: Take Your Friends With You” highlights, finding ways to let users move their data from site to site is a hot topic across the web development world. Sites like traveller network dopplr have succeeded in part by letting their (so far highly tech savvy) users import data from other social networks such as twitter. The real breakthrough will be when the mass-networks of the moment (as facebook is today) become similarly open. That won’t make it easy, but it will mean that there is suddenly a huge audience who can become fully signed up for your site with just a couple of clicks.

Right now most efforts hinge on a set of emerging standards, two of which will be familiar to anyone who’s been reading this blog for some time but which bear some more attention. There’s plenty of information around the web on these so I’ll just touch on them briefly:

Microformats are a way of taking plain old HTML and, by following some conventions, adding meaning to the content that could be understood by machines. While a human might be able to look at some information and infer that it is describing an event, machines aren’t so good at that, so we need standardised ways to say “this is describing an event, that bit is the date,” or “this link is to the homepage of my brother.” There were already ways to do that, but it involved adding extra things to your website. With microformats, so long as you (or your content management system) follow some simple conventions when creating a page, a machine can get the content out of the page as easily as a human reader can. That lets us identify friends/contact lists in a portable way, among other useful functions.

OpenID is a way to get rid of the frustration of having to create a username and password for every new site you visit. Instead when you visit a new site that you want to sign up for, you enter a URL that is your OpenID and that site will check with a central system (which may require you to log in) whether you do in fact own that OpenID. Rather than having to remember dozens of usernames and passwords, you’ll probably just have to remember one URL, one username, and one password. And because you’re using that same OpenID for lots of sites, when you sign up for a new site you can be identified on others. So if you sign up for a new site I’ve created using the same OpenID you use on livejournal my software can identify you on livejournal and import your posts from there. So there’s less work for you to tell that new site you’re creating a profile on how to find your blog and to import the posts, and an easy way to make your profile active and informative.

OAuth is the newest of the standards and goes hand-in-hand with OpenID. It allows you to grant one web application permission to access certain parts of your data in another application without giving your usernames and passwords all over the places. If you’ve ever used a site that redirected you to flickr to get your permission to do something with your photos, you’ve seen something like it. If OAuth is widely adopted, no longer will you have to give every social networking site your webmail username and password in order to have your address book checked for other users of the site, simply trusting that they won’t abuse it. Instead, it becomes easy to give a one-off permission while keeping your details as secret as they should be.

What these pieces add up to is a significant reduction in the psychological hurdles that might prevent your supporters from joining your new social network. Instead of pouring hours into their friendster profile only to find everyone has moved to myspace, and so not signing up for your site because they’d have to go through the whole process all over again, they can sign up with their OpenID, perhaps grant you a few permissions with OAuth (knowing that they’re not handing over the keys to their email, online photos, or whatever) and be signed up with an already complete profile.

In other words, persuading people to sign up and build their profiles is no longer the issue and you can focus on providing them with compelling reasons to keep coming back.

So if you’re wondering whether now is the time to start building out your campaign’s fancy new social networking site, it just may be, but chances are a few months from now will be a better time. As OpenID and OAuth become better established—and maybe even get adopted by some of the big players—your life is going to be easier and provided you pick web developers who’ve been keeping up you’ll be able to focus on your campaign strategy rather than coaxing visitors to spend another few hours re-entering the same old details.

Over the next two months they are going to increase third-party access to their site. First, they are going to highlight the thousands of widgets that have been on their site for years now. This should be released in the next couple of weeks. I am assuming that it will go beyond the FIM’s Spring Widget Gallery. Second, they are going to offer an API for applications to all developers. However, these applications are going to be sandboxed initially and 1-2 million users will have access to them. If the users deem the applications safe and useful they’ll be available to all users. Developers will be able to advertise in their applications.

It’ll be interesting to see whether the MySpace platform and API are truly a step towards openness or whether it’ll be another walled garden a la facebook. Facebook’s platform is phenomenally successful, but doesn’t really open up their core data (status, events, etc.) for developers to interact with. Given their track record it’s unlikely that MySpace are really going to launch something more open that that.

For developers, and for the musicians whose presence is MySpace’s key calling card, this is a tiny step but not one that makes easier the services that we really need. Musicians still need to update their information across dozens of walled gardens rather than having easy tools to use. Developers still need to scrape and hack if they want to provide a way to access core parts of users’ profile, and unless MySpace address the many, many technical problems on their site (unreliability, apparently random use of captchas, awful HTML) that’s going to remain a huge hassle.

Of course, the key question will be whether this announcement will help MySpace retain their pre-eminent position. The crown has slipped over the last few months, with facebook’s popularity rocketing and people deleting MySpace contacts and accounts in order to focus on just one social network. I suspect MySpace will never get their crown back. If they do, it’ll have to be because they’ve radically changed the social networking game.

I’ve long wished for a decent API that would help me integrate MySpace with websites I run for musicians—after all, it isn’t very DRY to post the same content in several places when it could be automated—but as time has gone on it’s become clear that an API would be entirely anathema to MySpace’s approach to the web.

So while working on some updates to a friend’s website I decided to try out the Ruby port of WWW::Mechanize to automate the process of posting blog entries over at MySpace.

Firstly, we need to be able to log in. To do that, you can almost copy some of the library’s examples as it’s as simple as:

agent = WWW::Mechanize.new
agent.user_agent_alias = 'Mac Safari'
 
page = agent.get('http://www.myspace.com')
login_form = page.forms.with.name('theForm').first
login_form.email = username
login_form.password = password
logged_in = agent.submit(login_form)

Posting a blog entry is a little trickier, as MySpace uses javascript to change forms’ ‘action’ attributes based on which button you click, and occasionally inserts tokens in the URLs, but after a little exploration I came up with:

blog_page = agent.get('http://blog.myspace.com/index.cfm?fuseaction=blog.create&editor=false')
blog_form = blog_page.forms.with.name('theForm').first
 
# Here we have to grab the action as it includes a token which can change
new_action = blog_page.body.match(/document.theForm.action = '(.+?)'/)
blog_form.action = new_action[1]
 
blog_form.subject = subject
blog_form.BlogCategoryID = category
blog_form.body = body
 
now = DateTime.now
blog_form.postMonth = now.month
blog_form.postDay = now.mday
blog_form.postYear = now.year
blog_form.postHour = now.strftime('%I')
blog_form.postMinute = now.min
blog_form.postTimeMarker = now.strftime('%p')
 
submitted = agent.submit(blog_form)
 
confirm_form = submitted.forms.with.name('theForm').first
confirm_form.action = 'http://blog.myspace.com/index.cfm?fuseaction=blog.processCreate'
posted = agent.submit(confirm_form)

And that’s all there is to it. I’m impressed with how easy WWW::Mechanize makes interacting with forms, and generally how pleasant it is to work with. Performance is pretty good too, specially given how problem prone MySpace is. It’s nice to be able to imagine a scenario in which clients can cross-post their content to MySpace. If we’re lucky, we never need actually visit that website again!

I’m working on packaging up the code, probably with support for posting event dates and ‘bulletins’, and adding in error handling to deal with the 75% of the time (based on my usage this afternoon) when MySpace returns an error page. It may be a few days, but I’ll post a note here when it’s ready.