monkinetic weblog | redmonk.net

Kottke:

No, the striking feature of this printer is that they made it look just like a normal desktop-sized HP inkjet printer, despite the fact that the damn thing is as big as a hippopotamus.

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!

Seeing as I’ve been in Vladivostok, Russia for a week and a half now adopting our second (and incredibly precious) daughter, this is going to sound remarkably petty. But I’m a geek and it’s been driving me nuts.

Before we left I loaded up my Mom’s PowerBook G4 with the applications I needed for communication - Firefox, Mailplane, Quicksilver, our .Mac account, etc. I installed Textmate, checked out the source for mofo (I’m working on some XFN additions) and figured I was set.

The trouble, of course, was that I did not test out my rig before leaving. Since bringing Sophie back to the hotel from the baby home, I’ve had some down time to do some coding, and discovered that I had forgotten to load the the actual ruby gems for mofo and Hpricot. When I ran gem install mofo -y I discovered that Mom’s PowerBook does not have the dev tools installed and therefore could not build the native extension for Hpricot. KAAAAAHHHHHHHN!!!!!!

Ok, this can be overcome, I thought to myself. I tried contacting a few people (the 18 hour time difference to the States is a killer) and finally get a hold of Matt Gemmell who was kind enough to go through the process of installing rubygems, then mofo and hpricot, then packaging up his gems directory and sending it all over.

30 minutes after starting I load up irb and try:

irb(main):017:0> require 'rubygems'
=> true
irb(main):018:0> require 'hpricot'
/usr/local/lib/ruby/gems/1.8/gems/hpricot-0.6/lib/i686-linux/hpricot_scan.bundle: 
[BUG] Bus     Error
ruby 1.8.6 (2007-03-13) [universal-darwin8.0]

Abort trap
~ azivys$

Oh, man, Murphy must HATE me.

Matt was on a PPC mac, but was running Leopard, so I don’t know if that was the issue, or what. But I’m stumped, and while I’ve gotten some code written, it’s code I can’t run or test, which sucks.

So, I’ve got the call out to another friend, but don’t know if I’m going to be able to get this going before it’s time to come home (Saturday). Ironically, I’ve spent about 3x the brain cycles trying to solve this than I would have writing the code I planned to write in the first place.

Sigh.