Dominiek.com

This week I suddenly realized that one month ago, we implemented XFN on iknow.co.jp – the startup I’m working for. I almost completely forgot about this and I needed some 20%-google-time distraction from my day to day tasks. So I thought about doing a quick search and jacking in a simple friend finder that uses the Social Graph API. A friend finder meaning: you input your SNS-X username and you will get all SNS-X usernames that are your friends on SNS-Y, SNS-Z.

To my amazement I couldn’t find any straightforward pieces of code actually doing this. All I could find was the usual pretty printed JSON outputs. So I rolled up my sleeves and did some Javascript hacking myself.

Click here for a Demo

• A regular expression determining the profile URL structure of an SNS
• The profile URL of the person to recommend friends to, eg: twitter.com/dominiek

The code should be fully customizable for your own SNS, feel free to use it however you want: (don’t forget to fetch socialgraph.js)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// callback:
function contact_found(username, is_new, on_site_name, on_profile_url) {
  // a user on this site was found and is a friend on_profile_url
  // this is also where the is_friend_already? check goes
}

// callback:
function contact_search_status(percentage) {
  // progress report, might take a while to query everything
}

// setup regexp for this SNS
var site_regexp = new RegExp(/http:\/\/www\.iknow\.co\.jp\/user\/([^\/]+)/);

// setup library and pass in callbacks (contact_search_status is optional)
var social_graph = new SocialGraph(site_regexp, contact_found, contact_search_status); 

// recommend for user dominiek
social_graph.contacts_for('http://www.iknow.co.jp/user/dominiek'); 

When doing a search, about 8 to 40 calls are done to the SocialGraph API to walk through all the data. That’s one of the reasons why I really love JSON – all of this stuff is done on the client side.

Please note that any profile URL used in gathering friends data has to be referred to or must refer some other XFN relationships. The more ‘me’ and ‘contact’ links, the better the results will be. iknow.co.jp is actually a very good example of this.

Note: a fellow developer (Zev Blut) pointed out to me that instead of fooling around with too many regular expressions it’s good to look into Node Canonicalization

Recently I’ve been working a lot on thinking out and building up the upcoming Data Services for iknow.co.jp. I’ve composed a quick slideshow of all the architectural choices and considerations I’ve come across.

Building API’s for a web 2.0 / web 3.0 aspiring service is very different than providing a tight integrated RPC service for some corporate client. It requires completely different ways of thinking and embracing new standards.

| View | Upload your own

This is a more extensive writeup of a problem I have talked about before. It’s about something many of us web innovators face today. Like many problems, they can be turned into opportunities if implemented well.

The new Web – let’s stop using 2.0 – is much more than social networking sites and round cornered layouts. As Tim O’Reilly said, people who think Web 2.0 is about AJAX are completely missing the boat. This is true, but it is important to keep in mind that the shift from desktop products to web services is a big deal. Online services are already gaining a lot of productivity for people and thanks to the characteristics of the web the companies developing it can distribute and evolve much better. So this means that certain value adders have now migrated to the web.

What is happening now is that many of these online services want to be able to harness the power of the new social characteristics of the web. People have their friends online now and there is a lot of activity between those people and services (UGC). Everybody wants to tap into this attention stream between people. It helps contextualize your offering and helps spread the goodness between like minded.

Unfortunately, getting this social activity going around your service is not easy. And frankly, most of the time it results in creating another lousy SNS with worse social features. Fortunately, most online services open up their API’s allowing you to integrate with their services to create a mashup.

• rate, review and discuss cheeses
• have support groups like: ‘Why is cheese so expensive in Japan?’
• add cheeses they’ve eaten, for example through IM or mail
• upload/import pictures of their cheese related experience
• provide little cheese diary entries for the real fanatics

• using Twitter to add and rate cheeses
• using Flickr to upload/import pictures about cheeses
• using Tumblr to provide journal functionality

We could use one of those create-your-own-community sites like Ning, but than we can’t build our core business around it: selling and recommending cheese based on their attention profiles. Fulfilling all cheese needs to our customers is why we exist.

Mashing up a service like this using Twitter, Flickr and Tumblr is easy. Turning that mashup into a success is nearly impossible. The problem lies in the shallowness of the way we do mashups now. People need a Twitter, Flickr and Tumblr account to use all functionality in our system. Explain that to the 60 year old French cheese farmer who just plugged in his DSL modem!

Now, I don’t want to start debating about web savvyness and targeting certain markets. My main point is that there is a certain flaw in all API’s: You need to register with the API provider in order to make use of the API anywhere.

• our cheese shop is using OpenID
• our cheese shop can create a new OpenID easily
• the services we integrate with are using OpenID
• the services allow first-time use of their service without ANY burden to our customers (truly seamless)

I think OpenID is the path we are moving towards, although I’m sure that at first most services will not be prepared for the seamlessness we want. Also, I have an interesting scenario for the case that OpenID doesn’t take off (will save that one for later).

Services will be able to focus on their core added value by specializing. Building things that have been build before is an extra baggage that seamless integration can fix. Also, when a service continues to specialize it needs to be thinking from the very start about it’s own integration in the collective. In our Cheese example, our service should have an API from day 1.

But right now, most services are not ready for this seamless integration. If FlickR would allow use of their API without showing any FlickR logos or Flickr ads, how would they make money? What if we want to display our own CheesR logo everywhere and completely exclude the user from knowing FlickR is used?

This is where Freemium Integration is born.

Right now, most popular services offer API’s. If you look carefully most of them don’t guarantee any service with the exception of Google’s. API’s are in their very early stage.

Soon, API’s will become the core of any successful online service. They will be the door to most of the revenue. Services will continue to specialize in the things they do well, recommending wine, recommending books or providing entertainment you appreciate. This specialization might go on to a point where there will no longer be an actual site, but just a widget, API, Facebook Application or some other integratable entity.

These integratable entities – that I will just call API’s for now – will have several ways of generating revenue for their creators.

• Free Integration. This could be either seamless or semi-seamless integration together with in-content contextual advertisement. In order to make these advertisements contextual there will need to be some kind of Attention Profile exchange between the two parties.
• Premium Integration. Seamless integration without brands or attention debt. The client-party will have to pay the provider an Amazon AWS like compensation for usage.

I think over the next short-term march towards the first intelligent agents, it is important to keep the API in mind. Make sure that your online service can be used with or without OpenID and that third parties can integrate seamlessly without any hassle. This also means changing your mindset towards branding since this is a concept likely to change very rapidly soon.

The purpose of this article is to spark discussion from the community. Have any of you encountered a similar discussion or desire for seamlessness? Any opinions welcome!

Twitter is great, and this small 5 million $ company is growing like crazy. The core of their service is inherently simple: blogging/chatting with no longer than 150 characters. They opened up all of their API’s and Twitter is now flurishing with activity. Hell, we even integrated it in our language learning platform: http://iknow.co.jp/ (more to come) It’s only the first step however, these services could open up even more!

iKnow is a service that specializes in online learning and therefore the SNS part of the site is nevertheless important but still secondary. Right now in our service iKnow you can upload a picture together with your journal entry. It would be nice if we could provide more picture uploading and managing functionality, but we don’t want to build that. Flickr specializes in these things and would make a nice addition. Unfortunately, a service like Flickr doesn’t provide a real transparent API yet – people still need to register for a Flickr account.

Also, it would be nice if could provide status updates for all people on the website using Twitter – but people still need to go through the registration procedure at Twitter.com to be able to use it. I think the next success in web integration lies in opening up your API’s to an extend where it is completely transparent to use them. You don’t need to worry about registering at the third party service.

But what about the revenue? If people don’t come to your website anymore, you cannot get any advertising money! That maybe so since most sites still rely on people being exposed to banners/adwords on their website. These things will change however:

• there will be in-content advertising, an example is the already emerging in-video ads
• the freemium model will also be applied to API’s. A free API is for personal use, a premium API is for integration use in other web services. This premium API will not require you to let people pre-register at the very least.

The big picture really makes sense: online services will be more specialized. Right now you could imagine that photo management is done by something like flickr/picasaweb, status updates by twitter, music integration by last.fm etc. But things could fragment even more when there is an open integration market: facebook-style wall service, embeddable message/mail service, tagging service, rating service or image cropping service. An example of the latter is PicNik a service recently integrated into Flickr.

sidethought: will this kill branding?

At the moment I’m working on a little web-IRC client. My intention was to use the Ruby-IRC Framework, but I’ve decided to write my own API for the following reasons:

• It is impossible to establish multiple connections (multi-user) in the same process
• Event-handlers can not be flexible.
• After disconnecting it’s almost impossible to reconnect using the same instance or a new one.

Now I have a slim SSL capable IRC API that fulfills all my needs.

Click here to view examples and documentation

Click here to download the API (Beer-Ware Licensed)

example IRC client:

require 'EyeAreSee'

irc = EyeAreSee.new("EyeAreSee", "irc.darkwired.org", :ssl => true, :channel => "#test")

# catch all lines for debugging
irc.on_message { |line|
  puts "debug: "+line if $DEBUG
}

# catch all server messages, eg nickname already in use
irc.on_server_message { |event|
  next if event[:code] == 372
  puts event[:code].to_s+": "+event[:message]
}

# handle 372 messages (Message of the Day)
irc.on_server_message(372) { |event|
  puts "motd: "+event[:message]
}

# display all messages directed to the #test channel
irc.on_message("privmsg", :to => "#test") { |event|
  puts event[:from_nickname].to_s+" says: "+event[:message].to_s
}

# auto-response to private message from specific user
irc.on_message("privmsg", :to => "EyeAreSee", :from_nickname => "Drakonen") { |event|
  sleep(rand*10)
  responses = ["hmmmz", "boeiend", "interessant"]
  irc.message event[:from_nickname], responses[(rand*3).to_i]
}

# display all messages directed to the #test channel
irc.on_message("privmsg", :to => "#test", :message => "please go away EyeAreSee") { |event|
  irc.message("#test", "OK "+event[:from_nickname]+", bye everyone!") 
  irc.quit
}

irc.start
irc.start #reconnect once after a quit