[twitter-dev] Re: media types in the tweet

2010-10-24 Thread Jaanus
It would be awesome if entities or annotations contained this info.
Right now it doesn't seem to be available.


J


On Oct 23, 3:58 pm, mostafa farghaly keepon...@gmail.com wrote:
 on twitter.com if the tweet contain image, video ...etc : the tweet
 will have image  video icons even if the links to this media is
 short ... is there a better way for knowing the media types in the
 tweets from the API than analyzing the long urls ?

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk


[twitter-dev] Re: How many people have authorized my application?

2010-10-09 Thread Jaanus
To collect all this info myself, I would need to operate some kind of
service on an ongoing basis. This is not that practical with a pure
client app like an iPhone app. Yes, I could build a server to collect
all the info and what not, but it would be much more convenient if I
could just go to Twitter site and look it up without having to build
and operate something.

I do agree that it is probably not a big business problem for Twitter
on a grand scale. But Twitter's success has largely come out of the
ecosystem. It would be cool if Twitter invested in small things like
this to keep us developers happy so that we could keep making money
for both them and ourselves.


J


On Oct 9, 5:29 pm, nischalshetty nischalshett...@gmail.com wrote:
 @Januus you could do that on your end as well, twitter doesn't
 restrict you from keeping a count on the number of users of your app.
 Nevertheless it would be awesome if twitter did it themselves, but as
 we can see from the reply above by @taylor they have scaling issues
 with the count and as far as I can tell, this would be low on their
 priority (any company would keep this on low priority when they have
 bigger problems out there to solve)

 -Nischal

 On Oct 9, 6:48 am, Jaanus jaa...@gmail.com wrote:



  Twitter has been advertising better analytics for themselves about
  users, apps, and developers, as one of the key benefits of migration
  to OAuth. I believe its completely true, and it would be nice if you
  reflected a bit of that benefit back to developers in the form of
  unique userIDs that have got a token for this consumer_key like it
  used to be on Twitter site. Even if it were with a day's lag or such,
  it would still be valuable to developers, it does not have to be
  realtime and with a load impact at all.

  J

  On Sep 29, 7:55 am, Taylor Singletary taylorsinglet...@twitter.com
  wrote:

   The loading of the information would not scale for many clients,
   resulting in whales when trying to load your application (lame but
   true). It's best to track such information by your own means. I'd be
   happy to look up the value for you if you follow up with me off-list.

   Thanks,
   Taylor

   On Wed, Sep 29, 2010 at 7:51 AM, Duane Roelands

   duane.roela...@gmail.com wrote:
I used to be able to go tohttp://twitter.com/oauth_clientsandsee
how many users have authorized my application.  Twitter appears to
have removed those numbers.

Where can I go to find out how many people have authorized my
application?
Why was this information removed?

--
Twitter developer documentation and resources:http://dev.twitter.com/doc
API updates via Twitter:http://twitter.com/twitterapi
Issues/Enhancements 
Tracker:http://code.google.com/p/twitter-api/issues/list
Change your membership to this 
group:http://groups.google.com/group/twitter-development-talk

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk


[twitter-dev] Re: How many people have authorized my application?

2010-10-08 Thread Jaanus
Twitter has been advertising better analytics for themselves about
users, apps, and developers, as one of the key benefits of migration
to OAuth. I believe its completely true, and it would be nice if you
reflected a bit of that benefit back to developers in the form of
unique userIDs that have got a token for this consumer_key like it
used to be on Twitter site. Even if it were with a day's lag or such,
it would still be valuable to developers, it does not have to be
realtime and with a load impact at all.


J


On Sep 29, 7:55 am, Taylor Singletary taylorsinglet...@twitter.com
wrote:
 The loading of the information would not scale for many clients,
 resulting in whales when trying to load your application (lame but
 true). It's best to track such information by your own means. I'd be
 happy to look up the value for you if you follow up with me off-list.

 Thanks,
 Taylor

 On Wed, Sep 29, 2010 at 7:51 AM, Duane Roelands



 duane.roela...@gmail.com wrote:
  I used to be able to go tohttp://twitter.com/oauth_clientsand see
  how many users have authorized my application.  Twitter appears to
  have removed those numbers.

  Where can I go to find out how many people have authorized my
  application?
  Why was this information removed?

  --
  Twitter developer documentation and resources:http://dev.twitter.com/doc
  API updates via Twitter:http://twitter.com/twitterapi
  Issues/Enhancements Tracker:http://code.google.com/p/twitter-api/issues/list
  Change your membership to this 
  group:http://groups.google.com/group/twitter-development-talk

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk


[twitter-dev] Re: Can we have bulk statuses/show?

2010-09-06 Thread Jaanus
Thanks, this makes sense (that api status fetching is modeling your
cost this way).

J


On Sep 1, 7:40 am, John Kalucki j...@twitter.com wrote:
 Fetching a random list of statuses is likely to include a number of statuses
 that are not in cache. I think accounting for them on a one-by-one basis
 models our cost fairly well.

 -John Kaluckihttp://twitter.com/jkalucki
 Twitter Inc.



 On Wed, Sep 1, 2010 at 8:00 AM, Jaanus jaa...@gmail.com wrote:
  The statuses/show/:id API method right now only retrieves a single
  status. Could we have a bulk version, where you can pass a set of
  status ID-s, and receive a set of statuses in return? Primary
  motivation is to conserve rate limit. In some apps, you have a set of
  status ID-s that you want to display to user, and fetching them one by
  one consumes limit like crazy.

  J

  --
  Twitter developer documentation and resources:http://dev.twitter.com/doc
  API updates via Twitter:http://twitter.com/twitterapi
  Issues/Enhancements Tracker:
 http://code.google.com/p/twitter-api/issues/list
  Change your membership to this group:
 http://groups.google.com/group/twitter-development-talk?hl=en

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk?hl=en


[twitter-dev] Can we have bulk statuses/show?

2010-09-01 Thread Jaanus
The statuses/show/:id API method right now only retrieves a single
status. Could we have a bulk version, where you can pass a set of
status ID-s, and receive a set of statuses in return? Primary
motivation is to conserve rate limit. In some apps, you have a set of
status ID-s that you want to display to user, and fetching them one by
one consumes limit like crazy.


J

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk?hl=en


[twitter-dev] Re: Profile image uploads not working (using twitter-async)

2010-07-14 Thread Jaanus
I have a similar problem. I am trying to upload a profile image with
the API with OAuth authentication. I get a 200 response and a valid
response body, indicating a path like
http://a1.twimg.com/profile_images/1078800125/myProfileImage_normal.jpg
in the response for the uploaded image. However, when I try to access
this URL, I get HTTP 403 Forbidden. Is this expected in the current
state of things, or is the problem on my client side?


J


On Jun 15, 8:12 am, Taylor Singletary taylorsinglet...@twitter.com
wrote:
 The image upload facilities at Twitter are in need of some love (and are
 being worked on!) -- they'll often throw a 500 error and actually update the
 image, or show a 500 error and not update the image.. it should, in general,
 function better and more reliably in the near future.  The current site
 issues make it sometimes difficult to have clarity on how something failed,
 and at what stage.

 Taylor Singletary
 Developer Advocate, Twitterhttp://twitter.com/episod



 On Tue, Jun 15, 2010 at 7:00 AM, Roy Tanck roy.ta...@gmail.com wrote:
  I'm trying to upload profile images using oAuth. This basically works
  (I get the right return data, no errors), except that the image is not
  updated. Sending tweets through the same library does work, so this
  probably isn't an authentication issue.

  As per the twitter-async documentation, I'm using:

  $twitterObj-post('/account/update_profile_image.json', array('@image'
  = '@'.$img_path));

  $img_path is the correct path (+filename) for the file, I've checked
  the folder name using phpinfo, used a test image, etc.

  Since I'm not getting errors, this issue is very hard to troubleshoot
  from my end. Suggestions on how to tackle this very welcome.

  (More info on twitter-async is here:
 http://github.com/jmathai/twitter-async
  , on sending images here
 http://wiki.github.com/jmathai/twitter-async/#multipart)


[twitter-dev] Rich content in tweets as entities/annotations?

2010-07-01 Thread Jaanus
This is a request to the Twitter API team but rather than sending it
in private, I'm posting it here so others can chime in too.

Tweets are 140 characters. But sometimes Twitter decides that some
content is interesting enough to annotate with graphical icons on
Twitter.com. Examples are red ribbon/aids that I think happened a
while ago, and now during World Cup, the #worldcup hashtag gets a
football icon and all the #country 3-letter abbreviations get a flag.

These things happen quickly and spontaneously enough inside Twitter
that it's not possible or necessary to coordinate with dev community
beforehand. I appreciate that, and that's perfectly fine. But perhaps
you can send developers this data as metadata, so should the apps opt
in to displaying these, they could do that too? You already have two
mechanisms in place for this that you could utilize — the entities
where you transmit the URLs and hashtags, and of course annotations.
Could we have these icons transmitted as part of either of these
mechanisms? And maybe you can standardize the height or size so we
could consider it in our UI layouts?


J
cremeapp.com


[twitter-dev] Re: countdown to OAuth / basic auth removal / OAuthcalypse

2010-04-26 Thread Jaanus
 I'm still not buying it that oauth is going add any value for desktop
 clients with regards to password security. Basically you are now storing
 token in the desktop client instead of password.

The added security is that either your malicious app, or, say some
trojan in the user's computer, cannot grab the token and get full user
privileges. If you store password, they can log on, change the
password and email on the account, and cause all other sorts of
trouble. with oAuth, the damage is limited to one user/app
combination, they cannot grab the token and change, say, the user's
email address on file. (Looks like the user's email address is not
exposed anywhere in the API, and that's a good thing.) The user can
clearly see what apps have permission to act on their behalf, and can
revoke access app-by-app, instead of having to change the password in
all apps.

A more practical example of improved security is that in the past, I
have myself had instances where I have changed my twitter password,
but forgot to change it in apps using basic auth. And apps are
implemented crappily (OTHER people's apps, but never yours, right? ;)
and do not check response when signing in and keep hammering the API
with wrong password. End result - my account is locked out due to what
looks like bruteforce hacking, and I need to go and reset it. Doable,
but annoying.

There are other benefits, but these two are very obvious and
practical. Deprecating Basic Auth in favor of OAuth will be painful
for both Twitter and lazy/bad developers (if you are a good developer,
OAuth won't really bother you at all), but I commend Twitter for doing
this.


J


-- 
Subscription settings: 
http://groups.google.com/group/twitter-development-talk/subscribe?hl=en


[twitter-dev] Re: countdown to OAuth / basic auth removal / OAuthcalypse

2010-04-24 Thread Jaanus
Is there any kind of special involvement needed from you every time
someone wants to do OAuth Echo? I thought I'll make my own server for
my own app for some purpose. Judging by the spec you posted on your
blog a while ago (http://mehack.com/oauth-echo-delegation-in-identity-
verificatio), it does not look like some special Twitter involvement
is needed, as long as I implement all that's needed in my app and
server?


J


On Apr 24, 5:44 pm, Raffi Krikorian ra...@twitter.com wrote:
 hi tom!

 i will be sending more info about it - we've been working with yfrog,
 tweetphoto, and twitpic to get their services migrated - they are either
 finished or are nearly there.  if there are others that you would like the
 @twitterapi team involved with to help them get migrated over as well, then
 feel free to drop me an e-mail asking me.

 On Sat, Apr 24, 2010 at 10:48 AM, Thomas Woolway tswool...@gmail.comwrote:





  Hi Raffi,

  Great that we've got a date for basic auth deprecation, but is there any
  news/timescales on OAuth Echo? We've got nine weeks and counting to get the
  spec, get the service providers to implement it, build it into clients and
  get our user-bases to upgrade if they want to be able to upload photos post
  June 30th. That's easier if you're web based, but not a huge amount of time
  if you are desktop or mobile based.

  Thanks,

  Tom

  On Sat, Apr 24, 2010 at 4:49 PM, Raffi Krikorian ra...@twitter.comwrote:

  there is a really good chance - now that oauth 2.0 has been submitted as a
  drafthttp://tools.ietf.org/html/draft-hammer-oauth2-00, we are going to
  spend some time catching up our oauth 2.0 implementation.  at that point,
  we'll evaluate letting it loose.

  On Sat, Apr 24, 2010 at 8:44 AM, Dewald Pretorius dpr...@gmail.comwrote:

  Raffi, that is super awesome. Thank you.

  Any chance that you will have OAuth 2.0 in production before then?

  On Apr 24, 12:40 pm, Raffi Krikorian ra...@twitter.com wrote:
   hi all.

   you're going to be hearing a lot from me over the next 9 weeks.  our
  plan is
   to turn off basic authorization on the API by june 30, 2010 --
  developers
   will have to switch over to OAuth by that time.  between now and then,
  there
   will be a *lot* of information coming along with tips on how to use
  OAuth
   Echo, xAuth, etc.  we really want to make this transition as easy as we
  can
   for everybody.

   as always, please feel free to reach out to this group, or to
  @twitterapi
   directly.  if you need help remembering the date -
 http://bit.ly/twcountdown
   .

   --
   Raffi Krikorian
   Twitter Platform Teamhttp://twitter.com/raffi

   --
   Subscription settings:
 http://groups.google.com/group/twitter-development-talk/subscribe?hl=en

  --
  Raffi Krikorian
  Twitter Platform Team
 http://twitter.com/raffi

 --
 Raffi Krikorian
 Twitter Platform Teamhttp://twitter.com/raffi


[twitter-dev] Re: Image Tags in Tweets?!

2010-04-24 Thread Jaanus
A fine answer, but does not answer the question ;) looks like you guys
are injecting custom images after some hashtags on the site?


J


On Apr 23, 10:20 pm, Raffi Krikorian ra...@twitter.com wrote:
 http://hope140.org/endmalaria





 On Fri, Apr 23, 2010 at 2:54 PM, John Meyer john.l.me...@gmail.com wrote:
  On 4/23/2010 3:42 PM, Jonathan Strauss wrote:

  The last few tweets from @twitter feature the #endmalaria hash tag. On
  some pages, likehttp://twitter.com/twitterand
 http://twitter.com/#search?q=%23endmalaria,
  the hash tag is followed by an image of a mosquito (http://
  a1.twimg.com/a/1272044617/images/mosquito.gif) which is hyperlinked to
  a different page than the hash tag itself. Yet on other pages, like
 http://twitter.com/twitter/status/12719532503, and in the API (http://
  api.twitter.com/1/statuses/show/12719532503.xml), the mosquito image
  doesn't appear at all.

  What gives? Is this some kind of annotations test or something totally
  different?

   Well I wouldn't expect that a mosquito image appear on a text xml file,
  but it appears on the twitter 12719532503 status it appears.

  --
  Subscription settings:
 http://groups.google.com/group/twitter-development-talk/subscribe?hl=en

 --
 Raffi Krikorian
 Twitter Platform Teamhttp://twitter.com/raffi


[twitter-dev] Re: Feature Request: Retrieve direct messages between requester and a single user

2010-04-24 Thread Jaanus
+1 to DMs being a stream, and splitting send/received not making much
sense, neither globally nor in one contact context. I treat them as
sort of a single meta-call in my app, consisting of two sub-calls, and
this seems to be general behavior in all apps and also matches user
model.


J


On Apr 23, 1:13 pm, Orian Marx (@orian) or...@orianmarx.com wrote:
 Sure, yeah. But I would argue that DMs make more sense to be viewed by
 default as a stream of back and forth messages vs a separate history
 of sent and history of received. I would say it makes more sense to
 offer it as one endpoint to be split client side rather than two
 endpoints to be merged client side. Of course, the current situation
 is they are split and I'm sure there is some historical reason for
 that and I wouldn't expect it to be changed. But in terms of a new
 endpoint specifically for retrieving a history of conversation with a
 particular user I don't really see what the benefit would be of
 serving it up split (to the consuming application).

 On Apr 23, 1:04 pm, John Meyer john.l.me...@gmail.com wrote:



  On 4/23/2010 10:58 AM, Orian Marx (@orian) wrote:

   f having two endpoints for
   sent / received DMs in the first place, as you end up needing to make
   two calls and then sort everything (if you're trying to show a stream
   of DM conversations).

  But if you're not making them into a conversation it makes more sense
  (i.e. a history).

  --
  Subscription 
  settings:http://groups.google.com/group/twitter-development-talk/subscribe?hl=en


[twitter-dev] Re: Announcing Twurl: OAuth-enabled curl for the Twitter API

2010-04-21 Thread Jaanus
I can't get it to authorize.

my-mac:~ jaanus$ twurl authorize --consumer-key blabla --consumer-
secret blabla
You must authorize first

huh?


On Apr 20, 3:13 pm, Marcel Molina mar...@twitter.com wrote:
 We've announced that come June 2010, Basic Auth will no longer be supported
 via the Twitter API. All authenticated requests will be moving to OAuth
 (either version 1.0a or the emerging 2.0 spec). There are many benefits from
 this change. Aside from the obvious security improvements, having all
 requests be signed with OAuth gives us far better visibility into our
 traffic and allows us many more tools for controlling and limiting abuse.
 When we know and trust the origin of our traffic we can loosen the reigns a
 lot and trust by default. We've already made a move in this direction by
 automatically increasing rate limits for requests signed with OAuth made to
 the new versioned api.twitter.com host.

 One of the often cited virtues of the Twitter API is its simplicity. All you
 have to do to poke around at the API is curl, for 
 example,http://api.twitter.com/1/users/noradio.xmland you're off and running. 
 When
 you require that OAuth be added to the mix, you risk losing the simplicity
 and low barrier to entry that curl affords you. We want to preserve this
 simplicity. So we've provided two tools to let you poke around at the API
 without having to fuss with all the extraneous details of OAuth. For those
 who want the ease of the web, we've already included an API console in our
 new developer portal athttp://dev.twitter.com/console. And now today we're
 glad to make available the Twurl command line utility as open source
 software:

  http://github.com/marcel/twurl

 If you already have RubyGems (http://rubygems.org/), you can install it with
 the gem command:

   sudo gem i twurl --sourcehttp://rubygems.org

 If you don't have RubyGems but you have Rake (http://rake.rubyforge.org/),
 you can install it from source. Check out the INSTALL file 
 (http://github.com/marcel/twurl/blob/master/INSTALL).

 Once you've got it installed, start off by checking out the README 
 (http://github.com/marcel/twurl/blob/master/README) (you can always get the
 README by running 'twurl -T'):

 +---+
 | Twurl |
 +---+

 Twurl is like curl, but tailored specifically for the Twitter API.
 It knows how to grant an access token to a client application for
 a specified user and then sign all requests with that access token.

 It also provides other development and debugging conveniences such
 as defining aliases for common requests, as well as support for
 multiple access tokens to easily switch between different client
 applications and Twitter accounts.

 +-+
 | Getting Started |
 +-+

 The first thing you have to do is register an OAuth application
 to get a consumer key and secret.

  http://dev.twitter.com/apps/new

 When you have your consumer key and its secret you authorize
 your Twitter account to make API requests with your consumer key
 and secret.

   % twurl authorize --consumer-key the_key       \
                     --consumer-secret the_secret

 This will return an URL that you should open up in your browser.
 Authenticate to Twitter, and then enter the returned PIN back into
 the terminal.  Assuming all that works well, you will beauthorized
 to make requests with the API. Twurl will tell you as much.

 If your consumer application has xAuth enabled, then you can use
 a variant of the above

   % twurl authorize -u username -p password      \
                     --consumer-key the_key       \
                     --consumer-secret the_secret

 And, again assuming your username, password, key and secret is
 correct, will authorize you in one step.

 +-+
 | Making Requests |
 +-+

 The simplest request just requires that you specify the path you
 want to request.

   % twurl /1/statuses/home_timeline.xml

 Similar to curl, a GET request is performed by default.

 You can implicitly perform a POST request by passing the -d option,
 which specifies POST parameters.

   % twurl -d 'status=Testing twurl' /1/statuses/update.xml

 You can explicitly specify what request method to perform with
 the -X (or --request-method) option.

   % twurl -X DELETE /1/statuses/destroy/123456.xml

 +--+
 | Creating aliases |
 +--+

   % twurl alias h /1/statuses/home_timeline.xml

 You can then use h in place of the full path.

   % twurl h

 Paths that require additional options such as request parameters for example
 can
 be used with aliases the same as with full explicit paths, just as you might
 expect.

   % twurl alias tweet /1/statuses/update.xml
   % twurl tweet -d status=Aliases in twurl are convenient

 +---+
 | Changing your default profile |
 +---+

 The first time you authorize a client application to make requests on behalf
 of your account, twurl

[twitter-dev] Re: [twitter-api-announce] Early look at Annotations

2010-04-16 Thread Jaanus
I feel what Marcel proposed is pretty cool, and does not need much
change before rolling out the first version, to start discovering what
needs to be improved based on real use.

Rogue apps are a concern with or without annotations. It's the same
problem as, say, spamming people with @mentions or #hashtags
excessively. Twitter is not pre-emptively policing this right now, I'm
sure they work on it behind the scenes, and it's fine.

For namespaces, one random thought is that you may want to consider
registering them, so that you know who has created a namespace, and
you could then validate them upon tweet posting, helping against
things like typos. I may still submit annotations in any namespace, as
long as _someone_ has registered the namespace. And they would be in a
browsable directory. Registration process could be similar to current
OAuth/@anywhere app registration, but independent of apps.

A lighter version of the above with all the benefits sans validation
is a free-for-all wiki where people just register their namespace on a
wikipage, and it helps people collaborate and discover what's going
on. Maybe Twitter wiki can have a section for that, or there will be
another semi-official one somewhere.


J


On Apr 16, 3:11 pm, Marcel Molina mar...@twitter.com wrote:
 We definitely want to have documents on dev.twitter.com with best practices
 and guildelines. That will be key. We're looking for everyone to help devise
 the rules of the road.





 On Fri, Apr 16, 2010 at 11:59 AM, gabriele renzi rff@gmail.com wrote:
  On Fri, Apr 16, 2010 at 8:51 PM, Marcel Molina mar...@twitter.com wrote:
   More namespace nesting would of course increase people's ability to
   taxonomize. It's a splippery slope though and we are trying to balance
   expressiveness with simplicity. Providing for arbitrarily nested
  namespaces
   increases complexity considerably both from an implementation perspective
   and a comprehension perspective.

  I am not in favour of arbitrarrily nested, quads are ok to express
  almost anything useful apart from temporal logic :) (consider a
  namespace app: subject-verb-object).

  But I'm ok with you choice, just, as i said, can we at least put some
  guidelines so we can avoid unintentional conflicts among implementors?
  E.g. if you want to store triples and avoid conflicts with other
  applications use a namespace such as yourapp:subnamespace - key -
  value

  --
  Subscription settings:
 http://groups.google.com/group/twitter-development-talk/subscribe?hl=en

 --
 Marcel Molina
 Twitter Platform Teamhttp://twitter.com/noradio


[twitter-dev] Re: Early look at Annotations

2010-04-16 Thread Jaanus
Another 2c: you should think about publishing numbers/stats for
annotations. Easiest to start on the level of namespaces. Publish
stats about popularity of namespaces: how many tweets and how many
users use which namespaces. And don't do that's a good idea and there
are still many moving parts and we are thinking of it for the future,
do this is absolutely vital for the community from day 1 :) This
would be a good measure for community to inform what namespaces to
support, what works and what doesn't, etc.


J


-- 
Subscription settings: 
http://groups.google.com/group/twitter-development-talk/subscribe?hl=en


[twitter-dev] Re: App user counts missing from http://dev.twitter.com/apps

2010-04-15 Thread Jaanus
On Apr 15, 12:27 am, Taylor Singletary taylorsinglet...@twitter.com
wrote:

 It's obviously a good number to know, but it's also a number you
 should be able to derive through good monitoring in your own
 application...

Such monitoring is difficult for client apps. Yes, you can get
download/purchase stats. But if you do not have client side app
tracking implemented, then the simple number of users from Twitter is
great to compare with the store stats. Of course there are roundabout
ways to get everything, but why not show a little love and make
peoples/devs lives easier.

And, how come dev.twitter.com does not use OAuth and has its own weird
login page? Do as I say, not as I do? ;)


J


[twitter-dev] Re: Basic Auth Deprecation

2010-04-14 Thread Jaanus
Why are you Twitter guys pushing xAuth so hard? Even for new desktop
clients? Instead of recommending a proper oAuth flow with PIN or such?
I understood its main purpose is to help legacy clients with
transition, and new clients should do proper oAuth.

One argument I have seen is that oAuth has usability problems. I would
like to see more substance around this statement beyond just
developers thinking out loud. I have implemented oAuth in @cremeapp
(ok, it uses in-app browser instead of separate, but otherwise it is
the proper PIN flow) and not a single person has complained. I see
from usage numbers that people breeze through the oAuth authentication
just fine. I was expecting worse, but it's fine. It comes down to
proper UI design and clarity of instructions.


J


On Apr 14, 1:15 am, Taylor Singletary taylorsinglet...@twitter.com
wrote:
 Basic auto being turned off means just that..

 Desktop clients can implement xAuth as an alternative, where you do a
 one-time exchange of login and password for an OAuth access token and
 continue from there signing your requests and doing things in the
 OAuth way. You'd no longer, as a best practice and one that I would
 stress in the upmost even on a desktop client, store the login and
 password beyond the xAuth access token negotiation step. If the token
 were revoked you would then query for the login and password again and
 so on and so on and also and also.

 Obtaining permission to use xAuth for desktop clients is as easy as
 sending a well-identified and verbose note to a...@twitter.com.

 Basic auth had a good run. It's nearly time to say goodnight.

 Taylor





 On Tuesday, April 13, 2010, Dean Collins d...@cognation.net wrote:
  Just so I understand this, applications running on the desktop will still 
  work correct? Basic functionality is only being turned off for web apps 
  correct? It's not like desktop apps will have to start using oauth.

  Cheers,

  Dean

  -Original Message-
  From: twitter-development-talk@googlegroups.com 
  [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald 
  Pretorius
  Sent: Tuesday, April 13, 2010 7:31 PM
  To: Twitter Development Talk
  Subject: [twitter-dev] Re: Basic Auth Deprecation

  Could you please announce the hard turn off date somewhere on one of
  your Twitter blogs about a month ahead of time, so that we all have an
  official source to point our users to when we explain to them why
  we're converting everything over to OAuth?

  On Apr 13, 8:19 pm, Raffi Krikorian ra...@twitter.com wrote:
  we have announced deprecation, and will hard turn off basic authentication
  in june.  the exact date has not been set, but i presume it will be later 
  in
  the month.

  Is Basic Auth going to be deprecated (as in hard switched-off) in

   June, or are you in June going to announce depracation, with the hard
   switch-off then coming a few months later?

  --
  Raffi Krikorian
  Twitter Platform Teamhttp://twitter.com/raffi

  --
  To unsubscribe, reply using remove me as the subject.

 --
 Taylor Singletary
 Developer Advocate, Twitterhttp://twitter.com/episod


[twitter-dev] Re: Basic Auth Deprecation

2010-04-14 Thread Jaanus
I like oAuth because for both Twitter and me as a developer, it
associates the request with both the user and app. As a developer, I
have a bunch of apps and I can go to twitter.com/oauth to see the
number of users that have used each app. (One thing that I noticed -
the number goes down sometimes??? Why is that?) Twitter can do things
like block rogue apps, analyze popularity easily etc.


On Apr 14, 8:58 am, Raffi Krikorian ra...@twitter.com wrote:
 in my ideal world, nobody would have access to a user's password except
 twitter.com -- oauth provides a framework so end applications are not
 storing the actual password.  people are notoriously bad with using the same
 password on lots of different sites.  additionally, oauth provides twitter
 better visibility into the traffic coming into our system, so we can better
 shape traffic needs, we can provide auditing back to users on which
 applications are doing what actions on their behalf, etc.

 On Wed, Apr 14, 2010 at 5:39 AM, Dean #39;at#39; Cognation dot Net 





 d...@cognation.net wrote:
  But why is oauth better than basic for a desktop client?

  i understand it for the webapps but on a desktop client whats the
  point?

  Basically you are saying the desktop end user cant be trusted? Sorry
  but that doesn't make any sense.

  Please explain.

  Cheers,
  Dean

  On Apr 14, 1:15 am, Taylor Singletary taylorsinglet...@twitter.com
  wrote:
   Basic auto being turned off means just that..

   Desktop clients can implement xAuth as an alternative, where you do a
   one-time exchange of login and password for an OAuth access token and
   continue from there signing your requests and doing things in the
   OAuth way. You'd no longer, as a best practice and one that I would
   stress in the upmost even on a desktop client, store the login and
   password beyond the xAuth access token negotiation step. If the token
   were revoked you would then query for the login and password again and
   so on and so on and also and also.

   Obtaining permission to use xAuth for desktop clients is as easy as
   sending a well-identified and verbose note to a...@twitter.com.

   Basic auth had a good run. It's nearly time to say goodnight.

   Taylor

   On Tuesday, April 13, 2010, Dean Collins d...@cognation.net wrote:
Just so I understand this, applications running on the desktop will
  still work correct? Basic functionality is only being turned off for web
  apps correct? It's not like desktop apps will have to start using oauth.

Cheers,

Dean

-Original Message-
From: twitter-development-talk@googlegroups.com [mailto:
  twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius
Sent: Tuesday, April 13, 2010 7:31 PM
To: Twitter Development Talk
Subject: [twitter-dev] Re: Basic Auth Deprecation

Could you please announce the hard turn off date somewhere on one of
your Twitter blogs about a month ahead of time, so that we all have an
official source to point our users to when we explain to them why
we're converting everything over to OAuth?

On Apr 13, 8:19 pm, Raffi Krikorian ra...@twitter.com wrote:
we have announced deprecation, and will hard turn off basic
  authentication
in june.  the exact date has not been set, but i presume it will be
  later in
the month.

Is Basic Auth going to be deprecated (as in hard switched-off) in

 June, or are you in June going to announce depracation, with the
  hard
 switch-off then coming a few months later?

--
Raffi Krikorian
Twitter Platform Teamhttp://twitter.com/raffi

--
To unsubscribe, reply using remove me as the subject.

   --
   Taylor Singletary
   Developer Advocate, Twitterhttp://twitter.com/episod-Hide quoted text -

   - Show quoted text -

 --
 Raffi Krikorian
 Twitter Platform Teamhttp://twitter.com/raffi


[twitter-dev] App user counts missing from http://dev.twitter.com/apps

2010-04-14 Thread Jaanus
Hey Twitter team -

http://dev.twitter.com/apps is missing user counts that twitter.com/
oauth was showing. Please put them back there, I would assume this is
a temporary oversight. And add even more data! :) (like, users in last
7 days or so, in addition to total.)


J


-- 
To unsubscribe, reply using remove me as the subject.


[twitter-dev] Re: What happened, happened.

2010-04-09 Thread Jaanus
 Interesting thought: Twitter is the *only* major API I'm aware of that
 does *not* require a per-user or per-company API key. Sure, there's the
 oAuth *application* keys, but there's no API key that tells Twitter
 this activity is coming from Ed Borasky, regardless of IP address or
 account or application. It would make my life as a developer simpler if
 a user of applications I create had to have an API key from Twitter to
 use them. Would it complicate Twitter's life substantially to do that?

Yeah, this doesn't really make any sense. Users already sign in to
OAuth apps and if they then use the apps, Twitter can tell what user
and app the traffic is coming from. So what is your need/point?


J


-- 
To unsubscribe, reply using remove me as the subject.


[twitter-dev] Re: Search API Changes: Popular Tweets vs. Recency

2010-04-07 Thread Jaanus
Thanks, good feedback.

Yep, it is always preferable to be explicit about specifying the
intent. API versioning and explicit options are both good ways of
doing that. The kerfuffle around the popular searches being injected
happened exactly because there was previously no way to specify
intent. Thus, there was an implicit intent in the search API behavior
that the developers came to trust. Now we feel as if a rug is somewhat
being pulled from under us.

To be fair, though, if popular tweets being included by default BREAKS
anybody's app in the technical sense, then maybe it's time to look in
the mirror or your code. My app won't be affected by it and will
continue to operate just fine. If I want, I could just add extra value
to my users by presenting the popular search somehow differently, but
if not, it continues to be just a bunch of results, all the same. Be
liberal in what you accept (http://en.wikipedia.org/wiki/
Robustness_principle) is a good rule to follow with Twitter API as
with any external data.


J


-- 
To unsubscribe, reply using remove me as the subject.


[twitter-dev] Re: Opt-in beta of Popular Tweets for the Search API now available

2010-04-06 Thread Jaanus
My oh my, what discussion about advocacy and what not. I think Taylor,
Raffi and everybody else from Twitter are doing a great job here and
everyone is eager to learn and they know they have ways to go. Let's
not get mean.

I'm with those who say injecting popular searches into the search API
results by Twitter still doesn't entirely make sense, given the way
the rollout/communication is handled. Here is the problem/conversation
in a nutshell:

Twitter: We are going to inject popular search results into the
search API results, changing previous behavior that just returned
recent results.
Developers: Wait a sec, this is a bad idea because of A, B and C.
Maybe you can version the API better or some such.
... time passes, nothing happens ...
Twitter: Hi, we're starting to roll this out now.

I don't particularly care for the popular results either way and I
trust Twitter that it is good for users in the grand scheme of things,
but the API behavior change is disturbing. It would be great to work
against a fixed API target so that those who want search to work in a
particular way can just work against a given API version, but with
search, this is not an option, you only have one endpoint that's in
this kind of flux.

What I'm saying is Twitter as a company could just earn more developer
street cred and respect here by handling this in a more graceful way.
There comes a point in time where the moving parts argument as an
excuse to not follow good API practices gets somewhat old.


rgds,
Jaanus


-- 
To unsubscribe, reply using remove me as the subject.


[twitter-dev] Re: SSL problems using ASI!

2010-03-27 Thread Jaanus
I am using ASIHTTPRequest and SSL and never saw any cert errors.

On Mar 26, 5:24 pm, c0olcast c0olc...@gmail.com wrote:
 Hey everyone, Got a few questions here.

 We are currently developing a twitter client and we are using
 ASIHTTPRequest to access twitter. We want to use SSL for our requests.
 It works most of the times but some times we get SSL cert errors. I
 read post saying that there were some servers that had their certs
 setup wrong, is this is true, or should I start looking into something
 different.

To unsubscribe from this group, send email to 
twitter-development-talk+unsubscribegooglegroups.com or reply to this email 
with the words REMOVE ME as the subject.


[twitter-dev] Re: Follow #topics

2010-03-23 Thread Jaanus
I built http://cremeapp.com to showcase what this (following a
search term or any #hashtag) might be like in a mobile UI. Twitter.com
and other apps support saved searches, but IMO they don't push it far
enough.

On Mar 23, 8:27 am, sem evers sem_...@hotmail.com wrote:
 Dear reader,

 Is it possible to follow #topics, like how many tweets contain
 #twitter for example and who tweeted the tweet containing #twitter?
 Sorry for my english

 Kind Regards,
 Sem Evers

To unsubscribe from this group, send email to 
twitter-development-talk+unsubscribegooglegroups.com or reply to this email 
with the words REMOVE ME as the subject.


[twitter-dev] OAuth Echo progress, next steps?

2010-03-22 Thread Jaanus
How is OAuth Echo going? What are the next steps? I would really like
to start posting pictures from @cremeapp to all sorts of places, and
also build my own serverside stuff, but it's all pending on Twitter's
next steps.

I guess there will be more news at Chirp but I won't be there and it's
still weeks away, so... nudge ;)


rgds,
Jaanus

To unsubscribe from this group, send email to 
twitter-development-talk+unsubscribegooglegroups.com or reply to this email 
with the words REMOVE ME as the subject.


[twitter-dev] Re: Skip the Return Values page after sending a tweet?

2010-03-20 Thread Jaanus
Sounds like you are just redirecting your users to the Twitter API URL
in their browser, and they are seeing the API response. This is not
right. You should use some Twitter API library to send the API request
and receive the response within your application, and then display
some feedback to your users yourself, depending on what result you got
from the API.

On Mar 20, 11:05 pm, T tstrickland...@gmail.com wrote:
 Forgive me if this isn't the right place to post, but I can't seem to
 find any answers to my question and i'm still pretty new to this.
 After integrating Twitter into my website, whenever i publish a tweet
 (from my website) i get sent to a page with return values. The tweet
 gets sent fine, but I dont want my users to see the return values. How
 do I send them to a page of my choice (i.e. index page or a
 confirmation page) after they send a tweet, instead of them seeing the
 return values?

To unsubscribe from this group, send email to 
twitter-development-talk+unsubscribegooglegroups.com or reply to this email 
with the words REMOVE ME as the subject.


[twitter-dev] Re: Most popular tweets in the search API

2010-03-19 Thread Jaanus
+1 to Cameron and funkatron. Making this default, even with a
transition period, would be extremely bad practice. The whole point of
API versioning is such that old stuff does not break. And yes,
changing behavior so that results returned to same query are suddenly
different is definitely breaking.

I find popular tweets in search results mixed with recents to be a
great idea, but it cannot be the default, since it would break many
apps that have relied on current behavior. And having whatever
transition period is not good enough. You are forcing developers to
change priorities and re-test old stuff, some of which may be
unmaintained legacy.

API versioning and backwards compatibility are standard industry
practices, just please stick to those and don't piss off developers
any further. (I could insert a more elaborate rant here to show what I
really feel, but the above captures the point.)


rgds,
Jaanus


On Mar 19, 3:29 pm, Cameron Kaiser spec...@floodgap.com wrote:
  Your definition of time to adjust may not be ours. Twitter has, to
  be honest, a fairly crappy reputation for changing API behavior. While
  some of that was surely driven by performance concerns, I don't see
  how this could be. This doesn't help the rep.

  Please, do not enable this by default, *ever*. Don't change behavior
  unless it is necessary. Add a new API method, or make recent results
  the default and keep it that way.

  If you're advocating for developers, advocate for making us do less
  work to maintain current functionality, please.

 This is spot on. It's not that I think the idea itself is bad -- I'm all
 for more relevant search results *when relevance is what's requested*. Right
 now, every app that queries the Search API expects time-oriented results
 because that's what we got before. Making this the new default is needless
 dev chaos, *and* I haven't heard if there is even a way to opt back to the
 old behaviour if this becomes the ill-advised default anyway.

 I'd love to support this feature, in the appropriate context, when it makes
 sense to do so. I don't want to have to code around it as the new,
 unsolicited default when it doesn't.

 --
  personal:http://www.cameronkaiser.com/--
   Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com
 -- FORTUNE: Good day for romance, but try a single person this time. 
 --

To unsubscribe from this group, send email to 
twitter-development-talk+unsubscribegooglegroups.com or reply to this email 
with the words REMOVE ME as the subject.


[twitter-dev] Are tweet ID-s in search and rest API-s the same?

2010-03-08 Thread Jaanus
http://apiwiki.twitter.com/Twitter-Search-API-Method:-search says:

Warning: The user ids in the Search API are different from those in
the REST API (about the two APIs). This defect is being tracked by
Issue 214. This means that the to_user_id and from_user_id field vary
from the actualy user id on Twitter.com.

How about tweet ID-s? The search API returns tweet ID in the id
field of the response object. Can I trust the search and REST API
tweet ID-s to be the same?


rgds,
Jaanus


[twitter-dev] Re: Follow me on Twitter

2010-03-05 Thread Jaanus
There are many ways, though, to implement the OAuth interface to sign
in the user. Many sites (see getsatisfaction.com for an example) do it
with a popup instead of a full page reload. This means that the main
page stays whatever it is, and the Twitter stuff appears just in a
small popup.


rgds,
Jaanus


On Mar 5, 6:30 pm, AlexBeck alexbeck...@gmail.com wrote:
 Thanks all,

 this is what i feared.
 On Mar 3, 3:34 pm, Jaanus jaa...@gmail.com wrote:



  Twitter API lets youfollowand unfollow people. But, the user needs
  to login, and these days the fancy way to do login is through OAuth,
  which means a trip to twitter.com anyway.

  On Mar 2, 9:58 pm, AlexBeck alexbeck...@gmail.com wrote:

   I am creating a project for a rather large client, and have run into a
   twitter api question.  The client wants to create a followmeon
   twitter bug on the page, but they do not want to land on any page
   that is a twitter.com address?

   is it possible to create an experience in a browser where someone can
   choose tofollowanother twitter user without every going to the
   twitter site?

   thanks
   alex


[twitter-dev] Re: What is the correct OAuth API endpoint

2010-03-04 Thread Jaanus
Is there a reason why the OAuth URL in the api wiki could not be HTTPS
by default? Why would you want to recommend HTTP over HTTPS? (I know
that OAuth was designed to be safe over HTTP, immune against man-in-
the-middle and all, but HTTPS just gives me a warm and fuzzy feel. ;)


rgds,
Jaanus


On Mar 4, 10:18 am, Thomas Woolway tswool...@gmail.com wrote:
 It's good to know that this is the recommended URI root for OAuth. Any
 chance of getting the docs 
 (http://apiwiki.twitter.com/Twitter-REST-API-Method:-oauth-access_tokenetc)
 updated to help out newcomers? Also, it might be worth adding a big NB that
 those resources aren't versioned - it's one of those things that is quite
 easy to miss.

 Cheers,

 Tom



 On Wed, Mar 3, 2010 at 3:26 PM, Scott Wilcox sc...@tig.gr wrote:
  Zhami,

  I'd go withhttps://api.twitter.com/1

  Scott.

  On 3 Mar 2010, at 15:02, Zhami wrote:

   What is the correct API end-point for OAuth authenticated,
   *documented* API calls?

   http(s)://twitter.com

   http(s)://api.twitter.com

   http(s)://api.twitter.com/1


[twitter-dev] Re: What is the correct OAuth API endpoint

2010-03-04 Thread Jaanus
The one other thing you might want to do is to update the interface on
http://twitter.com/oauth, which is where you configure your OAuth
apps. This returns you the URLs to use, which are now different from
what the wiki says. twitter.com/oauth should also return the correct
updated urls.


On Mar 4, 11:27 am, Taylor Singletary taylorsinglet...@twitter.com
wrote:
 The OAuth steps in the apiwiki have been updated to reflect the preferred
 subdomain of api as well as a note about the URLs not being versioned yet.

 Thanks,
 Taylor



 On Thu, Mar 4, 2010 at 7:18 AM, Thomas Woolway tswool...@gmail.com wrote:
  It's good to know that this is the recommended URI root for OAuth. Any
  chance of getting the docs (
 http://apiwiki.twitter.com/Twitter-REST-API-Method:-oauth-access_tokenetc)
  updated to help out newcomers? Also, it might be worth adding a big NB that
  those resources aren't versioned - it's one of those things that is quite
  easy to miss.

  Cheers,

  Tom

  On Wed, Mar 3, 2010 at 3:26 PM, Scott Wilcox sc...@tig.gr wrote:

  Zhami,

  I'd go withhttps://api.twitter.com/1

  Scott.

  On 3 Mar 2010, at 15:02, Zhami wrote:

   What is the correct API end-point for OAuth authenticated,
   *documented* API calls?

   http(s)://twitter.com

   http(s)://api.twitter.com

   http(s)://api.twitter.com/1


[twitter-dev] Re: Follow me on Twitter

2010-03-03 Thread Jaanus
Twitter API lets you follow and unfollow people. But, the user needs
to login, and these days the fancy way to do login is through OAuth,
which means a trip to twitter.com anyway.

On Mar 2, 9:58 pm, AlexBeck alexbeck...@gmail.com wrote:
 I am creating a project for a rather large client, and have run into a
 twitter api question.  The client wants to create a follow me on
 twitter bug on the page, but they do not want to land on any page
 that is a twitter.com address?

 is it possible to create an experience in a browser where someone can
 choose to follow another twitter user without every going to the
 twitter site?

 thanks
 alex


[twitter-dev] Re: Introduce yourself!

2010-03-03 Thread Jaanus
Hi,

I’m Jaanus. My day job has nothing to do with Twitter, but a few
months back, I started looking into Twitter and iPhone more closely
out of personal interest as a hobby project. I wrote down how OAuth
works [1] and made a simple Objective-C implementation [2].

Just now, I released a new iPhone Twitter app, Crème. It just hit the
App Store, get it from http://cremeapp.com. As far as I’m aware, it’s
one of the first general-purpose Twitter clients on the App Store that
uses OAuth for authentication, I haven’t come across others. I use my
own PlainOAuth. I think this app breaks some new ground in terms of
how to interact with Twitter, I’d be interested in all the feedback.

One thing that nobody seems to talk about is read/unread management,
which I think about a lot. I’m not sure that it belongs in the API,
perhaps at this stage it is better left to clients, but I think all
the current clients and also the twitter.com site do a terrible job at
it, so I propose a better way with Crème. This is still local to one
device, but I do believe that there is potential in syncing reads/
unreads across devices. Until Twitter puts it in their API (if ever),
I'll probably be forced to do my own solution. Looking forward to
OAuth Echo to do the authentication part of it (e.g if I maintain my
own unread server, I'd use OAuth Echo to make sure the reads/unreads
of different users are separated and everyone only sees their own.)

Twitter API was straightforward to work with, don’t really have any
major gripes. There’s a bunch of inconstencies (e.g I can get my own
mentions, but not others’), and one thing that is not advertised well
is the HTML encoding/decoding (a bunch of fields are HTML-encoded and
you need to remember to decode them on client side before
displaying... I think this applies only to JSON, which I’m also
using).

My only “holy crap” moment with Twitter API was when I came across the
REST and search user IDs are different bug (http://code.google.com/p/
twitter-api/issues/detail?id=214). That this has not been fixed after
all this time, leaves an amateur and shenaniganish taste of the whole
Twitter API operation. Fixing it does not get easier with time as
increasingly more data is generated, you know... but, on the client
side I do not need to do global matching for any users, I could work
around it by simply using screen names throughout the app, so for my
particular case it was not a showstopper, but it leaves a bad taste.

One other thing I didn't find much info about is how Twitter works
with profile images. As users upload them, multiple versions are
generated, and you have to truncate and replace parts of filename to
get the different versions, but I came across it as hearsay, I don't
think it's documented.

So, check out cremeapp.com :)

[1] http://www.jaanuskase.com/en/2010/01/understanding_the_guts_of_twit.html
[2] http://www.jaanuskase.com/en/2010/01/an_example_iphone_twitter_app.html


rgds,
Jaanus
@jaanus
http://www.jaanuskase.com/


On Feb 19, 3:20 pm, Abraham Williams 4bra...@gmail.com wrote:
 We have not had an introductions thread in a long time (or ever that I could
 find) so I'm starting one. Don't forget to add an answer to the tools thread
 [1](Gmail link [2]) as well.

 I'm Abraham Williams, I've been working with the Twitter API and this group
 since early 2008. I do mostly freelance Drupal and Twitter API integration
 and personal projects. I love seeing the creative projects developers build
 or integrate with the API and look forward to meeting many of you at Chirp.

 TwitterOAuth [3] the first PHP library to support OAuth is built and
 maintained by me, and will hopefully see a new release soon. I also built a
 fun Chrome extension [4] that integrates common friends and followers into
 Twitter profiles.

 The feature I would most like added to the API is a conversation method to
 get replies to a specific status.

 So. Who are you, what do you do, what have you built, and what feature do
 you most want to see added?

 @Abraham

 [1]http://groups.google.com/group/twitter-development-talk/browse_thread...
 [2]https://mail.google.com/mail/#inbox/12680cd0fa59011e
 [3]https://chrome.google.com/extensions/detail/npdjhmblakdjfnnajeomfbogo...
 [4]http://code.google.com/p/twitter-api/issues/detail?id=142

 --
 Abraham Williams | Community Advocate |http://abrah.am
 Project | Out Loud |http://outloud.labs.poseurtech.com
 This email is: [ ] shareable [x] ask first [ ] private.
 Sent from Seattle, WA, United States


[twitter-dev] Re: @twitterapi meetup @ Twitter HQ

2010-02-27 Thread Jaanus
On Feb 27, 1:00 am, Orian Marx (@orian) or...@orianmarx.com wrote:
 If TwitterHQ isn't opposed I'm sure there's someone who'd be willing
 to stream the event...

... recording would be cool too. and probably less hassle to do than
streaming.


rgds,
Jaanus


[twitter-dev] Re: oauth request token failing

2010-02-21 Thread Jaanus
  You order all parameters EXCEPT the signature, then create the signature,
  then append the signature to the end.  All other parameters should be in
  order.
 I am under the impression that sorting is only required to generate
 the Signature Base String. I haven't seen anything in the OAuth spec
 to suggest that Query parameters must be ordered. If I have missed
 something, lease let me know where. I also believe that ordering is
 *not* required in the Authorization header because the example shown
 in the spec is not ordered [1]

Yep, that's my understanding too. Signature base string sorting is
strict. For the Authorization header, neither sender nor receiver
should assume any sorting, it's an unsorted key/value map.


[twitter-dev] http://search.twitter.com/operators/ not loading in UIWebView on iPhone

2010-02-06 Thread Jaanus
Not sure whose bug is it, but I am having trouble loading
http://search.twitter.com/operators/ in UIWebView on iPhone. The
problem is not specific to my app—you can see this bug also with the
official UICatalog example.

The problem is specific to search.twitter.com/operators/ and
UIWebView. The link loads fine in iPhone Safari, and http://search.twitter.com/
and other Twitter links load fine in UIWebView. But, to provide inline
help for search, it would be handy to load this in UIWebView too.

I didn't have time to investigate if the bug is on server or client
side. My hunch is that Twitter may not handle the user-agent of
UIWebView correctly, but this is just a random guess, would need to
investigate more.


rgds,
Jaanus


[twitter-dev] statuses/mentions for other users?

2010-02-03 Thread Jaanus
http://apiwiki.twitter.com/Twitter-REST-API-Method:-statuses-mentions:

Returns the 20 most recent mentions (status containing @username) for
the authenticating user.

Is it possible to get this info for any other user than the
authenticating one? I was expecting to be able to give this method
user_id like to statuses/user_timeline and was surprised I can't do
that.

How should I get @replies to other people? Should I just do a search?


[twitter-dev] Re: API Limit of 150 is Obsolete

2010-01-20 Thread Jaanus
On top of all that, AFAIK the 1500 limit for OAuth is still vaporware
at this point, so everybody is capped at 150.

To inform the discussion, I wonder if Twitter could share any figures
like what's the actual API use distribution? Like what combination of
users/apps hit the cap regularly and cause massive load? If it was an
equal distribution (i.e most users/apps are around the same level)
that gives them heavy load, then I would see why they need to be
careful about raising limits (any increase would bring more fail
whales). But I suspect that it's highly asymmetrical... i.e there are
very few users/apps who actually cause any meaningful load.

Another hunch: desktop apps are negligible and the real load comes
from web apps who spider asynchronously 24/7. Should the load be
differentiated across client and web apps? Client apps are typically
only one user per device at a time, whereas the web app may be
spidering on behalf of who knows how many people.


On Jan 20, 5:48 pm, Eric Woodward e...@nambu.com wrote:
 I will come straight to the point: we need to an increase to the API
 limit to properly implement Twitter within a desktop client
 application given the addition of: 1) three retweets timelines; 2)
 checking the account's saved searches; and 3) up to 10-20 Twitter
 Lists timelines.

 Twitter Lists alone are causing real problems if a user follows more
 than 5 or so. We cant poll Twitter List subscriptions with one API
 call that combines them altogether, which we could then split apart
 client-side with some attached meta-data. That alone would have been a
 big help, and without it we are left polling each List as if it was a
 separate timeline, since that is what they are.

 Implementing proper Lists management is a non-starter within this
 limit, so is regular confirmation of a relationship between two users
 when asked for by the user (on Lists or search results). There is
 simply a lot of stuff I cannot do properly that is standard on
 twitter.com, all because I am subject to the API limit while
 twitter.com is not. Users simply do not understand this distinction in
 possibilities.

 I would like to formally ask on behalf of all client developers that
 the API limit increase to 250, from 150, for all applications whether
 they use OAuth or HTTP Basic Authentication. We are simply not able to
 implement Twitter properly within a limit of 150, but dont need a lot
 more, only another 100-200 API calls or so.

 If Twitter can even technically contemplate a 10x API limit increase
 to 1,500 for OAuth applications, surely an increase to 250 based on
 the addition of core features like official retweets and Lists is a
 reasonable request. A limit of 150 is simply obsolete, and has been
 for a long time.

 I do not want to wait for the UX repairs around OAuth for desktop
 applications, and I dont like being forced into OAuth sooner than we
 are ready just because we need the extra API hits just to do basic
 features properly. And besides, that was announced as two weeks away
 three weeks ago. I dont want to wait any longer. I want to properly
 implement the basics, like Lists polling, now.

 This is a considered email because I care about the quality of our
 Twitter implementation and I care about the Twitter ecosystem. I would
 appreciate a considered reply.

 --ejw

 Eric Woodward
 Email: e...@nambu.com


[twitter-dev] Re: OAuth workflow and verify_credentials (http://twitter.com/account/verify_credentials)

2010-01-19 Thread Jaanus
You don't actually _need_ to call it after obtaining the access token.
It does not _do_ anything, it simply returns a yes/no type of answer
to you (200 OK if the credentials are valid, 401 Unauthorized if not).
When you manage to obtain the access token, it implies that the
credentials are already verified. But it does not hurt anything to
call it, so you can call it if you really want to be extra sure.

The verify_credentials simply lets you check whether some previously
issued access token is still valid or not. For example, if the user
deauthorizes your app, you can detect this with verify_credentials...
but at the same time, all other API calls would also start to respond
with 401 Unauthorized.


rgds,
Jaanus


On Jan 19, 8:27 pm, eco_bach bac...@gmail.com wrote:
 Thanks Abraham!
 In that case I will call it automatically after obtaining the access
 token.


[twitter-dev] Guide to understanding how to work with Twitter and OAuth

2010-01-17 Thread Jaanus
Hey -

I'm hoping to save someone time with this as I was looking for a
similar guide myself when learning about OAuth and didn't find any. So
I just put together a walkthrough of the OAuth sequence. Maybe this
will be helpful to someone.

http://www.jaanuskase.com/en/2010/01/understanding_the_guts_of_twit.html


rgds,
Jaanus