Home - Stay N Alive

With New API, Twitter Attempts to Kill Autofollow Apps

Posted on June 21, 2013 by jessestay

Just this last week Twitter retired their long-lived 1.0 API for developers. This API was the first “versioned” release, a breath of fresh air in many ways for developers that were tired of API updates breaking their code. On June 11th, Twitter forced all devs to upgrade to their 1.1 API however, breaking many developers’ apps in the process (mine included). What hasn’t been said yet is that autofollow apps (apps that automatically follow people that follow you) seem to be out of luck with this new update, and no word yet from Twitter.

The problem with 1.1 lies in a new set of rate limits. Developers are allowed to make a certain number of calls per API method, meaning each method can only be called a certain number of times within a given time frame. This, I’m sure, is freeing up all kinds of resources and money on Twitter’s servers.

However, for apps relying on regular updates to a person’s social graph (their followers or friends), this reeks havoc on those apps. The rate limit currently for just getting the ids of a single user is 15 API calls per 15 minutes. Here’s the problem: you have to make a single API call for every 5,000 friends or followers that user has. Twitter’s API requires apps to “page” through a user’s friends and followers 5,000 at a time. This is great if a user has under 75,000 friends, but once you make that API call over 15 times to get a user’s friends, you’re stuck waiting another 15 minutes to get the rest of their friends. Now imagine if that user or brand has over 100,000 friends or followers! Or what about over 1 million! It’s impossible for an app that is trying to evaluate a person’s social graph to always know a person’s followers or friends in that rate limit, rendering apps like auto-follow, or even simple social graph analytics, impossible.

When you think about it, this might make sense per Twitter’s current business model. For users and brands with over 75,000 followers, I’m willing to bet Twitter would love to have them as customers. Many of those can afford an account rep that can take care of custom requests. In addition, Twitter now has their own analytics to track a user’s social graph growth over time. So maybe Twitter is discouraging these types of apps. I’m fine with that as long as they are open about it.

If this is the direction Twitter is going, I have to say I’m used to it. To be honest I haven’t been putting much effort into my own service that has focused on the social graph of Twitter users, SocialToo, because of it. In many ways it has just become another “hole” filler in Twitter’s API history. As a developer though, this is certainly discouraging, and even further driving me away from Twitter’s developer platform.

I hope I’m wrong. I’ve asked in the Twitter developer forums with no answer yet. Is there another solution I’m missing? Let me know in the comments and I’ll do another post showing how to do it.

Paypal Launches "Embedded Payments" Platform for Easy Integration Onto Any Website

Posted on October 26, 2010 by jessestay

Today at the Paypal X Innovate 2010 Conference Paypal, in a demo with the social shopping cart payments provider, Payvment, announced in a live demo their new “Embedded Payments” platform. The platform, at least according to the demo, allows developers, by just copying and pasting, to place a simple “Pay with Paypal” button into any app or website.

Paypal also demoed an integration with GigaOm, allowing premium content to the readers of the site, enabling GigaOm to charge for premium content. The demo implied the integration was very simple and easy to implement.

We are in a new era of APIs. We’ve gone beyond the era of backend, REST-based APIs that you have to write communications code to pull the data and then formulate the front-end to look the way you want. We’ve now moved into an era where implementing someone else’s platform is as simple as “copy” and “paste”, and nothing more.

Facebook has done something similar with their “Social Plugins” platform, launched earlier this year at their F8 conference, and that was preceded with Twitter‘s “@Anywhere” platform, each one allowing simple copy and paste into the view of any website or application. I’ve talked about the Building Block Web – Paypal has just entered the View component of the Building Block web. This is a very useful move by Paypal and I can’t wait to start playing with it!

Recurly Recurls Pricing – New Entrepreneurs Not Happy

Posted on March 25, 2010 by jessestay

Up until now I’ve been preparing a raving review about how much I love the recurring payment service, Recurly. Previously, at simply a fraction of the price of each payment on the service, it was very simple for any entrepreneur to get set up with the service and have an out-of-the-box solution for recurring payments on any website. Just today Recurly sent out a note to its beta customers stating they were changing that model, and rather than charging per transaction on either a percentage of revenue or the total number of subscribers (the lesser of the two), they would be switching to a flat-rate pricing model. The pricing would increase based on the services you used rather than the number of transactions. As a new entrepreneur, I’m horribly disappointed by this new plan.

Just today, Recurly’s CEO sent out a lengthy e-mail explaining the terms. In the e-mail, Isaac Hall, CEO of Recurly, blamed the new pricing on their talks with entrepreneurs, claiming what entrepreneurs would “likely be paying”, and implying that for most of those they talked to this new pricing structure was more beneficial. Unfortunately, I was not one of those he talked to, and evidently, nor was Damon Cortesi, another entrepreneur/developer and founder of UntitledStartup (where I learned about Recurly) who responded when I shared my disappointment on Twitter, “I agree re: the monthly fees. That’s a huge hit.”

“Our pricing is simple–we don’t get paid unless you get paid.” – the old slogan

The old pricing was simple – so simple they bragged, “Our pricing is simple–we don’t get paid until you get paid”. It offered the option of a tiered pricing level where each tier represented a number of users with accounts on your system. If you had more accounts, you paid more. There was also a percentage model, where for each purchase a percentage of the pricing would be charged to the transaction – they claimed they would choose the best pricing model based on your number of transactions. Unfortunately they must not have been getting paid enough. The new plan is just 3 tiers – $49, $99, and $199/month. The lower tier being a basic signup solution with no way to determine when users’ cards were declined and no way to whitelabel or do one-time transactions. The middle layer adds API support and white-label support. The final layer adds push notifications (for when cards are declined, subscriptions are canceled, etc), and one-time transaction support.

The old pricing model

For a budding entrepreneur trying to bootstrap his company with no guarantees as to whether that company will make any money at all, even $49/month is an expensive choice. For someone like me who can’t guarantee the user will actually come back to the site after signing up through Recurly, or can’t guarantee the user’s card will be successful the second or third month in, I need the push notification support. Currently even Paypal offers this on a per-transaction basis, and they provide one-time transaction support (which we’re using on SocialToo). White label is also critical for maximum fulfillment (something that was next on my list for SocialToo).

However, at $199/month, I just can’t guarantee my sales will always be enough to cover that, pay for hosting (already near $1k/mo), cover maintenance, design, and other costs of supporting the site. It’s simply too expensive for a site still in the early stages trying to build enough revenue to make something significant. Considering most businesses are bootstrapped in this manner and not paid for through VC money, this may be something Recurly wants to reconsider.

So, considering, I am now forced to look back at my options and I will probably be considering implementing my own solution now through a service like Paypal or perhaps something native through Authorize.net or similar just like I’m doing on the one-time payments. I really hope Recurly reconsiders on this. Their previous plan made it so easy to set up a recurring payment plan it was the obvious choice. I am stuck looking for more.

You can read the e-mail from the CEO of Recurly here.

What Buzz Needs to Make a "Sting" in Facebook

Posted on February 14, 2010 by jessestay

There’s a new Buzzword in town that’s “Buzz” lately and as I mentioned earlier, some are already calling things “dead” because of it. Most of this is due to the size of Google, the masses it can reach, and the overall usefulness of the service. Personally, I think all the “dead” articles are all a ruse to build the numbers of those praising the service and feeling a need to abandon others, as well as gain favor with the Google team as they see strong potential in the service. While there’s no argument there’s potential in the service (and I’m even spending more time over there and strongly hope for its success), it is far from a “Facebook killer”. While I mentioned why before, I feel qualified, and I’d like to spend some time sharing some things it needs to get on level grounds to Facebook.

Buzz Needs a Central Place for all Social Activity

I’ve said this before – Google needs a central place for everything “Social”. Facebook has grown so well because it has this organization. I’m still unclear if Google is trying to make Buzz this place, or if Orkut, or another product should be that. Contacts are not that place – Contacts should be the source of social graph data, but are not social connections. Social connections can come from much more than just contact data – people search, other peoples’ buzzes, as well as other Social Networks can all be sources for Social Contacts between Buzz (see the need for Facebook import later).

Buzz Needs a Stronger API

One of the reasons Buzz has such strong potential is because of its foundation on open architectures. There is so much more that can be done however – I’m sure they’re working on some of these, but I’d like to share my thoughts, in hope that if they haven’t been thought of, they can be added. For instance, currently there is no way for any 3rd party app to gain access to the cool comments architecture Buzz posts get in Gmail. What if I could get FriendFeed, or even SocialToo e-mails in the same format? Buzz or Gmail could open an interface to this, perhaps built on top of SMTP (an SMTP header would denote it’s a formatted e-mail), Salmon, and OpenSocial standards, to give developers access to this UI. The great thing about it – if Buzz sends new Buzz updates in an SMTP-supported format, other e-mail clients could adapt these standards as well. It would no longer be limited to just Gmail to see these formats.

I think it goes without saying that we need better ways to read, analyze, and discover the data, as well as social graph connections on Buzz. I’d like to be able to track who’s posting about what, how many likes or how many comments there are for specific posts mentioning specific keywords or links. I’d like to be able to track who has followed an individual and who has stopped following an individual on Buzz. I’d like to be able to embed Buzzes on 3rd party sites. I’d like an FBML-like interface to integrate and customize content right in the Buzz environment. I’d like RSS for every search I do, along with the ability to share searches and get notifications on new items from those searches (I believe Steve Gillmor calls this “Track”).

Buzz Needs Groups and Events, Deep Integration Into Those Events and Groups

To say just a social stream service is comparable to Facebook would be like saying Notepad is comparable to Windows 7. It’s just not a fair comparison. One is a feature of the other. If Buzz really wants to compete (and I’m not saying they do), they need deep integration into Groups, Events, business Pages, and more. They need the ability for groups of people to all collaborate around a single event, Buzz around it, share it with their friends via Buzz, RSVP via Buzz and Gmail, etc. Google Calendar just doesn’t do this yet.

Groups are another key component. E-mail is too private. They need to enable “Groups” in Buzz that do more than just Buzz. They need to enable sharing of photos, events related to that Group, and encourage communication amongst Group members. They need to put that into a people search enabling you to find old High School friends and acquaintances through them. Google already has some of the basics for this, but I argue they aren’t yet integrated across Google services yet, and are a bit more private an environment than what Facebook encourages. The challenge Google will have is maintaining the “public feel” that Facebook groups and events provide, while maintaining the “silo’d feel” Facebook provides at the same time giving people a sense of security. This will be no easy challenge, and may take a silo’d environment like Orkut to do completely successful.

Buzz Needs Better Privacy Controls

At the heart of most Buzz controversy currently lies their relaxed privacy controls. Originally they automatically followed people for you, giving others potential access to your private list of contacts. Your Google contacts were also all visible on your Google profile just by enabling Buzz. Google has since enabled you to disable this, and has turned the “auto-follow” into more of an “auto-suggest”, but there is still so much more that I can get from Facebook that Google is lacking in regards to Privacy.

For instance, on Facebook, I get to decide how much of my own profile is visible to certain friends. I get to decide if it’s visible to friends of friends. I can even go to the extent of selecting specific lists I want to be visible to, and certain other lists of friends (or individual friends) I don’t want it to be visible to. I can specify specific components of my profile I want visible to those lists. I can set profile-wide settings that remain protected by the privacy settings I set, as well as specific targeted profile elements that remain protected by these privacy settings. Facebook gives me complete control over what my friends see and don’t see. With Google Buzz, not only is it all out in the open, but you’re revealing much more than your social contacts – you’re revealing e-mail addresses and Google account information. It’s wrong the way Google approached this from the beginning, and I argue, even a little bit evil, whether intended or not.

Buzz Needs Lists

Which brings me to my next point – lists. Lists have much further ramifications than just privacy settings. On Facebook, I can click on the “Friends” link on the left-navigation and immediately have access to lists I have organized of my friends. I can view the posts of just my close family members, or just the posts of the news makers and use it like a news reader. Or I can look at just the latest comments of all my friends, or even a summarized view of the top posts for the day. Buzz really needs this to be even remotely useful. On FriendFeed, I have a list of “Favorites”, which I use most of the time to get the most relevant content from those I actually know, and then I can skim the rest of those I follow occasionally.

On every Social Network I belong, it should not be about giving, but how you receive content. Each and every Social Network has the responsibility to empower its users to receive content in the way they want to. Facebook has mastered this (although I argue FriendFeed has done, to an extent, even more than Facebook in this area). No one should feel the need to unfollow me because I post too much, or post one or two things they don’t like. They should be able to read the content in the manner they like, and filter out what they don’t like, without the ugly unfollow. Lists are just one component of this.

Buzz Needs Better Filters

The other part of being able to receive content the way you like is via filters. Each and every application that interfaces with Facebook has to identify itself. This enables users to filter based on application if they choose to. If I don’t want to receive Farmville posts, I just hide everything from Farmville, and I’ll never see another field plowed or beet grown again. People argue they’re worried integration with Facebook will enable the Farmvilles to gain access, but the thing is, without filters, the Farmvilles will use Buzz regardless, but without Filters you will have no way to stop them. Facebook has completely mastered this, and I can’t do this on any other service.

In addition to application hiding, I should be able to filter by feed type. If I don’t want to see someone’s Twitter feed, I should be able to hide just their Twitter feed. If I want to block all Twitter posts from showing, I should be able to do that. If I want to hide a user but not unfollow them, I should be able to do that. I shouldn’t have to worry about making anyone feel bad by unfollowing or blocking them. I should be able to just control my feed in the way I want, just like I do on Facebook (and to an extent, FriendFeed).

Buzz Needs the Ability to Import my Facebook Contacts

Lastly, in order to compete with Facebook, Buzz needs my Facebook friends. They’re not going to get those through my Gmail contacts. Most of my Facebook friends are not in my Gmail Contacts. The only way they’re going to gain access to my Facebook friends is via the Facebook API. It’s time for Google to suck it up, work with Facebook, and find ways of integrating my friend list from Facebook into the Google environment. We’ve waited too long for this with Google Friend Connect, and surely there’s a win-win option for both companies to allow this and work together. Win-win for them is win-win for the user.

Let’s look at Aardvark (recently purchased by Google), for instance. If you log into Aardvark with your Facebook login, it will immediately detect who in your Facebook contacts are also on Aardvark, and immediately add them as friends on Aardvark. The site, Digg.com also does this well – all my Facebook friends are automatically added as Digg friends as they log into Digg through Facebook. There should be no problem with Buzz following Facebook’s developer terms of service and integrating this into their own environment. Facebook provides hooks into its APIs for doing this exact thing.

Assuming it agrees with the Facebook developer terms of service, Google could even submit each user’s contacts to Facebook and immediately prompt each user in your contacts list to connect on Facebook. This would be win-win for both companies, as it would encourage the users of both services to build contacts in each and grow each service. Considering Youtube and Aardvark have both integrated the Facebook API (Youtube could do much better), I don’t anticipate any issues with them doing this. I will interpret any lack of Facebook integration as a failure on Google’s part, and Google itself playing politics, not Facebook. So long as you play by their rules, I’ve never heard of Facebook deny a developer.

I really hope the Buzz team reads this. I have a lot of experience in the Facebook environment. I know intimately how Facebook works as an author of 2 books on the subject and writer of a plethora of documentation about Facebook on various sites around the web, as well as a developer of numerous apps on the Facebook API and consultant to many others. Frankly, as a user and developer, I want to see both companies succeed. The more Buzz succeeds, the more Facebook will compete and provide a better service. The more Facebook competes, the more Buzz will compete and provide a better service. Users win in both scenarios.

If Buzz is really trying to compete with Facebook, these are the things they need to implement to get my attention.

Yahoo Launches SQL Interface to Twitter

Posted on February 9, 2010 by jessestay

Every time I switch to jQuery, Yahoo’s YUI libraries seem to keep luring me back. Just yesterday, Yahoo added one more tool to its arsenal of YQL libraries that actually makes the Twitter API intuitive, giving me another reason yet to switch back to yui, or at least consider using Yahoo a little more as I develop tools for the Social Web. The new YQL set of tables for Twitter enables any developer to use simple SQL-like queries to retrieve and post Twitter data.

For simple user queries, getting a user’s twitter profile data is as simple as something like “SELECT * FROM twitter.status WHERE id=’8036408424′;“. To insert data, you simply need to provide the oauth consumer key and secret, along with the user’s oauth tokens and you can do things like post new status updates for the user, all in Javascript! A subsequent call to post a user’s status would look like:

“INSERT INTO twitter.status (status, oauth_consumer_key, oauth_consumer_secret, oauth_token, oauth_token_secret)
VALUES (‘tweeting from yql!’, ‘@your_consumer_key’, ‘@your_consumer_secret’, ‘@your_access_token’, ‘@your_access_secret’);“

The cool thing about Yahoo’s YQL Twitter interface is I can also choose to only pull specific information out for the user. I’m not quite sure the benefit this gives you considering Yahoo is probably still retrieving the entire subset of data from Twitter (you can’t pull specific pieces of data out of specific objects in the Twitter API), but at least it’s possible, something I’ve been craving from the Twitter API for quite awhile. It is unclear if Yahoo is caching this data, and if so, it could provide some significant performance benefits, with Yahoo doing most of the work on their own backend.

Yahoo’s YQL puts them one level above Facebook’s own FQL query language for accessing Facebook data by enabling developers to not only access data like this for Twitter, but also other environments like Facebook as well. Yahoo has an entire database of “community tables”, where, if specific APIs aren’t provided, the community can create their own tables to that interface and give developers immediate access to those APIs via a simple, standardized SQL interface to those platforms.

This type of API is exactly what I was looking for from the likes of Google’s Friend Connect APIs (and Google has still failed to provide) – a standardized platform where one single API gives me access to all the different APIs out there. Now with standardized SQL I can access almost any API, and if that API doesn’t exist yet I can create my own interfaces into each API that, once created will also have access via that SQL interface.

Yahoo now has my attention with this launch. The API has a web interface, where a call as simple HTTP GET to http://query.yahooapis.com/v1/public/yql?[query_params] returns an entire structure of XML data my application can access. They provide a YUI Javascript interface into the table structure so you don’t need a backend if you don’t want one, and I get all this for all the APIs I interface with.

I will now be looking into the Yahoo APIs as I look to interface the limitless APIs available out there thanks to Yahoo’s focus on cross-platform integration of their YQL interface. I like that Yahoo isn’t being selfish with this. With YQL, Yahoo has finally created a glue that lets me access all the APIs I need to access as a Building Block Web brick builder.

Twitter Testing "OAuth Delegation" With Select Partners – Genius

Posted on February 5, 2010 by jessestay

A common complaint amongst Twitter developers has been that Twitter’s OAuth, the authentication process you see when you click the Twitter login button on a 3rd party website and go to a Twitter-looking page with a “Allow” or “Deny” button, is too complicated. Mainly, from a user experience perspective, users are required to leave the 3rd party site completely in order to log into Twitter, then get redirected back to the 3rd party site again. If anything breaks along the way, the user is left wondering what to do, and valuable logins, purchases, or registrations could be lost. Facebook has solved this by enabling users to do all the login process via Javascript they provide that produces a popup. Users can log into Facebook without ever leaving the 3rd party site. It appears, based on a thread on the Twitter developers list, that Twitter is planning to one-up Facebook by allowing users to log in to 3rd party sites without ever even needing a popup or any type of redirect, and they’re already testing it with select partners.

The topic came up when other developers noticed that the site, TwitPic.com, was allowing direct Twitter logins right on their own website and somehow posts from TwitPic were showing up with the TwitPic name and link next to the post on Twitter. This normally isn’t possible without enabling OAuth login because Twitter has disabled the functionality for any non-OAuth produced Tweet. In fact they have said in June of 2010 they will be completely removing the ability to login through Twitter on 3rd party sites via plain-text authentication. So how is TwitPic doing it?

According to Raffi, an Engineer on the Twitter API platform team, Twitter is currently working on a new “OAuth Delegation” standard that will allow applications to allow users to log in via Twitter on their own sites, while still maintaining the control over Apps that OAuth gives providers and users. So, on TwitPic, for instance, you can log in to TwitPic.com with your own Twitter username and password right on the TwitPic site itself, yet you’ll still have full control on Twitter.com to revoke access to TwitPic at any time you want to. In addition, Twitter, at any time, can remove TwitPic’s ability to publish or access the Twitter API since they still have to use OAuth to make Twitter API calls.

If the hints in the developers list thread prove true, developers will be able to take the plaintext username and password, still store them somewhere, but in order to make calls through the Twitter API they’ll have to somehow send an OAuth key with their requests to Twitter along with some way of identifying the user. My guess is, in essence, the app will send a one-time login on behalf of the user to Twitter (most likely via a secure SSL encryption channel or similar), and Twitter will return to the app an OAuth token to make API requests with on behalf of that user in the future. In my opinion, this is still no different than storing an OAuth Token in a database that would give apps the same access as their Twitter username and password.

Security Concerns

While storage may be no different, I’m sure there will still be those concerned about this approach. For instance, what happens when users get used to entering their Twitter usernames and passwords on 3rd party websites and decide to do so on a malicious website? We’ve seen how used to entering Twitter credentials people get with websites that look like Twitter itself with the rampant phishing attacks recently.

Maybe Twitter is feeling comfortable enough that they can be proactive about such misuses and password collection. The risk is still there though and hopefully the OAuth Delegation Twitter is getting ready to launch will cover this problem.

Partners

Thus far, it seems TwitPic is one of the partners testing this new delegation standard Twitter is working on. Several others were mentioned in the developer discussions about this as well. For instance, Seesmic Look is also taking similar credentials without any OAuth redirect, yet still shows the “Look” source in Tweets generated with the app. One developer pointed out the information that could be retrieved from the new requests, and the security of it all is a little concerning.

Whatever it ends up being, the winners will be desktop and mobile client developers. Right now developing a mobile or desktop app involves deep integration into the browser in order to legally get the user logged into the app. It is why we see so few native desktop clients and so many AIR apps. AIR is a browser-based solution.

I’m very interested to see what happens. The Twitter team is supposed to announce more details very soon and I’d like to find out more about what this means for developers, how secure it is, and how much recoding I’ll have to do to enable it in my app. Whatever it is, you can bet it will be one step simpler than the currently more-simple solution which Facebook provides. This is getting very interesting! Let the API wars begin…

Developers, It’s Time to Open Up Twitter’s API

Posted on December 19, 2009 by jessestay

If you’ve read my previous post on this, you’ll notice how I re-worded the title of this article. That’s because I’m delusional to think Twitter is going to open source their API any time soon – I’ve been requesting this for over a year now. I think I’ve come to a new understanding that if we’re to see an open standard built around Twitter’s API, it’s going to be we, the developers, who implement this.

It won’t be Twitter.

I mentioned earlier that developers are starting to catch onto this idea. It all started almost 2 years ago when Laconi.ca introduced their own Twitter-compatible API into their platform allowing any client library based on the Twitter platform to very simply add Laconi.ca instances to their preferred Twitter client. Unfortunately it took 2 years for that idea to catch on. Finally, we’re seeing some big players in this, and my predictions are coming true. Automattic just released their own Twitter-like API into WordPress.com. Tumblr just released their own Twitter-like API. The problem here is that all these developers are re-inventing the wheel every time they re-produce Twitter’s API, and any time Twitter releases a new feature they are stuck re-configuring and re-coding their server code to stay up with Twitter’s new API features. That’s fine though – this is all a step in the right direction.

The Vision

Imagine now if there were a standard that, at first duplicated what Twitter was producing on their end, but other developers could code off of. Open Source software could be built around this standard, and now any provider would be able to easily install code that integrated well with their own environments very easily. We’d see many more providers than just WordPress and Tumblr and Laconi.ca instances like TodaysMama Connect (of which I am an advisor) integrate this. We’d see big brands and big companies start to implement this.

Soon Twitter will be in the minority amongst services these “Twitter clients” (like TweetDeck, Tweetie, or Seesmic) support. The Twitter clients will no longer feel obligated to cater to just Twitter, and new layers, such as real time and meta APIs could be added to this API standard in a way that benefits the community, not a single company. Twitter would no longer have a choke-hold on this and we would have a new, distributed architecture that any developer can implement.

The Proposal

What I’m proposing is that we work together to build an open source set of libraries and services, perhaps a gateway of some sort, all built on a standard that we set (it will most likely copy Twitter’s API at the start). I’ve built a Google Group, called “OpenTwitter” for now, with the purpose of opening up Twitter’s APIs. The group will have a primary focus of determining how we want to build this software, establishing documentation for such software, and attaching a completely open standard on top of all that we can modify as it makes sense. The goal here is that the public will now control how this data gets distributed, not a single company.

But What About RSS?

The question always comes up, why not just push these clients to support RSS and rssCloud or Pubsub Hubbub? The answer is that we’ve been trying this for too long. It may still happen, but it’s going to take Twitter clients a lot longer to modify their code to support RSS than an open Twitter-compatible standard. Ideally, a Twitter client, which there are many, ought to be able to quickly and easily just change the base domain of where calls are sent, and everything with the providing service should “just work”. RSS complicates this too much. The fact is that Twitter has taken over and we need to accept that as a fact and work with it.

The Invitation

If you can, I’d like to invite you to join our “OpenTwitter” list on Google. Let’s get some conversations going, and get this thing off the ground. My hope is that we can get people like Dave Winer, Matt Mullenweg, Chris Messina, David Recordon, Joseph Smarr, DeWitt Clinton, and Mike Taylor all joining this effort. My goal is that we can even get Twitter involved in this effort – this isn’t meant to snub Twitter by all means. The entire goal here is to build a much more open, distributed web in as simple a manner as possible.

You can join the “OpenTwitter” list here. I’ll be posting a kickoff message there very soon.

Twitter, It’s Time to Open Source Your API

Posted on December 17, 2009 by jessestay

With the recent launch of a “Twitter API” by both Automattic (WordPress.com) and Tumblr, it is evident that developers have a need to implement similar APIs, on similar platforms, reducing the effort to retrieve data from multiple platforms in a single client. With Tweetie, for instance, you can simply change a single URL to “WordPress.com” or “Tumblr.com” or “Identi.ca” and immediately be receiving updates from your friends on those services, and even post back to those services. I argue this approach is very closed though, as for each and every implementation of a “Twitter API” (which ironically has nothing to do with Twitter), the developers need to completely re-invent the wheel and copy what Twitter has done based on documentation of Twitter’s own API to access its data. Readwriteweb even went to the extent of calling this approach “open”. There’s nothing open about it. Each developer implementing their own “Twitter API” (and especially calling it such) is blatantly ripping off Twitter’s API to do so under no license whatsoever and Twitter’s just standing back and watching. I think it’s time Twitter releases their API under an Open Source license to relieve this mess and protect their IP.

Open Sourcing APIs is nothing new. Of course, Google, with OpenSocial, did it and even standardized their own API for “containers” to easily implement the same API across multiple sites. All the code was provided for developers to do this and we quickly saw sites such as MySpace, Hi5, Orkut, and others all implement the same standard, reducing the code needed to port an app from platform to platform.

Facebook did the same with their platform. A little known fact is that any developer can go to http://developers.facebook.com/opensource.php and download the Facebook Open Platform, along with many other very useful open source tools. Immediately they have access to enable FBML, FBJS, and other aspects of the Facebook API to developers on their own sites, standardizing the Facebook platform amongst sites that implement it. Bebo was one of those who took up Facebook on this offer. Others can too.

What we need now is a standardized platform for sharing micro-content. Some have proposed RSS do this, which is fine with me, but since developers already have apps built on Twitter which this would go with it makes sense to also enable a standardized platform for developers to code on for these types of apps. Such an open-sourced code-base would enable developers to not have to change their code to enable access to similar sites beyond just Twitter. Twitter right now is a closed platform, plain and simple. With the exception of OAuth, they are based on a proprietary API, do not support open content protocols, and even their real-time stream is proprietary.

A good step for Twitter would be to open source this API. Enable sites such as WordPress, Tumblr, Status.net, and others to easily integrate it into their own platformse without the need to re-invent the wheel. Put it under an open license, and then your IP remains protected. Until that point developers are going to continue ripping off Twitter’s API, and Twitter’s IP slowly starts to go down the drain. I’d love to see Twitter take a lead in this process – it took Facebook just about 6 months to open source their API. Why haven’t we seen this yet from Twitter?

Or are they the next Compuserve?

Facebook Posts New Dashboard API Methods, Prepares New Interface

Posted on December 5, 2009 by jessestay

Early today Facebook posted a series of new API methods to their Developer Wiki enabling developers to post updates to what was previously called the “Application Navigation”, but what would now appear to be called “the Dashboard”. The Dashboard API aims to provide an easier interface for users to find updates to their favorite apps without cluttering the stream. At the same time, the Dashboard API tries to encourage more users to bookmark applications and provide applications on Facebook Platform another means of sharing information with their users.

The Dashboard, which will appear on the left-hand navigation either in place of or near the Friend Lists, should launch to users in the next week or two according to a vision statement posted by Mark Zuckerberg recently and the current developer roadmap. When launched, users will be able to bookmark their favorite applications on Facebook or on their favorite Facebook Connect-enabled site and those applications will appear in the left-navigation in the new Dashboard. Applications can then send updates, incrementing a counter when new updates are posted, enabling users to know when new updates are available from their favorite applications. When the user clicks on each application they are taken to a page with the updates.

In addition to traditional applications, according to the new developer documentation there will be a games category in the dashboard. If applications have categorized themselves as a game in the Facebook App directory, their app will appear underneath the Games category. This category appears to try and make it easier for users to manage all their games under one easy navigation so they can focus on the more productive apps beyond just gaming. Other applications appear under an Applications category, and there is also a “Friends’ Games” and “Friends’ Applications” category enabling users to view applications and games their friends are using, I assume.

The new Dashboard API enables developers to do all the things mentioned above, and comes alongside the 6 month developer roadmap announced earlier by Facebook. The roadmap comes with mixed criticism from developers, with some excited for new integration opportunities and better organization, while other developers mad at the removal of some features in the planned changes. One developer I talked to today was frustrated with the frequent changes Facebook makes on the Facebook.com site itself, opting to begin moving his development efforts more over to Facebook Connect where he has more control. I believe that is exactly where Facebook wants him.

The new Dashboard API should provide new opportunities for developers to update their users and easily notify users of changes within their apps. The API, according to the documentation, is available for development and testing now. According to the documentation there is no sandbox for the new API, but developers can start testing these methods on their own servers. It is unclear how developers will be able to begin testing the UI for the new methods.