monkinetic weblog | redmonk.net

It’s been a while since I’ve posted about what’s going on in the DiSo community, and I had started to prepare a list of recent developments to share, but on the way I felt that there was a theme I wanted to address first.

The DiSo Project is first and foremost about enabling/creating a new category of social-networking-enabled websites, not restricted to the large silos but grown organically at the edges of the web - the small and independent sites that are the forerunners and foundations of the communities we now enjoy. How can we best provide a fertile environment, one that encourages, protects, and nurtures this growth?

Fertile Foundations

One theme that’s been cropping up on the conference circuit lately, thanks to Chris Messina, Dave Recordon, Jeremy Keith, and others, is this idea of “building the open web“. The internet (based on public, open technical standards), and the early www (based on public, open hypertext formats and protocol specifications), gave “the web” we know its heart and soul. How did that happen, and what will perpetuate the process?

Like sediment in a river, or potting soil in a greenhouse, each layer we put down supports and affects the ecosystem that grows out of it. We take IP, ethernet, and their like completely for granted - they’ve been standardized and implemented across a worldwide network. That layer is foundation and fertilizer for the next: HTTP, SSL, HTML, XML, and the feed variants that have become the everyday building blocks of our applications and services. These are now settling into the foundation for the services we’re building now: near-real-time publishing and social software stacks. These, in turn, will provide for what comes after, and the philosophical foundations we build into this layer will profoundly affect the health of the next.

Building the Open Web

So for the next ecosystem of social and community applications to thrive, we need to make sure that these aspects - public, freely-implementable formats and open standards - are a part of the web as we know it now. Thankfully, it’s happening - witness the growth of open, enabling technoliges like:

• Microformats, basic specs for marking up machine-readable data in human-readable web pages (XFN, hCard, hCalendar, hAtom, hEtc)
• OpenID, open identity solution for web services
• OAuth, an HTTP-based protocol for authentication between services
• XRDS-Simple, which provides discovery for various web services and makes inter-app cooperation that much easier.
• XMPP, a real-time, distributed messaging system that can be integrated into other services.

All these are publicly developed and freely implementable, and active communities have evolved around them to discuss, implement, and evangelize them. This is what building the open web is about: collaborating to build a web that is larger than any company or organization - a web that will encourage new growth.

New Growth

So, given all the effort we’re putting into creating a web that is fertile ground for what’s coming next… what’s coming next? Here’s a look at a few areas DiSo is focusing on as we work on the building blocks of the distributed social network:

Identity

OpenID has focused a lot of attention on putting the User’s online identity back under their control. Rather than maintaining an account on each and every site they use, the User can maintain one or more OpenID accounts, using them as credentials on any of the 10,000+ sites that accept an OpenID for registration and login. With the technology in place, we turn our attention to what identity means, how much of that identity we’re willing to share, and with whom.

Activity

Since the mid 90’s we’ve been working on the problem of how to track what our friends and contacts are doing online, and figure out where the stuff that’s really interesting and relevant to us is happening. Look at the social network silos, and you’ll see that a huge part of what they offer users is the ability (or at least impression) that the user can know what their friends are up to. Sites like Twitter and FriendFeed are making progress on bringing this activity tracking into the light, but to really distribute it all there’s still a lot of work to do.

Here at the edges, we’re making it easy to agregate your own activity, and working on ways to track/follow updates of your friends activity in near-real-time.

Messaging

With OpenID providing a common form of identity, we’ve begun looking at what services can be enabled using that endpoint. One of the services we’re exploring is distributed messaging - friend requests, subscription requests, and direct messages - directed to that endpoint, authenticated via OAuth, and filtered by a messaging service based on user preferences.

Cultivating the Open Web

As the builders - or growers - of this web, it’s our responsibility to look beyond the IPO, beyond the ad-sell, beyond the current crop of buzzwords. We must decide that we’re going to invest in, and give back to, the ecosystem that has supported us. Think of it as Web “Green” - protecting and nurturing and stewarding the web ecology.

To Jeremy in IM:

You know you’re addicted when your first thought when Twitter is down, is to Twitter about how much more productive you are when Twitter is down.

Ok, so last week Jodi and Adelina were off in Colorado (I’m sure Jodi will blog it soon), so I was home alone quite a bit. So what did that mean? Hackery!

After exploring some machine tagging and some UI bits and pieces for machine tags on the site, I spent some time completely rewriting my machine tagging code. I started with blog:via as my first machine tag, then quickly added tags for movies in Netflix (netflix:id), books at Amazon (book:isbn) and other Amazon products (amazon:asin). Here’s a post with a blog:via tag and a book:isbn tag. And here’s one with a netflix:id tag and an amazon:asin tag.

Implementation

I’ll admit, the implementation is still a bit scattered. This blog is powered by WordPress, so to start with the tags themselves are added to posts via a custom field called ‘machinetags’ - one entry for each tag:

WordPress’s template tags make it easy to get at those values as an array, which I pass to a WordPress plugin I wrote just for this. The plugin builds the initial display for the related items, adding ids and classes as hooks for the next bit.

When the page loads, I wrote some javascript (using JQuery) that attaches custom event handlers to the click events for the “more posts” and “view” links. The handlers fire off ajax calls, so that I’m not making a lot of ajax calls as the page initially loads (which would increase page load times for something that only some readers are going to be interested in).

As you can see here, clicking the links loads related content inline:

Strategies

So far, all my tags live here on this site, attached to my posts. Jeremy Keith uses this same strategy, and adds a “tags in the cloud” tactic - assigning adactio:id=... tags to photos on Flickr, then doing a Flickr search to pull in photos when a post is viewed. I may explore this a bit more - I’ve been thinking about using Amazon’s tagging feature to add a monkinetic:id=... tag, then doing the lookup that way, but for products it feels more appropriate to have the hook/tag on this end.

APIs

Machine tagging is going to succeed or fail on the strength of the APIs that services offer. Amazon, while not being a posterboy for Web2.0, has an amazing REST API that is pretty easy to work with once you get the hang of it. (I’m using a technique that - acronym alert - runs Amazon’s XML output through an XSL stylesheet hosted on my server via Amazon’s own XSLT service to produce JSON.) I use it for looking up books as well as any other product Amazon offers.

Netflix, on the other hand, has no API, and I had to resort to figuring out the URLs that use Netflix’s internal movie ID to make a link to the site and grab the cover thumbnail. I would love to actually show the movie title and average rating, but there’s no api for it.

I also looked at IMDB but could not find even so much as a predictable way to devine a movie poster image from an IMDB title id, so while I may add imdb:title=... tags to some of my posts, I won’t be able to provide related content inline. This is really a pity, as both Netflix and IMDB are probably afraid that if they provide easy access to their content via an API, competitors might use it to disrupt their market. Well, that might be the case, but there are a LOT of us out here who would love to send traffic to both Netflix and IMDB in more interesting ways.

If you love something…

As Dave says:

People will only trust a service that gives them complete freedom to come and go as they please. Further, they’ll want to come back if you send them to cool places.