I wonder if it might be an acceptable compromise for twitter to not count certain requests against an authenticated user. These request should theoretically not be much if any more expensive in CPU or bandwidth than the rate limit check itself.
I propose that any request with a since_id that does not return any results not apply to the 100 request/hour limit. A request like this would result in a very quick indexed primary key lookup in the datasource being used to store the data. Also, in the case that no new items existed there would be no data returned to use datasource server bandwidth and it would not use any more bandwidth on the webserver than a 400 rate limit exceeded message. Perhaps these request should still be rate limited, but with higher caps. This would allow developers to provide nearly real-time updates in our clients without necessitating something extreme like implementing some Firehose based distribution system. Between trying to keep friend-statuses, user-statuses, @replies, direct messages sent, direct messages received, the following list, and the followers list all somewhat in sync puts a pretty heavy burden on the 100 request/hour limit. Especially considering the case where someone has a multiple clients on a laptop, work desktop, home desktop, and/or iPhone puts developers in a bit of a predicament. Josh
