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?

grass image from pygment.com for whose proprietor I cannot find contact information.

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.

For a few weeks now, I’ve been playing with Movable Type, porting my as-yet-unfinished Friends plugin from WordPress to MT. I’ve been interested in what’s happening in the MT development world for a while now, and this seemed a good way to find out.

Progress has been… stuttering. But I’ve got the basics in place - Editing and listing your contacts, and last night I got the template tags done so that I could build a basic blogroll widget (with XFN and hCard, oh my!).

MT Friends progress, in screenshots

A nerd needs a project because a nerd builds stuff. All the time. Those lulls in the conversation over dinner? That’s the nerd working on his project in his head.

– Rands in Repose, The Nerd Handbook

Microformats, OpenID, Portable Social Networks

So, for the last month or so, these things have been my Project. Actually, I haven’t spent as much time on them as I’d like, since I’m a Dad (geek dad FTW) and an employee first, but I am a nerd and these have been my Project. The evidence:

• If You Love Your Users, Set Them Free — Portable Social Networks
• Making a list: Whitelisting with OpenId and XFN
• Blogrolls, XFN, and OpenID URIs
• More XFN+OpenID
• XFN Blogroll

You can see that it’s been occupying the back (and front!) of my mind for some time now. My unfortunate sounding board for a lot of this has been the unflappable Chris Messina, who himself is an enthusiastic evangelist for microformats and has put up with a lot of questions, as well as putting up with me nearly hijacking and adopting his plugin project.

I’ve rewritten large chunks of the XFN blogroll plugin, with Chris’ help and encouragement, and added substantial functionality (mostly in enabling the plugin to find users who have registered via openid and modify the blogroll links based on that information). Now, we’ve decided to move this project and several others we have in mind to their own project on Google Code.

DiSo: Distributed Social Networking apps

DiSo (dee • zoh) is a new umbrella project for various open source social networking components that we’re working on. In the beginning, we’re largely targetting Wordpress, building on the work Will Norris‘ has done with his excellent WP-OpenID plugin.

From the project description page for DiSo:

This model can be described as having three sides… Information, Identity, and Interaction.

The first plugin is the Microformatted Blogroll (wp-xfn), which is about ready for a 0.5 release, and has been getting a workout on my blogroll for a while now.

I’ve also started preliminary work on an OpenID server (wp-openid-server) that will authenticate against the Wordpress user database. The server will, hopefully, be a port/wrap of phpMyID, a very easy to use single-file server writtten by CJ Niemera.

What’s Next

For me, continuing to develop wp-xfn, and start designing wp-openid-server. For you? Try reading http://code.google.com/p/diso/wiki/WordpressBrainstorming and http://factoryjoe.pbwiki.com/DistributedSocialNetwork and see if there’s something you’d like to work on. Download the source an browse around. Then contact me or Chris and let’s talk!

The action is over here. Next step is to start in on the thornier issue: how to start building the whitelist.

This weekend I ran across a post on Tim Berners Lee’s blog (the Giant Global Graph - Groan), but what got my attention was a previous post by Dan Connoly about the social-network-based whitelist they’ve developed for commenting on the Decentralized Information Group blog.

In less than a nutshell, the DIG is using the relationship data in their members’ FOAF files to build a whitelist of users (identified by their OpenID) who can comment on the site.

Decentralized Information Group, OpenID+FOAF Whitelist

In FOAF and OpenID: two great tastes that taste great together, Dan writes about the system the DIG devised to whitelist comment authors:

In more detail, you can comment on our blog if:
You can show ownership of a web page via the OpenID protocol.
That web page is related by the foaf:openid property to a foaf:Person, and
That foaf:Person is listed as a member of the DIG group in http://dig.csail.mit.edu/data, or
related to a dig member by one or two foaf:knows links.

Sean Palmer has a deeper, very interesting description of the process that went into the system, and Shahan Khatchadourian describes how it works for a new user

Mapped out, the system looks something like this:

To be added to the site’s comment whitelist, either the green or blue path must be satisfied: User A has to be either identifiable (via OpenId) as a DIG member (foaf:Person matches in the DIG member data) or another DIG member must “claim” User A (User A is identified via OpenID and their foaf:Person is related via foaf:knows to the known DIG member).

OpenID+XFN (+Wordpress?) Whitelist

So tonight I got to talking to Chris Messina about DIG’s system (he pointed me to Simon Willison’s efforts back in January at whitelisting via OpenID) and wondered if we couldn’t build a similar system with a little less propeller-head factor using XFN instead of the semantically pure but pragmatically awkward FOAF.

In order to make something like this work, it seems that the flow would work like this:

1. You can show ownership of a web page via the OpenID protocol.
2. That web page contains your hCard, or a symmetric XFN rel=”me” link to a separate page with your hCard
3. The URI of your hCard is listed in the service’s membership data, OR
4. The URI of your hCard is listed in the XFN of a member of the service with an XFN relationship of “acquaintance” or better (”better” is subject to definition, based on the XFN profile).
5. You get added to the service’s whitelist

This is very rough, but mapped out it looks something like this:

As before, to be added to a site’s whitelist, either the green or blue path must be satisfied. I think that a system like this for Wordpress (for example) could be built out of mostly existing parts, starting with the Wordpress OpenID Plugin (newly 2.0). (Chris has more notes on a wordpress plugin.)

My thinking here is rough, and probably contains quite a few holes, so I’m trusting that those more knowledgable that I will point out flaws in my thinking or new directions.

UPDATE: A conversation with Paul Walsh and Simon Willison sprang up in the comments on Pauls’ post, “Identity” the most widely misused term by Internet experts. Paul makes a decent case (and Simon agrees) that saying OpenID “proves identiy” is misleading - nothing is proven and no Trust is asserted. OpenID provides a form of identity (”I can prove I own this URI”) that particpants have agreed to. Thanks to Paul and I’ve updated my diagrams accordingly.

If you love something, set it free

If it comes back to you, its yours

If it doesn’t, it never was

– Author Unknown

These wise words graced the wall of my childhood home in Virginia Beach, VA, along with a generic painting of a seagull. (Why anyone would want to keep a seagull was beyond me.) However, in today’s web the words ring true all over again.

Social networks are popping up faster than weeds, and user fatigue is already setting in. One of the solutions (the most “Don’t Be Evil” in my opinion) comes in the form of a discussion of Portable Social Networks - the idea that social networking sites should allow users’ data to be portable between sites. This idea comes in two parts:

1. Allow users to import their data from a source they trust in the form of an hCard, and their existing contacts in the form of XFN-linked hCards.
2. Optionally publish user’s data in these same formats so that if they lose interest, they can move on.

Part 2 used to scare people running sites, but it’s becoming the de-facto standard and is becoming expected behavior (see Twitter, Flickr, dopplr, etc.) Data lock-in is considered in very poor taste now.

Surprisingly, part 1 is still finding its way into apps, though it would go a long way toward making users feel that they and their time are respected. A few sites are doing a good job of making it easy for users to bring their data with them. Dopplr.com, though in private-beta right now, is getting good reviews for a registration process that offers the user the option of importing their profile data from a variety of other social sites, and also offers to match up the users contacts from those sites with (and this is an important point) users already in the Dopplr system. Let’s cut down on the social-network-invite SPAM while we’re at it, mmmkay? Dopplr as even gone as far as publishing code.

Portable Social Network Lib

As a couple folks have discovered, I’ve started a project for a ruby library called, surprisingly, Portable Social Network Lib.

PSNlib is quite early in its life (and I’ve been distracted by an adoption and by adding some stuff to mofo to make building PSNlib easier) but it has two goals:

1. Make it easy for a ruby-based app to add hCard+XFN import to an existing model layer, and
2. Make it easy to publish user profile and contact/friend information as hCard+XFN

Eventually, I’d like to see OpenID/OAuth mixed in in some way as well. Kevin Lawver has started some cool stuff in that area, and I’m going to keep my eye on it.

Outstanding Issues

It’s after 2 AM in Vladivostok, Russia, and the whole point of this post was to get down some issues I’m having in implementation so I could STOP thinking about them. So in no particular order, here are some things that are bugging me:

Mixed data: XFN+hCard

When parsing an XFN list and you want to look for hCard data for those contacts along it, what is a good parsing strategy? lab.backnetwork (another site experimenting with XFN+hCard importing) uses:

<li class="vcard"><a rel="friend coworker"><span class="first-name">Co-worker</span> <span class="last-name">Friend</span></a></li>

This is thorny because while mofo/hpricot makes finding the XFN relationships easy, it would take some working around the default behavior to figure out that the XFN relationship was wrapped in an hCard (class=”vcard”). Likewise, I’m unsure of the recommended practices when publishing XFN contact list data with hCard data mixed in with it.

XFN pagination

rel="next" or rel="me next"? lab.backnetwork uses rel="next" but microformats.org recommends rel="me next".

Wrapping Up

That’s all I have energy for today, but if you have thoughts or ideas, please leave them in the comments. Thanks!

Jeremy Keith and I had a geeky chat this morning about machine tags, rel=tag, and the like.

A while back I was thinking about how to encode “via” information in a blog post/tag, so that eventually I’ll be able to do more interesting things with where I’m getting my links/inspiration. Jeremy and I talked then as well, and the idea of using a machinetag came up, and we came up with a format:

blog:via=<permalink>

Since then I’ve tagged a few posts with this format, but haven’t been really comfortable with mixing the machinetags in with my usual tags (I confess mostly this was because they did not break properly and made my layout look janky). So I pinged Jeremy and we talked it over. Eventually he gave me the piece of information I was missing: machinetags are not related (no pun intended) in any way to rel=tag. They just happen to confusingly share the label “tag”.

Aha! This freed me to implement my machine tags separately from the normal post tags, as you can now see on this post about the FontBook. In this case I created a WordPress custom field for them. I may continue to tweak the presentation a bit, but I like what I’ve got.

Further Reading:

• Machinetags.org wiki
• Machine tags and ISBNs
• Machine Tags: Tagging Revisited
• Adactio: Ghost in the Machine Tags
• Flickr API - by which some of these machine tags are gaining usefulness