This morning marked the official deprecation of Twitter's basic authentication system. I had been working toward the changeover, and at about 8 am I switched iTweet.net over to OAuth-based authentication.

Things went pretty smoothly, I hope. Most people seem to have been able to refresh, authenticate with Twitter, and start tweeting again right away. Even aside from the improved security, the nicest immediate benefit is the API rate limit of 350 calls per hour instead of the 150/hour available through basic authentication. This will allow me to do some fun stuff that wasn't possible before.

The people who were most affected by this change were those who use iTweet because twitter.com is blocked due to a company firewall/filter or censorship. These folks are not able to sign in via OAuth, just due to the nature of what OAuth is. I'm bummed that this is the case, but don't immediately see a way around it - however I am open to ideas from any direction.

For the time being I've put a basic-authentication version of iTweet up at:

http://itweet.net/basic/ - and you can use it at that address for the next two weeks.

However, please note that Twitter is going to be cutting down the number of available API requests by 10% every business day until August 31, when basic authentication will be switched off entirely. You can read about this in the twitter-development Google group. If you're one of the folks who use iTweet to get around a filter, this is a bummer.

So by the end of the month people needing a proxy for twitter.com will be out of luck. I'm open to suggestions as to how this inconvenience could be avoided, as this change will happen for all apps, not just iTweet.net - feel free to post ideas in the comments.

My pet project iTweet.net has been a great success for me.  It gets plenty of traffic, enjoys a steadily growing community of users, and is a lot of fun to work on.  The list of things I'd like to explore with this project grows every week, and with all the new additions to the Twitter API of late - OAuth, RTs, Lists, Geolocation etc - there is much more to be done in order to keep up.

The steady increase in traffic means that we've had to spend extra time and money on iTweet's server in order to keep up with all the users.  Hosting has graciously been sponsored by The Illusion Factory, but the monthly demand keeps increasing and it's clear that something needs to change.  The growing nature of both the to-do list and the server cost has led me to think of ways in which iTweet can become self-sustaining.  This app needs to start earning its keep, peoples!  One thing that I've decided to try is the insertion of sponsored tweets by 140 Proof.


This company has a very unique system of advertising delivery, promising very targeted content in an unobtrusive format.  How does that work?  140 Proof's system scans your (publicly available) tweets and delivers you an ad tailored to your location and/or favorite topics.   This means that you'll see content that is interesting and relevant to you.  And the ads come in tweet format so they fit right in with the flow of the app.  Most of them are real tweets, from a real Twitter account, and behave pretty much like the other tweets in your stream - you can reply, favorite or retweet them too.  (I'm giving these sponsored tweets a slightly different style so you can tell them from regular tweets.)


Since a lot of people have asked me what my plans for future development are, here's a nutshell version:

iTweet.net has no database behind it.  It doesn't store any of your information, and only uses data from the Twitter (and TwitPic, bit.ly, etc) APIs.  In order to do some more "interesting" stuff, such as multiple accounts, decent Lists and follower management, autocompleter, etc, I need to put a database behind the front end and rewrite a whole bunch of stuff.  This will let me do a lot more *interesting* things with the app, as it currently operates within the exact constraints of the API.

My immediate goals for iTweet are this:

1. Switch to OAuth - this will eliminate API limit hassles
2. Database-driven back end
3. Support for new APIs - RT, geolocation etc.
4. Support for multiple accounts, other oft-requested features
   
5. Support for internationalization (multiple languages)

Once these major issues are tackled, I'll be looking at expanding iTweet's feature set into a new app, something larger that I have been imagining for some time now.  My hope is that by exploring monetization routes for the app, I'll be able to fund part of this development.


Cheers, and thanks for helping to make my little project take off.  As always the user community will directly influence the direction of future development.  Please let me know your thoughts below or by contacting me directly - I'm interested in hearing what you have to say.

itweet, twitter, api, twitter app, itweet.net, 140 proof, twitter ads

I just noticed in my web app iTweet that Twitter is reporting a maximum of 150 API requests per hour now! Hurray!  This is great news for Twitter clients, as the API limit is a constant challenge in user interaction.

Twitter had mentioned that this was in the works, but so far I haven't heard mention of them actually launching this upgrade.  I hope it is here to stay!

They have also recently fixed a long-standing bug that caused followers/following methods to report incorrect data. Along with this fix came some new API methods for managing follow relationships - I will be updating iTweet with a new follow/unfollow UI just as soon as I can get to it!

There are some really great improvements coming soon to iTweet.net - stay tuned for much much more.

Twitter made an alteration to their API for "in reply to" statuses this week that I felt required a change in the way that iTweet.net handles sending @replies.

One of my personal favorite iTweet features is the "in reply to" links that show what tweet a person was @replying to inline - so you can follow conversations without leaving the page you're on.

Previously if no particular status was specified, Twitter assigned the "in reply to" link to the last tweet of the person who was replied to.  As of this week, they are only assigning that link if a particular tweet was specified - otherwise there will be no "in reply to" tweet marked.  This will help make conversation threading much more clear, but it also required that Twitter API clients get on board with the new method to ensure that threads are clearly designated.

(In case you're wondering, @replies to you will still show up in your Replies tab if no tweet was specified - but there will not be a particular thread attached.)

Here's how I've decided to handle this change - when you click the @ button to send a reply, a small box above the tweet input will show you the tweet you're replying to.  If you don't want to mark your tweet as a reply to that status, simply click the "cancel" button.

One bonus of this is that you don't necessarily need to begin a @reply tweet with "@username" - the tweet will get marked as a reply (and appear in the user's Replies tab) whether you use that convention or not.

The only thing you'll need to be careful of is accidentally marking a tweet as part of a conversation if you changed your mind about the original @reply - so don't forget to click the "Cancel" button if you're not going to reply to that tweet.

One idea that occurred to me would be to also tie the "RT" retweet button to this behavior, so that if you retweeted someone they would see that retweet in their "Replies" tab - kind of a nice way of letting them know you liked their tweet enough to retweet it.  Does that sound like a helpful addition?

Let me know in the comments, or tweet or email me with your thoughts!

Technorati Tags: itweet, twitter, api

I've made a couple additions and modifications to iTweet this week, they are lots of fun and add some great functionality!

In the Web interface I've added Statistics to your profile in the top right - so you can see at a glance your number of updates, favorites, following and followers. This updates itself as you tweet, fave and follow.  There is also an "Appearance" preference in the Settings menu - you can keep the default iTweet look OR import your Twitter profile's appearance - background image, font colors, sidebar color and everything!

If you are wondering "where did the nifty follow/notifications/block buttons go?", I have moved them all to the Profile pages to make better use of the API and make these methods more intuitive.  The old method assumed whether you were following a person or not based on the timeline they were found in; this was a little confusing and inconvenient, so I've moved it to the Profile page.  Here the page can tell (via the Twitter API call) whether you are following that person or not, and present the correct options depending on that status.

There's also an "is so-and-so following me?" button so you can see if that person is following you, and a "Twittering Since" date that shows when that person joined Twitter.  That part has been interesting to me as it's neat to see how long someone has been part of the Twitter community.  That data is made available via the Twitter API, although for some reason you can't find that info about a user on twitter.com - another reason to use iTweet!


Leave comments on this blog, or let's talk on Twitter or Facebook.

itweet, twitter, api, iphone

Twitter just made a great addition to their Search API: Twitter Trends!

This method allows you to see the hot topics of discussion across the entire Twitterverse.  This is a neat way to keep up on breaking news, technology trends, political sentiments, or the latest Internet meme that everyone's tweeting about.

When I hear about some fresh news or tech rumor, I do a quick Twitter search before I go to any news website; it's a great way to find a wealth of links to pertinent content across the Web.

I've added the Twitter Trends method to both the iPhone and the Web version of iTweet.net.  I think it will become a fun way to keep up on current events, and to entertain myself when I'm stuck in line at the bank.    Enjoy!

Leave comments on this blog, or let's talk on Twitter or Facebook.

Technorati Tags: itweet, itweet.net, twitter, iphone, trends, api, colby palmer

Today I'm releasing a major upgrade to iTweet, an interface for Twitter that is one of my pet projects.  This is a double release: a hugely improved iPhone Web app, and an all-new interface for any Web browser.

Click here to give the new iTweet a try!

Beginning with the iPhone app, there are some key features to note:

• Tap user pictures to toggle bio information. This section allows you to see a user's location, bio, and URL.  There are quick links to send a DM, view extended profile, turn notifications on/off, block, and follow/unfollow.
• "In reply to" links allow you to see the tweet a person was replying to, without loading a new page.
  
• Built-in search and hashtags via the Twitter Search API.
  
• Monitor your remaining API requests using the number in the "refresh" button.
  
• Update (and check) your location from the Settings menu.
  
• Change your notifications device, get more detailed API usage info, set hashtags preferences, and more from the Settings menu.
  
• Vastly improved speed in loading all timelines.
  

As before, a basic rule of thumb with iTweet goes: tap the avatar to see a person's profile, tap the username to see a person's tweets.

There is also a contact form on the About page, please use this for feature requests and bug reports!  (It sends messages directly to my email so you will get a quick response, especially if you're following me and I can DM you.)   <3


The Web interface has all the same features as the above, but adds some more information that doesn't fit on a tiny iPhone screen:

• Detailed user info and API limit info available at top right.
  
• Speed Tweet mode! Hitting the "Return" key from the text-entry field will send your tweet, more like an IM client than the Twitter website. Give it a try! I love it... if you don't you can turn that feature off using the Settings menu.
  
• Really simple method for sending DM's, I use this one all the time too.
  

Known issues and limitations:

• Character counter on the iPhone version still slows down typing. This is the biggest problem with the app, by my own reckoning and others' as well. I've tried many, many different methods of doing this. We're talking HOURS of experimentation! Basically I find that inspecting a textarea just kills MobileSafari's performance, especially in a Web page that has a lot of other elements in it.  I'm open to suggestions, as always. I've pared it down to 3 simple lines of Javascript and I don't think it can be any lighter than that.
  
• User profile pages are missing information for most users. Also profile information such as "last update" are running behind something like 5-18 hours.  This is due to a bug in the Twitter API which I have reported here. I will post an update when this is fixed. This will allow some very cool functions to be brought back to the Web version especially!
  

Happy iTweeting! I'm always interested in your feedback, you can contact me here.

Leave comments on this blog, or let's talk on Twitter or Facebook.

Technorati Tags: itweet, iphone, twitter, api, iphone app, colby palmer

Twitter has decided to remove a certain call from their API that the iTweet 2 private beta relied on to create the "ticker" effect that kept it updating at nearly real-time speeds.  The rate limit for API calls also remains handicapped, cut to 30 per hour from the usual 70.  This makes using Twitter API tools extremely inconvenient, and developing them is also quite frustrating.

For now I have removed the "ticker" feature and the friends timeline will refresh every 140 seconds, though this number may be adjusted slightly as I attempt to keep the page open and in use today.  (Big thanks to all my helpful beta testers for your excellent feedback on the last iTweet 2 development cycle!)  Further development on the beta will continue when the API rate limit returns to normal.  Until then, Twitter API development is a waste of time as most people seem to be ditching API apps for the non-limited Web site.

This is actually a good thing for me, as I am working hard on developing some other tools for The Illusion Factory that I will be posting more about soon.  Apologies for the lack of updates recently, I've been in "workshop mode" for quite some time but I will be posting details about the new ideas, tools and projects I've been working with in the coming weeks.  (I call this "pimp" mode as I will be hawking the bejeezus out of my work.)  I'm building some really neat ways of connecting with people, and I am very excited to share them as soon as possible!

Twitter has been very cool about keeping the community updated on its current status, present challenges and plans for future improvement, despite some really nasty attacks and and the lively scrutiny of about a million people speculating on who is to blame, or how a business model could be developed, or how they can fix Twitter's problems in a single blog post/comment/tweet.  They were also kind enough to post a poll in the dev group about removing the friends_timeline/username API call.  This is not something they HAVE to do, so I thought it was nice of them to bother. And — even though I was getting great use out of this feature — I voted that if removing it meant a tangible improvement to Twitter's stability, I would take it out back and shoot it myself.

Here's why I would vote to remove a feature that made iTweet's beta the most bitchin' Twitter interface for the Web: The problems Twitter is suffering from are going to take a while to solve, and more downgrades may happen. The Twitter team is working on it, and I am willing to be patient during the downtimes and downgrades while they get their app sorted out. I enjoy using Twitter and making fun stuff with their API.  But I have lots of other things that I like, and plenty of projects in the works.  I know they are doing their best to improve and/or rebuild their service, so when they've gotten through the current setbacks, I'll be back for more.  Rather than getting cranky about it, obsessing over it, or otherwise wasting my mental energy on it, I'll just go play with some other toys until this one gets glued back together again.

And of course, in the meantime a shinier toy may come along and Twitter may end up collecting dust.  That is the risk they are running every day that their service is downgraded... and I am sure no one is more aware of this than the Twitter team themselves.

Leave comments on this blog, or let's talk on Twitter or Facebook.

Tags: twitter, downtime, api, web development, itweet