The Blog

The Social Network Wars Begin In Earnest: Facebook Bans Google Friend Connect :

Why do all journalists have to frame issues as a war?

The first few widgets available on the Friends Connect OpenSocial hosted platform are from Google and in there is an OpenID Signin, and a Friends viewer. And also in there is a Facebook application. And it's this Facebook application that is calling Facebook's bluff.

Either Facebook's Connect API let's you use Facebook's auth and gives you access to your friends. Or not. And on the surface the answer is "Yes, as long as we like you". But even this isn't clear. FB appear to be saying that you can get and store ID numbers, but you can only display your contacts' data on the fly.

Which finally brings us down to a privacy debate that is central to the whole data portability drive as it relates to your list of friends. You have a claim on your own profile data. You have a claim on your list of friends. But you *don't* have a claim on your friend's profile data. And in that context Facebook looks like it's trying to do the right thing while also using it as a core part of their business model. Google is also trying to do the right thing from the public access point of view. Actually your friend's profile data is public information. And public information wants to be free.

Prying Open the Social Graph - GigaOM :

I'm seeing an amazing number of articles that are criticising Google Friends Connect for not being about data portability and locking your data into Google.

So. Look at this in the context of Google promoting OpenSocial instead of in the context of Google opening up and providing data portability. OpenSocial is now 4 things.
1) An API for building widgets
2) An API for building a container for widgets for big web sites
3) A REST API for accessing the underlying data and mashing it up
4) A Javascript wrapper to a hosted container on Google for dropping onto small websites

Look at it like that and Friends Connect looks like an entry level container that widens the market for widgets by vastly increasing the number of places your widgets will run. They've managed to hide all the complexity of building a container or installing and integrating ShinDig into one line of javascript. Isn't that an amazingly clever thing that will have at least as much effect as wrapping Google Maps into a snippet of javascript that anyone can use?

So nice to get a big win. There's been an ongoing, unanswered question in DataPortability. If we use XRDS-Simple as a way of listing services that the user provides, how do we know what URI to use for common service types? It felt like we needed a big list of service types that developers could agree on. Both those building XRDS files and those consuming them.

For some services, this seems relatively straight forwards. For instance a FOAF file in RDF-XML would have an entry in XRDS that looked like this.

<Service priority="1">
</Service> is the xmlns for FOAF, it redirects to the FOAF specs and the FOAF community have committed to maintaining the URL indefinitely. The MediaType is shown as RDF-XML to distinguish from N3 although this is optional because it will be discovered when a consumer GETs the file.

But for some services this is going to be harder to identify and is going to require some buy in from the community developing the service type. For instance it's not immediately obvious what the Type should be for the page containing my Microformatted list of Profile pages marked up with rel="me". One possibility would be But there's no guarantee that will be around for ever. And we'd want to break it down a little more. We really need 3 types for
- My profile page
- My list of external profiles
- My list of contacts

Anyway, we made contact with Gabe Wachob, one of the architects of XRDS-Simple and he announced last night to be both a clearing house for the big list of types and if necessary to be a place to host a Type URI.

Until this gets going we'll probably start a list on the DataPotability wiki.

I've been looking round a number of OpenID providers this morning. Almost all of them have kept up to date and are providing an XRDS file discovered though an http header when you GET the human memorable openid URL. I know I'm repeating myself but one way of looking at this is that they are all hosting a personal home page and then delegating from there to the actual openid server. This makes sense as it leaves their options open to add profile or other information to that page at some earlier or later date. So I'm still feeling the same way which is that the Service Catalogue should generally be the XRDS discovered at the home page. One of the entries will be the OpenID Server, either directly, or by a further redirection through the home page at the Service Provider. This makes it all a consistent method of finding it. And it allows us to attack the problem both at the OpenID Providers and via people's home blogs, or through their favourite Social Network.

Now say I have an XRDS at Voidstar which points through to the XRDS at MyOpenID which then points to the MyOpenID server. And say both I and MyOpenid have XRDS entries for other Services. The Relying party site really needs to aggregate all the XRDS entries into one list. It could get the profile service from MyOpenID and the Contact List service from Voidstar.

What we really need is for the JanRain Yadis library (and others) to return all this metadata to the calling program as part of OpenID discovery. The list of XRDS URLs found along the way and a list of the services in each one.

I like this. It then doesn't matter if the Service provider, the blog or some other site, hosts bits of the Service Catalogue. They can each contribute what they know. They can each choose whether to play Home Page Provider. It means we're not dependent on the OpenID provider but they can play along too.

As well as the parsing problem, I really need help on constructing appropriate entries for services within the XRDS file.

The May DIY Project from the DataPortability project is to produce and markup blocks on people's websites and blogs with XFN rel="me".

Well firstly I've already done this some time ago. On the left you'll find a block giving every profile page where I've signed up for a service. Each link is marked up with the rel="me" microformat.

As a side effect of doing this I built a small test rig for navigating round these links and links like them. I started by using Google's Socialgraph API but that works on cached data and I needed something current.

That led me to trying to find libraries in PHP for parsing Microformats. Which in turn led me to an impassioned debate on the Microformats list. The gist is that you really, really don't want to write an HTML parser in any of the more common web programming languages. To me this means that Microformats are effectively write-only data when we're talking about App to App communication. That's not to say that they aren't useful. But App to App communication needs nice elegant standards with robust and formal definitions. Which is why most of them are based on XML. Burying the data within horrible, badly written HTML by marking up visible elements is just wrong. At least for App to App communications.

However, there is still merit in marking things up with microformats because firstly it's easy to do, and secondly you can use tools like the Firefox plugin Operator to grab them. Extracting a VCard from a web page you're looking at and dropping it into your local contacts store is a great use case.

So finally we get back to XFN and rel="me". Now it turns out that if you put the html through tidy so it's well formed XML and then query the nodes, it's relatively easy to extract all the XFN entries. Here's some sample PHP5 code which uses the loadHtml() function to do the HTML Tidy for you. The source HTML has to be really bad before this fails.

$url = '';
if($html = @file_get_contents($url)){
$dom = new DomDocument();
if ($nodes = $dom->getElementsByTagName('a')) {
foreach($nodes as $node){
if ($node->getAttribute('rel')=='me') {
echo $node->getAttribute('href');

This gives us a route into querying something like my MyBlogLog page or my Plaxo Pulse page and finding all my profile pages so I don't have to type them all in yet again to the next service (FriendFeed, say) that wants the same data.

There's a side effect of putting your YASN-Roll (Yet Another Social Network Rollcall) on your weblog. It's great for self-publicists! Why wouldn't you want your blog readers to be able to find you on Twitter, Upcoming, Facebook, Plaxo and all the other places you hang out. Which finally brings us to the last part of the DataPortability DIY project. "Adopt an Alpha Blogger". This is where we go and hand hold a well known influential blogger, encourage them to "walk the walk" and get them to build an XFN enabled YASN-Roll on their blog.

And last but not least, if you run Wordpress, you don't have to do this by hand. Stephen Paul Weber has built a plug in for wordpress that does the hard part for you as part of the DiSo project.

I'm not sure why but I've been avoiding talking about Data Portability. It's time to change that.

Here's some thoughts on one of the primary Use Cases. This is aimed at initial population of a profile during signup to a service and the automatic finding of existing contacts already on the service.


* User U
* User's Home site/page H
* XRDS at the Home Page URL SC (For Service catalogue)
* New site where the user is signing up. N
* XRDS at the new site NX
* User's OpenID provider S (For Service Provider)


1) The User goes to the N Site's Signup page, where there's a field for OpenID.

2) The User puts their Home Page URL into the OpenID field.

3) The new site N uses XRDS discovery to retrieve the user's Service catalogue SC.

4) N reads and parses the SC looking for three things. Some of these may be combined.

* OpenID Service Provider and delegated ID
* Service providing Profile information SP
* Service providing Contact lists SCL
* Service providing a profile page URL list SCP

5) User is redirected to the OpenID Service Provider

6) The Service Provider looks up the N site's XRDS NX and confirms on screen that everything looks ok.

7) The User confirms that they want to sign in to the new site N

8) The user is redirected back to a profile form on the new site.

9) The new site N uses the Profile Service to retrieve the profile and populates the profile form with the data.

10) The User confirms that the profile data is correct

11) A new account is created with the profile data, the home site URL, the home site XRDS location and the OpenID key passed back from the service provider.

12) The new site N uses the Contacts list service SCL to retrieve the user's contacts.

13) The contact list is matched off against the existing member base. The new site can do whatever fits their business model. eg

* Make connections automatically
* Offer to follow all or some of them
* Send friend requests to all or some of them

14) The new site uses the profile page service SCP to retrieve the list of the user's other profile pages. Optionally it tells the SCP that there is a new entry for the user's new profile page on the New site. It can then do additional work on this eg - Store a link to the list that can be displayed dynamically on their new profile

* Store the profile pages locally
* Query them for RSS

Notes, Options and Issues

1) XRDS discovery should use that described in XRDS-Simple. Priority should be given to the http header method since this requires the minimum bandwidth.

2) The XRDS file should follow at least XRDS-Simple

3) This process requires that the user has a home page that can provide XRDS and has a simple enough URL to be used as the OpenID login. This may be a private blog, or a hosted service. This is a bottom up approach and the larger systems that provide hosted personal home pages should be encouraged to host an XRDS file for their member's profile pages.

4) The three services SP, SCL, SCP should be widely used, formal standards with libraries available for consuming them. Priority should be given to RDF-XML FOAF with additional namespaces. Not least because common usage of FOAF can handle all three services in a single file. However, there is a lack of a de facto standard in these areas. It is hoped that libraries appear to hide the complexity and to query and return common structured data from other systems such as the OpenSocial APIs, Google Contact APIs, MS Live Contacts and so on. hCard and XFN can be used providing ways can be found to parse them reliably and to encode all the required information.

5) The Contacts List service should provide at least one (and preferably more than one) common Inverse Functional Property such as mbox_sha1sum to aid matching with the existing members.

6) FOAF (like Atom and RSS) already has an auto-discovery method. This could be used in addition to XRDS. But work should be done to encourage moving to XRDS- Simple as a single auto-discovery method.

7) Standards, documentation and examples are needed to define how to code the three services in an XRDS file. And this has to allow for several possible service types for each entry. So a Profile Service entry might have several service entries of different protocols in a priority order

8) Properly parsing FOAF requires an RDF approach. It may be possible to recommend a structure that uses FOAF-XML and other preferred namespaces (such as vCard) into a form that is parsed by a simple XML parser.

9) It is assumed above in the process description that the three services do not require authentication. If they do then each should use their own authentication and discovery methods and work should be done to try and make this seamless to the user. It is recommended that oAuth is used by these services.

10) No attempt is made here to provide alternate personas through a single home page URL. The simplest solution is to use a different home page URL for the 2nd Persona.

11) It is also assumed that the OpenID provider concentrates on authentication and not profile/contact list management as well. OpenID Service providers may choose to do this. If they do then the service should be defined separately in the XRDS service catalogue. This goes against the development direction OpenID was taking with sReg and AX to combine this into a single service and so may cause some push back.

Resulting Actions

1) Work with the XRDS-Simple people to define, document and give examples of entries for common services.

2) Work with and encourage the DiSo (and others) people to develop plugins that create and manage an XRDS file for the common blog platforms. Work with them also to build plugins to create other related systems such as the microformatted list of the blogger's profile URLs. Help them to document these plugins as they are written, with examples.

3) Work with the OpenID people and JanRain to enhance and extend the Yadis auto- discovery libraries to parse XRDS and provide the service entries in an easily digestible form during the OpenID discovery process. Document recipes and examples that build on the Plaxo OpenID consumer guide on implementing a DP aware OpenID consumer

4) Work with the FOAF people to come up with a recommended set of namespaces, best practice and file layout-structure that is easy to create and read. Help and encourage the development of parsers that understand this best practice layout in all major languages. Work to define, document and give examples of putting private FOAF behind oAuth.

5) Work with the microformat people to define, document and give examples of best practice use of microformats. Help and encourage the development of parsers that understand this best practice in all major languages.

6) Work with the people developing the other major profile and contact list standards to make sure their standards work well with the "Profiles and Contacts population during initial signup" use case. include them in 1) above.

7) Develop and demonstrate prototypes of all of the above.

8) Encourage bloggers and the smaller hosted services and networks to implement the above. In particular, working one to one with the so called "Alpha-Bloggers".

Today's opinion
Hot: OpenID, oAuth, XRDS, XRDS-Simple, FOAF, OpenSocial Data APis
Cold: Microformats, hCard, XFN contact lists, OpenID AX
Indifferent: APML, OPML, MS Live Contacts

The site maintenance over the last weekend went smoothly and I hope you're enjoying the much increased speed of the Ecademy website. We have two problems as a result.

Some people have been receiving email from the site that is dated December 2007. It seems we had a large queue of email that had been held. When that was copied across, the new email server finally delivered it. If you receive email notifications, particularly about subscription problems, that you weren't expecting then check the date. If the Sent date is very old, then simply discard it.

The main Contacts Search seems to have got out of step and some searches are not returning the data they should. This is currently being dealt with and should improve over the next day or so.

Julian Bond
CTO Ecademy [from: JB Ecademy]

We've now got Yahoo OpenID fully working to log into Ecademy.

1. Go to My Settings, Manage OpenIDs

2. Type in "" into the "Add a new OpenID" field and hit "Sign In"

3. After a moment and perhaps an intermediate screen, you'll be presented with a Yahoo screen asking if you want to log in to Click on the "Let Me In" button.

4. You're returned to Ecademy and your Yahoo OpenID is associated with your Ecademy account.

Now when you need to log in to Ecademy, the process is very similar.

1. Go to the login screen at Ecademy. Scroll down to the "Login with OpenID"

2. Type in and click Sign in.

3. You're redirected to Yahoo asking if it's ok. Click "Let Me In"

4. You're back on the Ecademy home page and logged in. [from: JB Ecademy]

Over the last couple of days and again this evening we've had some problems with our database server.

It looks as though a request for an RSS feed was being made very frequently and this particular request was launching a database query that was inefficient and slow. The combination was overloading the database and leading to the site being extremely slow or unavailable.

This particular problem has now been dealt with and should not arise again.

Please accept our apologies for the outage.

Julian Bond
Chief Technology Officer
Ecademy [from: JB Ecademy]

A second virus email has appeared with text about Ecademy, Subject: "ECADEMY will close work in April 2008". It appears to be from . Again it has a Yahoo Message-ID although it hasn't been anywhere near Yahoo's servers. The email has an attachment which contains document.exe which may be a Trojan or Virus.

One copy we've seen was sent from a Korean home broadband PC using Outlook Express. This makes it look as though it's being sent by a botnet of infected PCs round the world.

Needless to say this is not from Ecademy, and is in no way connected with Ecademy servers, systems or people.

Ecademy never sends emails with attachments.

Ignore it. Don't open it. Delete it.

Julian Bond
Chief Technology Officer

ps. Here's the text of the email

Dear members, clients and guests of our portal,
Over the last few years our portal has helped you to organize your business, find new partners and increase sales.
However, all good things end. Many of you know that we have experienced legal problems over the last year. Our competitors from other social
networks are trying to take over our client base.
Our website has been hacked and our database was stolen. After that we were taken to court because of identity theft.
Unfortunately, legal expenses and unfavorable court verdict with following closure of our bank accounts will lead to closure of our website. All
paying members will receive refund starting from March 14th.
Please check attached file for legal information in regards to your account.

Best regards,
The Ecademy Team

Ecademy - The Social Network for Business People

Company Registration:7382702 VAT:718 0377 36
[from: JB Ecademy]

We will again be SkypeCasting the Ecademy Event tonight at 7:30. Details here.

To listen to the Skypecast, go to the page for this skypecast at 7:30pm UK time and follow the instructions. If you can't connect, try calling +99001110006940486

Skype Beta 2.6 has a Skypecasting directory built into the client. Recommended. [from: JB Ecademy]

We will be doing some engineering work this evening (Friday 22nd September) and expect some downtime. We plan this to start at about 6:30pm UK Time and last for about half an hour.

Apologies for any inconvenience caused. [from: JB Ecademy]

We're going to be running the Skypecast of the Ecademy event again tonight.

Details here. Starting at 7:30pm UK time.

Go to that page after 7:30 and follow the instructions to listen in. You'll need your Skype password to join.
[from: JB Ecademy]

Apologies to those of you who have received large numbers of emails from Ecademy containing an "EAP Report".

This report went live at the weekend and should have sent one report each week. A glitch in the code meant that the servers resent a copy every half hour or so. This has now been stopped.

Unfortunately this coincided with a problem with the mail server which meant there was a large backlog of email waiting to go out which included these multiple copies. Consequently we didn't catch the problem quickly enough. Sorting out the mail server and clearing the backlog then released the waiting copies.

The mail server is now delivering mail correctly. There may still be some mail from the backlog going out where remote mail servers were temporarily unavailable.

We're working on finding out why multiple copies of the report were sent to avoid this happening again in the future.

Apologies again for the inconvenience. [from: JB Ecademy]

We had an outage on Friday evening. This was caused by a loss of power to the database server. It took some time to bring the server back up and it's clock was then set back to 2002. All of that has now been sorted. No data has been lost but there may be some records with invalid timestamps which we will attempt to rectify.

While the clock was out a number of background tasks will have sent out emails incorrectly.

Please accept our apologies for any inconvenience caused. [from: JB Ecademy]

We had a hardware problem early this morning and again this afternoon around 4 to 5pm that meant that the Ecademy site was running very slowly. We're temporarily sorted this out and are currently investigating the cause to prevent it happening again.

Although this coincided with the new functions and changes going live, it was not actually related.

Please accept our apologies for any inconvenience caused. [from: JB Ecademy]

Key websites
- Twitterfeed Entries in an RSS feed copied to a Twitter account
- Twitter4Skype Twitter account updates copied to a Skype chat
- OpenID This page has a list of OpenID providers where you can get an OpenID
- RSS for your Ecademy status
- RSS for your Ecademy contact's status

Preparation. Get yourself an OpenID.

1. Copy your Ecademy status updates to your Twitter account
- Go to Twitterfeed.
- Log in with an OpenID
- Create a feed entry using your Ecademy status RSS
- Send it to your main Twitter account.
Every update on Ecademy also updates your Twitter

2. Copy your Ecademy Contact's status to a Twitter friend
- Create a dummy Twitter account (eg JBFeeds)
- Add this dummy account as a friend on your main Twitter account
- Go to Twitterfeed.
- Log in with an OpenID
- Create a feed entry using your Ecademy Contact's status RSS
- Send it to your dummy Twitter account. Prefix each tweet with: EC

Now you can see all your Twitter and Ecademy Friend's updates in one place.

3. Display your Ecademy Status on your Facebook profile
- Go to your Facebook profile.
- Add the Facebook Feeds RSS application
- Add the RSS for your Ecademy status as a feed

Your Ecademy status is now on your Facebook profile.

4. Add feeds from Facebook, Jaiku, Plazes, Ecademy to a Twitter Friend
- Follow on from 2. Seek out the RSS for all the other Status feeds for other services like Facebook, Jaiku, Plazes and add entries in Twitterfeed for them routed to your dummy Twitter user created in 2.
- Add a two letter prefix for each one like FB, EC, JK, PL

Now all your friend's on all your services can update their status and you'll see them all in one place.

5. Route all your Twitter updates to a Skype chat.
- Go here for a tutorial about Twitter to Skype.
1. Add twitter4skype as a contact.
2. Type the following as a single chat message to twitter4skype:

/account (alt+return)
yourtwitteraccountname (alt+return)
yourtwitteraccountpassword (alt+return)
3. The system should return: twitter4skype Registration complete!

All the status updates you've gathered together in 4. appear in this Skype chat. Set Notifications to off for this chat so it doesn't popup every 5 minutes. [from: JB Ecademy]

Here's a challenge.

You're in Thailand.

You have your UK passport.

You have a UK bank account with internet banking and money in the account . You don't have your cheque book with you.

You can get to an Internet cafe.

The ATM has just swallowed your Bank card.

How do you get cash in your hand? [from: JB Ecademy]

I'm going to try to Skypecast the London Event tonight with Don Tapscott for people who cannot attend.

At around 7:30pm (UK time), go to this web address and follow the instructions. You will need your Skype ID and Password. [from: JB Ecademy]

1 to 20 of 3789