This problem has been bugging me for the past few weeks - should web application APIs, such as the ones that Twitter, Pownce, Digg, etc. employ, require the programmer to authenticate by some means, or should it simply be open access? There are very good arguments for both, but the choice lies within the type of API it is. If the API provides sensitive data, such as the Twitter API, some sort of authentication should probably be used. If the data is public anyway, such as Digg, then no authentication is needed.

No Authentication: Easiest on the programmer side, hardest on the service that is offering the API. It allows those using the API to dive right in - no need to sign up for a project id or a username and password combination to authenticate with. The programmer can start playing right away; however, the downside is that the web service offering the API find it much harder, if not impossible, to track any API abuse. The service provider must weigh the benefit of allowing programmers to dive head first into the API with how crucial tracking is.

Username/Password Authentication: The opposite of open access is of course closed access - the programmer must provide a username or password to access any data from the API. Now the web service can easily track who and when a program/script requested information from the API; though, the downside is that the programmer cannot start playing with the API immediately.

APIs that provide the programmer with sensitive data should use some sort of authentication method. For example, using the Twitter API a programmer can request information from a "timeline" of user activity - the programmer then needs to supply authentication for that user. That way data sensitivity is not compromised.

Digg however employs a method somewhere in between these two methods - a username and password is not required but an application ID is. When requesting data from the Digg API the programmer must provide an application ID that he created. This proves to be a happy median because the programmer can start playing with the API right away and Digg can also track when the application ID is used, the only problem arising when a two programmers choose the same application ID for their project.

Once again, the type of method is dependent on the project. If sensitive data is being requested, of course authentication is needed. If the data is publicly viewable to begin with then no authentication is needed, but you might want to consider requiring an application ID so the program/script can be tracked.

Using a Unix time stamp, or POSIX time stamp is a quick and fast way to represent a point in them. A Unix time stamp returns the number of seconds since the Unix epoch, January 1, 1970; however, it does not count leap seconds.

To create a Unix time stamp function exactly like the one in PHP, you first have to realize that JavaScript calculates to the millisecond instead of just the second. Obviously, you can either divide by 1000 or take the first ten characters of the substring.

The following function excepts an optional date object as a parameter and returns a Unix time stamp equivalent to the one PHPs time() function would return:

• 1.
• function getUnixTimestamp(timeObj)
• 2.
•  {
• 3.
•   var dateObj = null;
• 4.
•  
• 5.
•   if (timeObj != null)
• 6.
•    {
• 7.
•     dateObj = new Date(timeObj);
• 8.
•    }
• 9.
•  
• 10.
•   else
• 11.
•    {
• 12.
•     dateObj = new Date();
• 13.
•    }
• 14.
•  
• 15.
•   return (parseInt(dateObj.getTime().toString().substring(0, 10)));
• 16.
•   // alternatively, the following can be used:
• 17.
•   // return (parseInt(dateObj.getTime() / 1000));
• 18.
•  }

This function, while extremely basic, will prove to be useful in the next blog post where I will show you how to calculate relative times similar to Twitter and Digg. ex: "1 day 23 hours ago" or "10 minutes 3 seconds ago".

Re-post from DiggMatch

Digg released its recommended user/story algorithm last week - this algorithm had taken them over a year and a half to develop and I must say, I am very, very disappointed. As a social news website first, and a social networking website second, the focus of digg should always be on the stories. Sure, it is nice to find users that share my digging tastes, just like it is nice to find people to share my listening tastes over at last.fm, but I do not go to digg to meet new friends - I go there for the content.

And as for the amount of recommended stories, digg offers me three to look at. Three stories. Thats it. Out of the thousands and thousands of submissions per day, there are only three that match my digging tastes. Once again, I stress the point that while social networking is nice, social bookmarking is what digg.com is all about.

The difference between the digg recommended story/user algorithm and the RIMA powered algorithm is simple:

Digg - Long Term Relationship: Long term relationships are hit or miss. Sure, you may be happy for the rest of your life, waking up next to the same algorithm everyday, eating the same thing for breakfast, and driving your matching Prius to work. But there is an equal chance that the relationship could end badly. You could catch the algorithm in bed with another byte of code - the entire relationship, built up to one tragic end. Using the social networking road builds a list of friends with (somewhat) similar digging tastes, which in turn gives you a posse of diggers to promote any story your submit. It may work, or it may not. It is hit or miss for every user.

RIMA - One Night Stand: Couples fight, couples bicker, and couples who have been married for a long time never have sex. What is the fun in that? Sometimes I just want to get my digging rocks off to a story that interests me - I do not have the time to meet a bunch of friends and "network" myself around. I go to digg for the stories and thats what I want recommended to me first, users second. In the end I may not have as many friends as I want to, but at least I will be satisfied.

Which method works best for you? Let me know, I am curious.

My pride and joy - well so far at least. I finished up a specification on the algorithm I used to write DiggMatch. The algorithm is used for information retrieval, specifically taking a set of data, indexing it, then comparing other entities of data against the indexed set to see how related the entity and the table are too each other.

For example, say you were to visit the New York Times website every day for a week and save the text from stories that interested you. The indexing portion of RIMA could be applied to the saved text, creating a table of data. Then for every subsequent day, any given story on the NYT website could be compared to the table using the match portion of RIMA. A score would be returned representing the relevancy between the story and the table - the higher the score, the higher the relation. Using RIMA, a programmer can create a "recommended set of data/text" for a website, an essential part of any new web application.

RIMA can be downloaded in pdf format or viewed online in html.