Hi5 (yet another social network) is launching their OpenSocial based platform today (well really tomorrow and over the next few weeks) and have done a really great job communicating with developers how stuff is going to work. For example, letting developers know what will and won’t be working in their release plan. Facebook and MySpace could learn a good lesson here in communication. Stop being vague with your plans and let your developers and advocates know what’s up. Facebook has made some great strides with their notifications around larger platform changes, but the small stuff is still an open question.

The blog has been picked up by spammers. We are now receiving daily spam comments. This would be inconsequential, however, until only a few days ago I had a site map that did not include the blog entries thus preventing it from being indexed by Google. I removed that map around the 19th and so Google has since indexed the blog pages. I believe spammers are using Google (and possibly other search engines) to locate sites running WordPress and other blogging software and adding them to their bots in hopes the blogs are unmoderated. I know nothing earth shattering here, but curious that until I was indexed by Google’s search engine - not a single spam comment. I noticed a similar effect on my personal blog when I removed the registration requirement (still moderated) for posts.

Today I noticed a new tab in the application editor making it infinitely easier for developers of OpenSocial applications to adopt the MySpace platform. I first said they should be doing this two weeks ago and I’m happy to announce that they are. They now allow for the simple monolithic XML file to define your application. This is a great step forward. Their platform is becoming more robust and stable each day. Kudos to them, but they still have a lot to do as Nick O’Neill pointed out yesterday.

I spent some time yesterday reading up RFC’s on URI encoding for use with OAuth. More specifically, I was getting a handle on how different languages interpret and encode assorted character strings. What I learned is that JavaScript and PHP do not get along well. Even a benign string like “Hello world!” is not escaped consistently between languages.

In his article, Marc Worrell spells out in detail the differences between assorted encoding standards in PHP, Perl and Javascript as well as between different RFC’s. He even provides a great (and simple) function which escapes strings in PHP. I highly recommend taking a look at his page.

What he did not do was show the differences between encodeURIComponent() and escape() in Javascript. It turns out neither are compatible with RFC 3986, and more specifically, the “!” character caused me a bit of grief. Why is this important to OAuth? Because properly signed signatures require identical strings in the hashing alogrithm. Because “!” is not “%21″ a computed hash value would differ resulting in a nightmare when trying to validate signatures. As it turns out, encodeURIComponent() does a pretty good job, but there are a few other characters that are improperly escaped using the built in javascript function.

So I wrote a prototype method to handle the discrepancies and offer that here for folks who might require just such a method.

String.prototype.to_rfc3986 = function (){
   var tmp =  encodeURIComponent(this);
   tmp = tmp.replace('!','%21');
   tmp = tmp.replace('*','%2A');
   tmp = tmp.replace('(','%28');
   tmp = tmp.replace(')','%29');
   tmp = tmp.replace("'",'%27');
   return tmp;
}

Usage is very simple - when you require an encoded version of the string, simply call the to_rfc3986() method. You could easily make this a standalone function if you wanted.

var mystring = "Hello world!";
alert(mystring.to_rfc3986());

I saw on Forbes this morning that Time Warner is buying the social network Bebo for $850 million. My experience with Bebo hasn’t been great so far, it’s a blend of the best parts of MySpace and Facebook, but without the reliability or audience size of either. Granted my experience has been narrow - focused primarily on application development after they launched their platform based on the Facebook’s FBML.

AOL, the Internet division of Time Warner, said on Thursday that it was buying the social networking site Bebo for $850 million in cash, placing it in position to go head to head with News Corp.’s MySpace as well as Facebook.

What AOL fails to realize is that it’s original online presence was in fact a social network that they channeled into a portal. Now they’re looking to buy the 3rd - albeit a distant 3rd - largest social network to regain their original community of users. Kind of sad actually. Stats on the top 3 networks from complete.com below. Notice bebo’s not much more than a blip on the radar of MySpace and Facebook. As they say, “good luck with that.” I hope they don’t spam all the Bebo users with free AOL CD’s.

This evening I had the opportunity to implement what should have been a simple OAuth signature validation until I ran into trouble parsing the parameters of the request. I decided to use one of the many pre-built libraries instead of rolling my own (perhaps that’s where I went wrong) but I found that it wasn’t as easy as I had expected.

A quick primer for those unfamiliar with PHP, there are multiple variables that hold request information. The two most common for passing parameters to a PHP script are $_GET and $_POST, which are both associative arrays. PHP handles the encoding of the values and brings everything back to regular strings. This is very handy for passing data. There is one more useful structure called $_REQUEST that actually holds both sets of values in one structure - also very handy if you don’t know where your data will be coming from on a given request. Now back to my issue.

OAuth augments your parameters with a few specific values that are unique to it’s implementation and uses a shared secret key system to digitally sign requests providing a level of trust with any request. If your lost with OAuth, I wrote a quick primer about it a month or so ago. OAuth takes any data you pass and signs them into a hashed value by concatenating the data with the shared secret and a few other parameters. The resulting hash is then very unique and very difficult to guess. On the server side, you can now validate the request by looking at the parameters and re-calculating the hash value.

While that’s simple in theory, it’s a bit more difficult in practice, especially with MySpace’s implementation of OpenSocial and OAuth. Yesterday I blogged about how to make AJAX requests using OpenSocial. As a habit, I always default requests to POST when possible to get around any arbitrary data size limits that might be present and to keep data out of my log files. This resulted in quite a bit of drama trying to implement the signature because the library wanted to evaluate the POST parameters and MySpace sends them as GET values. I tried tweaking the library to use the generic $_REQUEST parameters, however, the $_POST values weren’t included in the hash! As a result I ended up moving all requests over to use get - which was very simple.

Below you’ll find the revised GET friendly code:

function ajaxRequest(url, callback_func, post_params){
   var queryString = "";
   for (k in post_params) {
      queryString += "&" + k + "=" + encodeURIComponent(post_params[k]);
   }
   url += "?" + queryString;
   var osParams = {};
   osParams[gadgets.io.RequestParameters.AUTHORIZATION] = gadgets.io.AuthorizationType.SIGNED;
   gadgets.io.makeRequest(url, makeRequest_callback, osParams);
   function makeRequest_callback(data){
      renderStatus("Handling ajax response with typeof: " + typeof(data.data));
      var json = gadgets.json.parse(data.data);
      if(!json){
         alert('Unable to parse JSON object');
      }
      callback_func(json);
   }
}

Now you can use the OAuth libraries to parse your signature in PHP and verify who’s posting to your data points. Don’t forget to s/_POST/_GET/g your code to update all POST references. It seems like a bug to me in the implementation that if the request is made via POST the parameters wouldn’t also be passed in the same way. Perhaps there’s a method to the madness I’m not aware of?

Two MySpace developers posting on a thread regarding requestNavigateTo within the MySpace environment need credit for this one. Kristaps and Eric posted a discussion which included some nice brief code snips. The code is short and sweet. All that’s required is a surface name and any optional parameters you would want to pass to that surface. Note in OpenSocial 0.7 “surfaces” are now known as “views” which might throw some developers for a loop as they make the transition.

function navigate(surfaceName, params){
   var surfaces = gadgets.views.getSupportedViews();
   var surfaceRef = surfaces[surfaceName];
   gadgets.views.requestNavigateTo(surfaceRef, params);
}

Valid views within MySpace (as of this time) are home, profile, and canvas. Sample usage for moving to the Canvas view from the profile (or home) would be as follows:

<a href="#na" onClick="navigate('canvas',{});" title="Move to canvas">go to canvas</a>

After much frustration debugging a tweak from OpenSocial 0.6 to 0.7, I decided I’d capture the essence of my code in one location for others to look at it. This walks through the basic structure to make an AJAX request using MySpace’s implementation of OpenSocial. It should work with other OpenSocial 0.7 compliant sites as well.

This is the core of the functionality - where all the magic happens - a function called ajaxRequest(). As you see it takes 3 parameters, the URL to post to, a call back function and an object/array containing any data you would like passed via post.

function ajaxRequest(url, callback_func, post_params){
   var queryString = "";
   for (k in post_params) {
      queryString += "&" + k + "=" + encodeURIComponent(post_params[k]);
   }
   var osParams = {};
   osParams[gadgets.io.RequestParameters.METHOD] = gadgets.io.MethodType.POST;
   osParams[gadgets.io.RequestParameters.POST_DATA] = queryString;
   osParams[gadgets.io.RequestParameters.AUTHORIZATION] = gadgets.io.AuthorizationType.SIGNED;
   gadgets.io.makeRequest(url, makeRequest_callback, osParams);
   function makeRequest_callback(data){
      renderStatus("Handling ajax response with typeof: " + typeof(data.data));
      var json = gadgets.json.parse(data.data);
      if(!json){
         alert('Unable to parse JSON object');
      }
      callback_func(json);
   }
}

Now that we have this tool, using it is very simple, first create a call back function that takes your JSON result and does something with it, then invoke the ajaxRequest by calling the ajaxRequest function using your parameters. That’s it.

function ajax_callback(jsonData){
   // do something with the data!!!
}

ajaxRequest("http://www.af-design.com/", ajax_callback,{});

I hope this saves some developers some frustration reading through the OpenSocial documentation and helps them get their apps up and running more quickly.

Today MySpace announced that the shift to OpenSocial 0.7 is completed and now they’re actively debugging it. The problem is, that most of the critical components, such as the ability to make AJAX requests, for any company looking to more widely leverage their existing databases are unable to do any testing at all! After setting aside my fears that OAuth wouldn’t be implemented in time, MySpace delivered yesterday OAuth signed requests. I’m really thankful that we can now use OpenSocial 0.7 within their container, but I’d be much happier if it all was working more than 48 hours before the soft launch. Their relay proxy machines have been down for nearly 12 hours now, putting a great crimp in development time. Does Rupert Murdoch own a pizza delivery chain or a significant interest in Red Bull?

Compete, one of my favorite website metric tools, shows an interesting trend between three bloggers, two of whom I have met (Rodney Rumford and Nick O’Neill) and have a great deal of respect for. But neither the merits of these individuals or their websites, is the point of this discussion. What concerns me is the lack of quality metrics for this type of comparison. Google Analytics may have the best approach to solving this problem yet. With their new data sharing options, it will be possible for website owners to more accurately track their performance against other websites, including their perceived competitors (assuming they’re running Google Analytics too).

Alexa also offers online metrics and shows some similar trends but neither get the whole picture because the technology used to capture the data is browser based - ie, you install a plugin/toolbar and away you go. This doesn’t accurately capture many devices, including the quickly growing mobile device market, game consoles and non-plugable browsers (Safari anyone?).

Google’s AdSense tool has some drawbacks as well because JavaScript is device dependent - but over time that will become less of an issue as devices become more and more robust. Full integration of plugin enabled browsers on the phones seems much MUCH further away.

Michael Arrington pointed out on TechCrunch, that a share “With Everyone” option was needed. While we can certainly create accounts that have read access to our data and publish that information on our sites - it might be nice to get a 30,000 foot view of multiple sites without needing to authenticate to each and compare the numbers manually. I suggest a full Compete / Alexa type interface allowing users to explore not only a single site, but trends within a vertical, industry or even across industries is where the real data is.

Does the slow and steady decline of these three sites over the last few months indicate burn out on Facebook or is their user audience switching to MySpace centric blogs and news sources? I want to know and quite frankly, I don’t have a good way to find out.