TweetStats Down More than 24 Hours As Twitter Attacks Cache Issues

TweetStats: Closed Since Sunday Afternoon
On Sunday, we mentioned Twitter had run into a bug that masked the display of third party clients on the service, erroneously reporting all updates as coming from "Web", whether they were, or if they were instead from the mobile interface or any of the growing array of applications that interact with the microblogging leader. Now into Tuesday, the bug hasn't yet been fixed, and in the meantime, popular statistics tracker TweetStats has been shut down - incapable of operating correctly with bad data pouring in.

Twitter's API team is telling developers that the "from Web" issue is the result of large growth in the company's database, thanks to a recent increase in API developers and their registering applications to work with OAuth. The database object reportedly grew to a size incapable of being cached, dramatically impacting performance.

Still a small company, rather than push for Twitter's engineers to come in over the weekend to resolve the issue, the company said they chose the "quick solution", opting to "disable source parameters", according to postings on their Twitter API forum here.

Initial guidance was that the issue would be resolved "likely early in June 1 workday" (sic), but more issues have cropped up. The company followed up with a second note saying, "Due to problems with other *critical* code we've had to delay deployment of this fix until tomorrow."


TweetStats Reports The Trouble Sunday
TweetStats shut down mid-day Sunday after the issue had impacted the statistics gathering service dramatically. And while Twitter has again offered a new date of resolution, the developer, Damon Cortesi, has said he'll find a way to get rebooted, with or without help from Twitter.


TweetStats Hopes for Best, But Prepares...
He noted late Monday night, "If not fixed tomorrow AM, will re-open and deal with the consequences."

Jesse Stay has more around the details of the API issue here: Where is Twitter’s Emergency Response System?

Remind Yourself Who You Hate With Twitter's New Blocking API

By Jesse Stay of Stay N' Alive (Facebook/FriendFeed)

A little while back Louis shared the importance of not holding a grudge, encouraging the LouisGray.com readers to try to maintain relationships regardless of any blips that may occur during that relationship. Twitter just released an API which, if you're one to hold grudges, could rub it in a little further through applications which choose to use it.

The Twitter Blocking API enables Twitter Platform developers to retrieve a list of all the users any authenticating user has blocked, enabling them to help you manage the past blocks you may have forgotten about. Fortunately, developers can only retrieve lists of users authenticated users have blocked and not just any user. This means you can only see those you blocked, and your friends can't see that list. The methods released only allow developers to retrieve a list of users blocked, or if a specific block has occurred between the authenticating user and another Twitter user.

A couple weeks ago Louis shared some interesting statistics found from screenshots of the Twitter administrative interface, taken by a hacker that found a way to get into their system. Some of those statistics included the numbers Britney Spears and Barack Obama had blocked. While users won't be able to tell this information with the new API, Britney herself could keep track of that information herself through tools such as Tweetie or TweetDeck or Seesmic Desktop.

It will be interesting to see how developers find ways to use this new API, and which apps choose to utilize the new information. It should be noted that not even the Twitter UI has this information currently.

Read more by Jesse Stay at Stay N' Alive.

Twitter Caps Following Limits, Denting Auto-Follow Services

Another day, another Twitter limit that impacts its developers. Following on to Twitter's statement last month about auto-following practices being "disingenuous", the company is back at it again, telling users that "it is unlikely that anyone can actually read tweets from thousands of accounts", and limiting the number of accounts that a single person can follow in a day to 1,000. While that may sound reasoned in practice, it's going to impact the way highly visible accounts can use the service, and again, throw a monkey wrench into entrepreneurs who are looking to fill gaps in Twitter's service.

In the last few weeks, Web and print media have been awash in discussion of some of the largest accounts on Twitter reaching the 1 million follower mark. Assuming Ashton Kutcher and others were to follow Twitter's rule to only follow 1,000 new accounts a day, it would take Ashton 3 years to follow all that follow him, assuming no more new users found his account interesting. It seems Twitter would prefer that these celebrity accounts only follow, say... 93 as Ashton does, rather than the nearly 400,000 Britney Spears follows, which I would guess would be even higher if it weren't for Twitter's API troubles.

I speak to this point not so much as a standard Twitter user, but also as an advisor to SocialToo, which Jesse Stay has worked on to help Twitter users like Guy Kawasaki, myself and many much more visible accounts to stay even on their following and followers, as well as many other features. One of the premium options SocialToo has offered has been a "catch up" option, where users could catch up and follow all those who they were not previously following. Now, SocialToo could only add a maximum of 1,000 a day, making the service good for smaller users, but not for the rapidly-expanding numbers we see on many accounts.

Lest you think I'm just trying to cover for SocialToo here, take a look at how other Twitter developers in the last week by slowness and caps that Twitter is placing on their ability to get data to feed their services. Mr. Tweet has been reporting service disruptions and apologizing to users and Tweet Later reports problems getting data from Twitter. TweetLater even notes from earlier this evening, "At the time of writing there were 1.7 million unprocessed API calls on the processing queue, and the queue is still growing every second."

It's likely Twitter is issuing this newest limit to try and stop spammers and go after the worms that have recently impacted the system. But the ecosystem that has helped the service grow to such high visibility is getting impacted. Hopefully there can soon be a resolution that lets Twitter be secure the right people with the right tools are doing the right things, and that the bad guys are being appropriately stopped in their tracks.

10 Business Models to Monetize Web Applications

By Rob Diana of Regular Geek (Twitter/FriendFeed)

During my morning reading, The Long Tail had a link to a survey of Web app business models. If you take a look at the charts listing the revenue models, you will see there are twenty models listed. However, that is not an exhaustive list of ways to make money. Some of the models, such as Fixed and Variable Subscriptions, have several "implementations" that you can attempt.

Having said this, why is it that monetization is so hard for many Web 2.0 applications? Let's look at what needs to be done to support the various business models.

Subscriptions

1. Fixed subscriptions are a simple concept where people pay monthly fee for a product or service. Typically, you can charge for removing advertisements or some level of premium features. The problems with fixed subscriptions are that you need to create a subscription payment system and you need something to charge for. The first issue can be rectified by integrating with something like PayPal. The second issue is what most sites have difficulty with, what do you charge for? Premium content or features are much harder to find as you want to ensure you can build as large an audience as possible. Premium features need to be really interesting, and generally not available for free elsewhere.

2. Variable subscriptions are much more interesting. These are things like charging for use of an API or data feed. These are difficult as it requires a large amount of tracking application usage, and the pricing plans are more difficult to administer. Again, there are the questions of whether your services are generally available for free or even that useful.

Third Party Support

3. Advertising is the most common form of third party support. However, most Web applications are not launching with advertisements, which I think is a mistake. Google AdSense may not help you make millions, but maybe it offsets the costs a little bit and it opens up opportunities for real advertisements in the future.

4. Sponsor is a glorified word for really nice advertiser. A sponsor typically has a permanent advertisement on the site. These are nice, but it typically requires a decent amount of traffic in order to attract one.

5. Paid content is the black sheep of third party support and generally vilified by bloggers. The amount of negative publicity that you could receive from paid content may not be worth the money, especially if your site is still young. I would definitely recommend against this unless you are an established blogger and can easily defend your position.

Products And Pay-Per-Use

6. Products and Pay-Per-Use are probably the hardest monetization models to use. Do you have a physical product or virtual product that you can sell? Are people even willing to buy your product? Products typically require a significant amount of capital to develop or purchase, so your costs are generally high as well. Pay-per-use models are also difficult to develop. PayPal is an excellent example, where they charge transaction fees for each transaction. Just like the variable subscriptions, tracking of application usage can be difficult and for transaction fees, there is a large amount of financial work involved. Most technical people do not have significant financial background, so there is a large knowledge obstacle to overcome.

Services

7. Branding tends to be a side effect of what you have tried to do with your application. However, there is good money to be made from consulting and speaking engagements. This is an interesting option, but it tends to be more of a personal option as opposed to monetizing your application directly.

8. Create a platform. This is part of the model for the iPhone. You can charge developers for the development kit. This is immensely difficult to do because your platform must be hugely popular. Twitter is becoming a platform, but has been so open with their API that they would have difficulty charging people at this point. With this option, you should start charging immediately when it is released.

9. Affiliate sales are also an interesting option and do not require a huge amount of initial work. The difficulty with affiliate sales is that you still have to create something that is worth buying. I would also think that the amount of revenue possible from affiliate sales is smaller than most people creating Web applications would want. Granted, I do not have experience with this model, but you are sharing revenue with the people who are your affiliates. You could create a larger sales network in this way, but people would have to want to sell your product.

10. White label services do not appear very often for some reason. This is similar to the platform model, but the difference is that your software is not obviously at the forefront of the product. Ning is the most widely known option in the social network space, but there is a significant amount of competition. This model also requires some portion of other models as well. Ning has fixed monthly subscriptions as well as variable usage subscriptions. You could avoid mixing models by charging a larger fee for the initial creation of the white label service, but a larger initial payment will also scare potential buyers away.

Obviously, this list is not complete, but these basic models can be implemented or even integrated into most applications. I have avoided the "holy grail" of internet applications, selling the entire startup, as there is no direct way to implement this. It is also ridiculously difficult to survive without any monetization and be purchased for a decent amount of money. Most potential acquirers would like to see some semblance of revenue and potential revenue before buying something. It does help to be the hot application in the hot industry, i.e. YouTube or Twitter, but there are very few opportunities to do that and there will be tons of competition.

Read more by Rob Diana at RegularGeek.com.

Omniture Announces Developer APIs, iPhone Integration

By Jesse Stay of Stay N' Alive (Twitter/FriendFeed)

I am at the Omniture Annual Summit in Salt Lake City, Utah watching Josh James, CEO and founder of Omniture, deliver the first keynote for the conference. Some fascinating and useful things have been announced, but perhaps the most significant was their announcement of a developer platform around the Omniture analytics and marketing suite. The platform, called the Omniture Developer Connection, aims to give a single point for developers to connect, learn, and showcase the applications they develop.

From their recent press release:

"Omniture Developer Connection further opens up the Omniture platform, giving developers new levels of flexibility to create, and integrate with, applications that leverage Omniture data to optimize online business," said John Mellor, EVP of Strategy and Business Development at Omniture. "With approximately one trillion transactions measured each quarter, our customers are sitting on a tremendous resource of information and we are committed to rapidly expanding the ecosystem of applications available to help them drive value from that resource."

In addition to the platform, Omniture has released a series of sample applications, including a Wordpress plugin for tracking Blog traffic, and even more significant, a SOAP API for the iPhone so iPhone developers can communicate via SOAP within their applications, including interfacing and bringing live analytics and tracking into their iPhone applications. Omniture puts it this way:

"One notable omission in the iPhone SDK is the lack of a Web Services framework like WebServicesCore from the OSX SDK. Given the iPhone’s emphasis on online connectivity, it is at least surprising that there is no native framework stack for SOAP web services. So, what’s a developer to do?"

Now, developers have full access to the vast storage of data given to publishers via Omniture, on mobile devices as just one opportunity. Omniture, with over 5,000 customers, 5 of the top media companies, 6 of the top 10 retailers, 4 of the top 5 banks, 4 of the top 5 travel companies, and boasts 250,000 transactions per second, is the very definition of mainstream analytics. Now you will see sites such as Best Buy, JetBlue, Walmart, and many more begin to make a presence on the iPhone and more as they will now be able to track their presence on these mobile devices.

With the release of this developer platform Omniture has just opened up a goldmine of data around Site Analytics, and every developer has access to this information. Mobile and Social Analytics have just hit mainstream due to this platform, and will continue to strengthen due to companies like Omniture opening up their platforms to this data.

All developer APIs and documentation can be found at https://developer.omniture.com/.

Read more by Jesse Stay at Stay N' Alive.

Twitter Announces OAuth Details, Hints At App Directory

By Jesse Stay of Stay N' Alive (Twitter/FriendFeed)

In an announcement on the Twitter developers mailing list today, Matt Sanford, a developer at Twitter who has been leading the efforts to integrate Twitter API with OAuth, announced details on how the new OAuth would work. In the announcement, he released a preview of documentation for the new OAuth methods, how developers would integrate using a sample Ruby on Rails application, and what developers would need to know to integrate.

Interestingly, the documentation also hints at other plans in Twitter's future as well. For instance, Sanford suggests users will be able to see what applications they have given access to and revoke that access. He also hints at a future catalog of applications and opportunity for developers registered within the API to be a part of that Catalog.

Announcement of such a catalog and authorization process has been speculated on for quite awhile now. It was mentioned as a possibility when I visited Twitter with Robert Scoble about a year ago. So seeing Twitter's plans to stick towards this path and continue towards this goal is welcome news to say the least. Also mentioned in the documentation is the suggestion that the basic auth API Twitter is using today will eventually be phased out.

Twitter plans to release the OAuth API to developers that are participating in the closed beta "by next week", and they have not announced a date it will open to the public yet. However with increased pressure to have better control over the applications that run on Twitter you can bet Twitter is now putting top priority on this particular issue.

Read more by Jesse Stay at Stay N' Alive.

The Danger of Changing The Baseline

By Rob Diana of Regular Geek (Twitter/FriendFeed)


There has been a lot of discussion regarding the recent announcement about Twitter's API limiting. The SocialToo blog has a very good overview of the situation. Granted I am not a fan of the limitations, but that is not the reason for this post. Changing the limits is the real problem.

The baseline for any application is when it is released. Any updates or new features added to an application reset the baseline to a higher level. The user and developer community are your best friends during this cycle. It can be argued that Twitter would not be nearly as popular if there was no API or third party applications for it. However, if you decide to change something in an application, and the net effect is a decrease in functionality, it feels like you have taken something away. For example, Jesse Stay, the founder of SocialToo, realizes that these limits now change the way applications can use the API:

Many of the services you have come to love for Twitter, including those of our competitors, and many other Twitter-based services are in jeopardy. This is scary news as an entrepreneur and Twitter developer. Twitter has basically just limited how big any Twitter-based business can grow.

Changing The Baseline

The real problem is that these limits appeared long after the API was released. Twitter has consistently removed functionality during peak traffic periods as well. Things like deleting direct messages or viewing older messages often gets disabled. This does not provide a good user experience.

Twitter is not the only one doing this either. Google has also recently done this for their Google Apps product.

When Google Apps first launched up to 200 user accounts could be created for each business under the free version. But that limit was quietly reduced to just 100 user accounts. And then when the reseller program was announced earlier this month, the limit was cut in half again, to just 50 accounts.

Obviously, this is bad for the users and good for Google. However, lowering this limit is devaluing the service that Google is supplying. Sometimes a company will have a promotion when first launched where the account limit is temporarily raised, but it is also known that it is temporary. In Google's case, the Apps offering has been around as long as Twitter has. So, it is not the case of a quick change, it has been changing over the course of years.

The Danger

The real danger appears after the changes take effect. If the changes or limits are drastic enough, the popularity of the application could decrease rapidly. In some instances, your users could rebel or even start building an alternative product. The idea is that the application must always move forward. In some cases, moving forward may mean a small step back, like a little used feature that is poorly implemented gets removed until a rebuild of the feature is ready.

For startups, losing popularity or even a small decrease in users or hype could mean the end of the line. In the case of Google Apps, lowering the number of free users may actually drive small companies away from them. Many small companies may be using Google Apps because it is free, and they can grow with the service. Now, with a limit of 50 free users, companies need to make decisions on Google Apps or other online application suites shortly after hiring employees.

In reality, you want to push change for the better. You want to keep your customers as happy as possible. Enforcing new limits long after releasing features can just alienate your users. Some level of trust will be lost because it feels like they were tricked by your earlier kindness.

Read more by Rob Diana at RegularGeek.com.

Every Time I Try To Embrace Twitter, They Push Us Away

As an advisor to SocialToo, Jesse Stay, the developer of the service, and I trade a lot of e-mail... we also talk on the phone and exchange direct messages via Twitter on how to improve his service. Some of the ideas I've had already have made a small impact on the service, while other pieces will come much later. But last night, Jesse sounded an alarm that the service itself could be in jeopardy, thanks to proposed changes from Twitter's API team that would set limits which essentially cripple SocialToo's capability. And as much as I want to champion the immediacy of Twitter, the real-time aspects of the service, the community, and its outstanding search engine, this isn't the first time I've been left feeling cold about how the team has impacted its users or development community.

Previous Discussion:

• Twitter Chokes Unauthenticated API Requests By IP, Sites Gasp for Air

If you have your head buried in RSS feeds and the tech Web, you've likely already seen the major issue - either from the SocialToo blog itself, or on sites like ReadWriteWeb, CNET and others, including Chris Charabaruk and TweetLiberty. Essentially, the limits are a hard number that aggressive services could easily surpass, assuming solid customer growth. And as developers like Jesse and others start to use the Twitter community and trends as their data set, they keep running into roadblocks. At first, Twitter was failing due to simple aspects of scale, but now, it seems as they make headlines for record traffic and involvement in world news, they are making headlines again for the wrong reasons - things that could be better massaged with improved tact and transparency.

Twitter's move, at its heart, looks to be one to protect themselves. As API Lead Alex Payne wrote yesterday, "This is essentially a preventative measure to ensure that no one API client, even a whitelisted account or IP, can consume an inordinate amount of our resoures." (sic)

But there didn't seem to be any options for services, even whitelisted ones like SocialToo, to get a work-around. There was not an option to pay to get increased access capabilities, or even tips on how to optimize code so that it takes less effort to achieve the same result. Twitter wants revenue, and the development team wants Twitter to succeed. So does everybody else, essentially. But my understanding is that Twitter has made it very difficult for some services to do the things users are asking for - including automatic following and unfollowing, because they aren't really that interested in providing such functionality. That doesn't sound promising for developers of SocialToo, Qwitter, FriendOrFollow and others. What other providers, such as FriendFeed and Facebook, offer in full, Twitter parcels out in bits and pieces, and seemingly expect the community to be grateful for it.

So now, Jesse and others are faced with a tough situation - is it even possible to optimize their code? Should they ditch Twitter as a development platform altogether because the company treats them like leeches instead of celebrating their efforts? Jesse asked in an e-mail, "Why develop for the Twitter platform any more if we know we can only grow to your limit?", adding one option for him may just be to exclude the most popular users outright to reduce stress on the system.

I'm not sensing a developer mutiny overnight. Twitter at this point has practically become a mainstay of most digerati's online experiences. Even if there are products that are better, Twitter has the momentum. Twitter has the growth and the buzz. But they are acting like they know it. Alex followed on to today's discussions, via Twitter of course, saying: "If people just asked us rather than making assumptions, there would be no story :)" But I'll be direct here - I saw Jesse's questions. He asks lots of questions and gets some answers. There is still a story. The story is that people who have made some very innovative and interesting products on a service with no revenue are very concerned about whether they can trust Twitter and if Twitter wants them to succeed - period.

Twitter Withdraws Plans for Supporting OpenMicroblogging

By Jesse Stay of Stay N' Alive (Twitter/FriendFeed)

In a very quiet announcement in a bug request on Google today, Alex Payne, API Lead at Twitter, announced the popular microupdate service would switch the status of implementing OpenMicroblogger support from "Accepted", to "Won't Fix".  In the words of Payne, "We've considered this request, and we feel that OpenMicroBlogging doesn't map cleanly onto the services and methods that the Twitter API provides, particularly as we expand our set of methods in the next release."

We previously covered Twitter's initial plans to offer OpenMicroblogging support here before.  With Twitter's attendance at Steve Gillmor's Bear Hug Camp it seemed it may only have been a matter of time for Twitter to accept OpenMicroblogging into their network. Such acceptance would mean other developers could implement their own microblog implementations that could communicate with Twitter in an easy format, and allow users of those services to continue to follow the friends they had already established on the Twitter service. Twitter, being the near-monopoly in microblogging that it is, seems to have other plans.

While Twitter is seeming to remain open to some other option that would resolve the issues that OpenMicroblogging seems to fix, they have continued to ignore the OpenMicroblogging community in being open to letting Twitter lead the discussion on OpenMicroblogging.  Back in July, Evan Prodromou, author of the OpenMicroblogging spec, put the offer out, asking, "If you have some ideas of what sort of adoption metrics we have to hit, let me know."  The question went unanswered however as the issue quickly became one of the most popular issues in the queue for Twitter to implement.  It appears in this particular instance, Twitter simply doesn't want to listen.

Payne tried to calm the concerns by saying, "Should the specification evolve to better reflect what we're trying to achieve, we'll reconsider supporting it." Prodromou responded to Payne's offer by stating, "Alex, we're working on a next release of the OMB spec. If you can send me your notes on what you'd like to see in OMB, I'll be happy to include them. Since the point of the protocol is to create a federated network of Twitter-like sites, it's clear that we'd love to hear your suggestions."  But since his offer this morning, there still has been no response from Payne or Twitter.

For a site that wants to be more attentive to its developers and users, Twitter seems to be dropping the ball in this case, repeatedly ignoring requests by the community to help in the efforts of developing the OpenMicroblogging spec.  Since they have a near-monopoly, can you blame them though?  Or perhaps it's because their time is being spent elsewhere.

Read more by Jesse Stay at Stay N' Alive.

AideRSS Rebrands as PostRank, Launches New Features, API

Since its launch, AideRSS has aimed to leverage social tools to help determine a publisher's most popular content, through analysis of individual posts and their related activity, including Diggs, bookmarks on Delicious, links in Google, and total comments. RSS advocates suffering from information overload have even turned to AideRSS to act as an intelligent filter, providing them the best stream, rather than the default firehose. With today's new announcements, along with a rebranding as PostRank that saw the launch of a new Web site and look, the service has added tags, keyword filtering, and other tools that will get users to the data they are seeking quickly.

(See from December 2007: AideRSS Judges Feed Posts as Good, Great, Best)


PostRank Shows Posts With Audience Engagement Have Higher Score
The first major enhancement to the new PostRank is keyword filtering. As Ilya Grigorik wrote, users have asked for the ability to customize and filter any RSS feed with specific keywords. For example, you could get all posts from The Unofficial Apple Weblog that mention iPhone, or posts from Matt Cutts that mention SEO.


I Tagged TUAW as iPhone and Filtered for Only iPhone News
You can also now tag feeds you import into PostRank, helping to build out what the team calls "custom content channels" based on those tags and keywords. All feeds tagged with BlackBerry would be in the BlackBerry channel, etc.

Most interesting to developers may be the introduction of full API access. According to Grigorik, all operations possible on the new postrank.com site are accessible by API, making it easy to utilize the filtering capabilities seen in their service on other applications.

As a blogger, the new PostRank offers better ways to see if specific posts do better with readers and the social services based on keywords. As a consumer, you can now read fewer feed items and still be sure you don't miss those that are most interesting to you. You can find PostRank at http://www.postrank.com. Of course, going to the old AideRSS.com will push you there as well...

Shyftr Reloads With New API, Activity Stream, Widgets and UI

The crowded world of online RSS feed readers is one that's been dominated by names like Google Reader, Bloglines and Netvibes. But underneath that layer you have a few interesting innovative players, including FeedEachOther, and Shyftr. Shyftr came to prominence this spring, drawing attention for a shared comment stream on linked items, and has been quiet for the last few months as they worked on enhancing their platform. Today, they woke up in a big way, revamping the service, while adding an API, activity streams and widgets for bloggers.

Shyftr's main draws continue to be the same. You can add friends on the service, and see which RSS feeds they are following, or have "Shyfted". You can see who else is reading feeds that you have added, which you can do manually, or by OPML. And despite your reading your feeds in your own space, you can make comments and see them shared with the broader Shyftr community, much like other aggregation tools, including FriendFeed and Strands do. But unlike those services, Shyftr deduplicates, providing a single instance for each unique URL.

In addition to the social aspects of Shyftr, the service offers what they call a Pocket blog, the equivalent of a Google shared links blog, letting you see what friends have found interesting, as they "pocket" new items they discover.


Today's announcements set the foundation for Shyftr and for outside developers to further enhance the service. The API can tap into just about every aspect of the service, except for actually reading feeds, Shyftr reported in a blog post this morning. Among the first introductions is a new activity stream, which shows your activity, or that of your friends, as they "Shyft" new feeds, "Pocket" new items, or make comments.


Like FriendFeed and other social tools, you can filter whether you want to see "Everyone's activity", "Friends activity" or just your own activity. You can also view a single individual's stream if you like.

The last addition are embeddable widgets. Every Web service under the sun has a corresponding widget these days, and Shyftr is no different. You can make widgets for your activity stream, for a specific feed, or to show all activity on Shyftr itself.

As Shyftr founder Dave Stanley wrote in this morning's post, the development of an API was critical to expanding the site's social features, and bringing it to be much more than a passive RSS reader. While the service remains small in the shadows of giants, it has set the groundwork for growth. You can see my profile here: http://www.shyftr.com/profile/louisgray.

With Facebook Connect, Google Has Unique Integration Opportunity

By Jesse Stay of Stay N' Alive (Identi.ca/FriendFeed)


In working with Google FriendConnect recently, I realized that Google has a unique opportunity that perhaps they did not have previously. In only the last few months, Facebook has opened up the opportunity for any 3rd party site to integrate with Facebook, all via a special login button and form Facebook provides. Such technology is enabled through a product Facebook calls Facebook Connect. In playing with Google's product, it enables one to authenticate through other services and allow porting of friend data and more through its FriendConnect interface. I believe Google now may just have the unique opportunity to finally integrate Facebook as they wanted to before.

Several months back, Google attempted to launch FriendConnect with Facebook as one of the launch partners. Facebook quickly pulled Google's app from the Facebook App Store because they claimed it breached the Facebook Terms of Service. Google denied they were doing such, but Facebook insisted, keeping Google from being able to integrate with Facebook. It's unclear what exactly Facebook was claiming Google had done wrong, but it appeared to be some sort of backdoor technique to obtain user information.

Enter Facebook Connect

Several months later, Facebook launched their somewhat competing product, Facebook Connect. Facebook Connect does not integrate with other sites, but does integrate with OpenID similar to the way Google FriendConnect does, and enables you to through simple javascript, allow others to login and integrate their Facebook friends right on their own website.

Because FriendConnect is specific to Facebook, Google could now have just the opportunity to integrate Facebook the way they wanted to. Now, Google simply, and legally, should be able to implement a simple Facebook Connect login button into their user settings interface, let the user log into Facebook, and automatically Google would now have full access to the Facebook API from a third party site as they were trying to do before. Google can now enter in through the front door.

Not only that, but Facebook now allows site owners to identify existing accounts with existing Facebook accounts that have the same e-mail address. If Google were to collect the user's Facebook e-mail, or use their existing assuming it's the same as their Gmail address, they could then identify existing Friends on Google that also have Facebook accounts, allow you to link into them, invite them to begin using your FriendConnect-enabled site, and more.

Why Google has not yet implemented this is beyond me. Perhaps they already have and we are just waiting for Facebook to fully lift the Sandbox they have in place for developers right now. Regardless, I am willing to bet that Facebook integration into Google FriendConnect is coming very soon because of these features. Expect it to come in the form of Facebook Connect.

Read more by Jesse Stay at Stay N' Alive.

BackType Launches Widgets and Alerts to Extend Comments Tracker

At the end of August, BackType launched an interesting tool to track individuals' comments across the Web - no matter the commenting platform and no matter the blog, and letting you subscribe to other BackType users to see their comments, wherever they were. In the last few weeks, BackType launched alerts, letting you follow search terms, and today, they launched widgets which enable you to show the places you are commenting around the Web from a single place, most likely your own blog.

As the world of blogging is changing, tweets on Twitter and comments on blog posts are becoming nearly as important as dedicated posts themselves, and BackType has served as a way to find out what other blogs people you follow read and comment on, or to show who is more likely to launch a new story, yet not participate in the following discussion. The service also serves to show if bloggers tend to only participate in the comments on their own site, and not around the Web - something I myself have been guilty of in some weeks.


BackType's New Alerts and Widgets

Alerts

After logging in to BackType, go to http://www.backtype.com/home/alerts to see how you can follow individual words or search terms, and have them deliver e-mail alerts each day, each week, or in real time. You can even choose to follow terms but keep them on your dashboard, without spawning an e-mail.

Widgets

Just about every service has widgets these days, and the new challenge as a blogger can be which ones to install at the expense of others. If you've got the real estate, BackType's new widget shows you comments you've made across the Web, with a favicon of the blog, and its recency - showing how fresh the comment is. Interestingly, clicking on the widget takes you to the actual comment within BackType, and from there, you can click through to the blog post in question.

In case that wasn't enough, Christopher Golda of BackType says more features are planned. BackType has been expanding their coverage through scouring more and more blogs, has been improving the service's search engine, and they're developing an API. Hot on the heels of Disqus' launch of their own public API. it should be interesting to see how innovation in the comments space is developing.

You can find me on BackType here: http://www.backtype.com/louisgray

Disqus' API Launch Extends Commenting Possibilities

At Blog World Expo last week, I said that those services which "played well with others" would do better in a collaborative, cooperative Web 2.0 landscape over those that instead held tight to their walled gardens (See tweet from @drewolanoff.) It is through the launch of an API and extensive developer activity that services like Facebook, FriendFeed and Twitter have grown, often at the expense of those that didn't. Tonight, the popular Web commenting service Disqus joined the fray, launching a full public API.

The API (outlined here) lets services and tools write custom comment import and export tools, or to develop unique plug-ins for their platform. (see the announcement and coverage by The Inquisitr.)

Disqus comments are already among the most portable, enabling syndication through RSS, and into lifestreaming applications of all sorts. But what I found most interesting was the note on custom plugins for customer platforms. What's to stop developers from making a custom Disqus-enabled engine that is secure, and for the enterprise, essentially the comments equivalent of Yammer (versus Twitter)? What I see happening is that many of the social tools we may be using for community and entertainment in our world are now on the verge of making it to the enterprise. With an open development platform, and possibly, the idea to customize the comments engine for services that have enterprise capabilities, this could be one way to break on through to the other side, so to speak.

This week's big commenting news was Automattic buying up Intense Debate, something many thought would make Disqus' world a whole lot harder. Tonight's announcement shows they aren't sitting still and playing the part of victim. I'm eager to see the new services and tools that get developed as a result of being Disqus-powered.

Throttled By the Twitter API? Try Something New.

Guest Post By Rob Diana of Regular Geek (Twitter/FriendFeed)

Well, the microblogging API space sure got interesting in a hurry.

First, on Thursday, Louis Gray reported that Twitter was throttling unauthenticated API requests. This obviously would effect several applications in a very bad way. Later in the day, Dave Winer let everyone know that Identi.ca has implemented the Twitter API. And on Friday, in a surprising move, TechCrunch announced that Twitter is sending the XMPP firehose to new middle man Gnip.

So, what does this mean to you? Well, that is a good question. First, we know what the Twitter API looks like. Identi.ca replicating the API is good for interoperability as well. Yes, they copied the main Twitter API, but have yet to include the searching capabilities that Summize supplies. However, they do have RSS feeds for any search query which does suffice for basic searching. The other big players in the microblogging space, Jaiku and Pownce, also have APIs. But, what do they have to offer?

Jaiku's API contains the usual suspects, the public feed, a user's feed and a user's profile. It also allows for "presence" updates which is helpful for allowing applications like Ping.fm to post to multiple services. It also provides a method to get a user's current "presence", their last item in the "presence" stream and as well as a specific item in the "presence" stream.

Pownce's API is similar as well. There is a public "note" list, a user's note list (which can be filtered for replies, private messages and other coolness) and a user's profile. You can also retrieve a specific note, with replies included optionally, and the list of recipients for the note. For social graph fans, you can get the friends (mutual relationship) of a user, fans of the user and who the user is a fan of. For posting notes, there is the normal post method as well as separate post link, event, file and reply methods.

Interestingly, there is a method to determine the list of users a post can go to. There are some other minor goodies like feeds for the public list and a user as well as simple web post integration. Obviously, this is an API designed with developers in mind. They thought of several different ways to use the application and provided APIs accordingly. The only problem that I could see is that there is no search supported. Hopefully a third party service like Gnip will fill that void, like Summize did for Twitter.

Now that looks like a good foundation, but there are some fundamental problems. It is not obvious that Pownce and Jaiku support something like an XMPP feed, so, there may not be the ability to have the full public stream at all times. This type of thing is critical for interoperability. There is also inconsistent support for threaded messages and other post types (like the Pownce event and file posts). Why haven't we seen a real multi-microblog client? Ping.fm is doing multi-writes, but does not support multi-reads. In the instant messaging world, where the XMPP standard comes from, we do have multi-chat clients and few actually support XMPP! We are starting to see some standardization in this space as well with Identi.ca copying the Twitter API as well. If we consider the Twitter API a defacto standard and we have the XMPP standard for real time transfer, there should be little stopping developers from creating the ultimate micro-blogging client.

Now, the question is, are you willing to wait or do you want to crown someone king?