Re: [twitter-dev] TweetDeck joins Twitter
Then why don't developers do something? http://bit.ly/lpiADG On Wednesday, May 25, 2011 at 10:57 AM, TJ Luoma wrote: On Wed, May 25, 2011 at 11:34 AM, Matt Harris thematthar...@twitter.com wrote: When Tweetie became part of the Twitter family the user growth was huge, creating more opportunities for developers to build applications for the growing audience. Except for developers who had developed, you know, Twitter clients. Because Twitter is committed to buying the biggest ones and making them available for free, to drive you out of business. Other than that, it was a great opportunity for developers! TjL ps - just to make it clear: of course Twitter, Inc. has the freedom to do whatever they want, it's their sandbox. Just don't tell me that's rain on my leg. It's insulting at best, and dishonest at worst. -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
[twitter-dev] Fallback Permissions Level
Is anyone working on a choice-based or fallback permissions schema to give users a choice which permission level they authorize? -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] Twitter API for iPhone Application
What are your constraints, coding language, etc.? What do you want to do with the API? On Tuesday, May 24, 2011 at 8:50 AM, Davinder Singh wrote: Requesting help to find a suitable API to integrate with my Twitter account. Thanks in advance! -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
[twitter-dev] Permissions Level Changes
I thought this might interest many of you. It was written with the intent of explaining the development issues in language our end users can understand. http://www.mediabistro.com/alltwitter/how-private-are-your-private-messages_b9078 We are all worried of how big of a PR fiasco this could be to make our customers understand what and why things are happening. I believe education and transparency our are best options at this time. -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] Re: A new permission level
In any security or permissions context the default should be the most secure and least amount of permissions to get the job done. That is Computer and Network Security 101. A user must explicitly configure more loose permissions on their own after understanding the implications. This is the way computer network security is and always has been done. This is part of the reason Linux/Unix et al is way more secure than Windows ever could be. Just because a user isn't sophisticated enough to configure more lax permissions to get their needs met isn't a reason to default to lower the security context. This is what FB did _completely_ wrong when they updated their permissions system. They defaulted everything to being completely open, accessible and public for purely selfish reasons. They wanted to keep more user data 100% public thus increasing the amount of public and free (as in $ to FB) user-generated content created every day. More pageviews, more pics, more comments equals more ad revenue for them. Even though it's a pain in the ass for developer's to rework their apps and re-auth it's the right thing to do for the end user and the overall safety of the community. I commend Twitter for doing the right (even if unpopular) thing in this case. Damon On Thursday, May 19, 2011 at 1:50 AM, janole wrote: Hi Matt, thanks for your feedback. I think the following paragraph can't be generalized, though: Why will you not grandfather existing applications into DM access? Grandfathering all existing read/write tokens assumes they all wanted access to DMs. The feedback we’ve had from users and developers tells us otherwise. We want to give users the opportunity to make an informed choice. -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] Re: A new permission level
Janole None, taken. I am a network sysadmin, developer and ultimately businessman so I do know a little bit about how they are all related. I understand you are in a slightly different position having to deal with xAuth. However, xAuth is not a secure system in itself. Any system that passes a user and password through a third party cannot be secure. Yes you are supposed to discard the info after the initial tokens are exchanged and received back, but there is no proof that actually happens. A third party still had access to my username and password. From a purely network and security standpoint xAuth should be done away with in lieu of newer more secure methods where no one other than myself and the service I am accessing know my password. For that matter, the service shouldn't know my password either beyond when I submit it as it should be hashed and that token saved instead of the raw password. Authentication then involves comparing two hashes instead of two raw text passwords. In your case you are limited by the the underlying OS from achieving a traditional OAuth flow. Your work around sounds like it will suffice and is no less potentially insecure than the existing if properly setup. You say you know nothing about your users under the current system, and that's the way it should be. But that is you in your specific case, being I'm sure an honest developer. Allowing insecure methods to continue though, lowers the security of the whole. It only takes one bad app to screw a bunch of users and ultimately it's Twitter who would have the proverbial egg on the face. The app developer would be banned and forgotten. I'm not happy about this change being forced down everyone's throat so quickly as much as the next developer. In my option more levels of privacy and security should have been rolled out all at once instead of this one change. This change fixes one minor problem when a more broad change to add finer-grained permissions could have been rolled out and affected third-party developers not much more than this current one. I also suspect as you hinted there may be other more selfish reasons partly behind such changes and have written several articles about the subject. http://bit.ly/lFZuZC But as I said... from a purely network and security standpoint the changes are sound. Economics and competition may be a different story. damonp On Thursday, May 19, 2011 at 11:14 AM, janole wrote: Damon, with all due respect and in all politeness, have you even read what this thread is about? Do you really think an xAuth application - that knows the users full credentials - is getting more secure without the right to access direct messages? I mean ... really ;-) We both do not know why Twitter tries to introduce this change. I have a feeling what it is about, but it's definitely not about user privacy or security if it comes to xAuth applications. OAuth apps, granted, different story and I could live with that change. But as I am not using OAuth, I leave it to the developers affected to voice their concerns. They should know better. For me, who needs to have xAuth access to provide my users access to Twitter - actually to provide it to the Symbian platform ( biggest smartphone OS worldwide, 2010 ... ) - these changes are not good. And my users do think the same. Most of my users love Twitter and I try to provide a client that makes them use Twitter a lot - because I love Twitter, too ( well, better to say, I am addicted to Twitter. ) I just don't see any reason why this privacy related change couldn't be implemented in a way which does NOT break so many applications. We are also talking about preloaded mobile apps here - apps that cannot be changed quickly - or cannot be changed at all. My planned work-around for this xAuth change ( I still hope it is being reverted! ) will include running a Twitter service for authentication. That way, I would have access to my users' OAuth tokens. I don't like that. It imposes a great risk to me and my servers being hacked. So far, I do not know nothing about my users via my Twitter client. No password, no credentials. I like it that way. More secure for my users. As for Linux, yes, we all know Linux is way more secure. That's why companies like Sony and Gawker are running their services on top of Linux servers ... okay, forget about that one ;-) Cheers please don't feel offended, Ole ( @janole / @gravityapp ) On May 19, 2:44 pm, Damon Parker cartmet...@gmail.com wrote: In any security or permissions context the default should be the most secure and least amount of permissions to get the job done. That is Computer and Network Security 101. A user must explicitly configure more loose permissions on their own after understanding the implications. This is the way computer network security is and always has been done. This is part of the reason Linux/Unix et al
Re: [twitter-dev] Re: A new permission level
It will be interesting to see where the PR nightmare falls more squarely on when it happens... Twitter or the app developers themselves. We will get the tech support nightmare but if recent history is any indication (ie. Ubertwitter ban) many users are going to ultimately blame Twitter. -- damonp On Thursday, May 19, 2011 at 12:25 PM, Ron wrote: Millions of mobile Twitter users are going to get really ticked off when they can no longer use their favorite apps. So let's be honest. When it comes to Twitter mobile clients, this isn't about user security. It's about pruning client competition from the market. -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] Re: A new permission level
Ole- You make some very good points, but you can't use the tired users create poor passwords argument as a reason to stick with outdated security protocols. By that logic, no security upgrade is worth the time because some dumb users are going to foil you every time. If a user wants to chose a poor password and share it across all accounts, that's his business. You will never be able to stop that in a consumer situation such as this (ie. you have a lot of inexperienced users who could go elsewhere). On closed networks, you can disallow simple passwords and force password changes every few months. That's why professionals like you and I exist. We enforce state of the art and create systems as secure as we can given the constraints of the architecture (which your workaround is attempting to do). Many users will take advantage of all of the enhanced security and many won't. But everyone had a choice to educate themselves and use the most secure method they chose. Disclosing the fact that you could have had access to your user's accounts involves your customer's perception, not the reality. You did, in fact have access to their accounts. You may have taken care to secure and/or discard the data but not every developer is as conscientious or as honest as I'm sure you are. That is PR issue you and a few other developers in similar situation are about to be forced to deal with unfortunately. I feel for you. Apple did similar when they would not allow Flash on iOS. IMO, it was the right thing to do for their platform at the time. Flash sucks processing power and is inherently insecure. You can't have your phone lock up and ring 30 seconds late because some Flash advert or game was pegging out your mobile processor. It's a phone first. Did it also help them in the long run not to help a competitor? Obviously. It also forced developers to learn iOS and code for it specifically, not just make Flash apps based on an aging platform. In trying to get away from xAuth as much as possible, Twitter is obviously trying to take the third party out of the authentication equation and that in itself is a positive step towards a more secure system for Twitter. Does it hurt us developers and cost us money in redevelopment? Obviously. Is it a step towards clearing the slate of a lot of client competition? cheers damonp -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] A new permission level
On that day when your users open up our various clients and see issues with direct messages I suggest you insert your own DMs to your users with succinct descriptions to the root of the problem and links to further info. It looks like there is no way to prevent having to update apps for those that can, but you certainly have the platform and your customer's eyeballs at the exact point of failure to explain. We all know not everyone is going to read the email we are all dreading to send, at least this way we have another method to get the point to them at the exact time they need it. On Thursday, May 19, 2011 at 4:18 PM, Frank Ash wrote: I wish they would just tell the developers to go to hell in a way and let us know they hate us instead of doing these back handed attacks on our apps all the time. This has very very little to do with privacy. Especially for the developer that wants to abuse accounts, this doesn't stop them and serves no real purpose. And putting it to the media as we having access to their DM's is misguided at best. Users now think we are reading their DM's and have access to monitoring their conversations. Which is just crap. This is all about clients having a large control over the twitterverse and the mismanagement of the situation by Twitter execs. Seeing us instead as competitors for the same resource. To disguise this as a security issue is laughable at best and a bit insulting. You have to realize the benefit Twitter is getting to know why they are doing this. It isn't mandatory to break all the client apps to make this change, but its convenient for Twitters current attack scheme on client apps. This will cause mass exodus from 3rd party apps. If you have an app now, you are about to face a wave of pissed off people and bad reviews. There is no way you can realistically avoid this, and they know that. Thats the real meaning for this not because we all wanted it and have been requesting it. No serious Dev would want this. Maybe we want some more security options like Facebook has but we don't want to ruin our relationship with our customers to get it. Twitter should hire some people with sense enough to know how to work with developers. It is no secret that Twitter is at war with the devs, so just tell us yes or no. You want us or you don't. Opening up for developers helped grow Twitter, now they don't need us anymore so they want to weed us out because we control too much of their market again, the same market we all created for them. All this whole thing does is make people weary of client apps with saying we can access their DM's and then a whirlwind of confusion and complaints from our users will guarantee we loose many many users. Think about the normal person that uses tweetdeck. They will load the all, see nothing, and think its broken. If they figure out they need to confirm their info again and accept new permissions, they will be confused and weary as to why they have to do that. There is NO positive outcome for developers or their customers on this. It's a shame that we keep getting slammed with these sneaky back door slaps in the face disguised as some enhancement for users and more laughable, developers. -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] A new permission level
Frank- Correct me if I'm wrong, but the applications won't quit working altogether. You'll get a 403 error when trying to access DMs through the API. Everything else should work as normal. Has there been a better official answer if this affects Twitter's own apps other than this: Will Twitter's own applications also go through the OAuth web flow? We’re taking this step to give more clarity and control to users about the access a third-party application has to their account. The way users interact with Twitter’s clients is not expected to change. Applications who wish to access a user’s DMs will need to update their application permission and incorporate the OAuth web flow if they don’t already. If an application does not need access to DMs it will not need to make any changes. Which doesn't quite answer my question or the one it's supposed to. cheers damonp On Thursday, May 19, 2011 at 4:58 PM, Frank Ash wrote: I'll give an example for people using multiple accounts. From a customer point of view. I have 12 Twitter accounts, and I use 3 separate clients for different things. When this comes out I will have to re-authorize 36 times over these 3 apps alone. And they won't work until I do. If I was a normal user and didnt hear about the change, what am I going to think about this? I can already tell you I don't want to do it, and its gonna take a lot of time just to get these apps working again. That is for a power user though. Now someone like my mom who uses tweetdeck just to follow celebrities, she will have no clue what happened or why its not working and will be weary when tweetdeck asks her to confirm a new permissions scheme and wonder why they want her info again. Just step back and look at it for what it is and how people will react. We all know what's going to happen. -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] A new permission level
Frank-
http://dev.twitter.com/pages/application-permission-model-faq
The way I read the FAQ posted is _only_ apps requiring DM read access will be
affected under the following endpoints:
/1/direct_messages.{format}
/1/direct_messages/sent.{format}
/1/direct_messages/destroy.{format}
/1/direct_messages/show.{format}
These will receive an HTTP 403 with:
{errors:[{code:93,message:This application is not allowed to access or
delete your direct messages}]}
In fact, it explicitly says:
Yes. Read/Write tokens can send direct messages using direct_messages/new.
Which doesn't quite make sense from a security standpoint... but I'm not going
to argue.
Unless this is all PR spin, the only thing that seemed unclear was whether
Twitter's own apps would require re-authorization into the new perms. The only
thing that addresses that was what I posted previously:
Will Twitter's own applications also go through the OAuth web flow?
We’re taking this step to give more clarity and control to users about
the access a third-party application has to their account. The way
users interact with Twitter’s clients is not expected to change.
Applications who wish to access a user’s DMs will need to update their
application permission and incorporate the OAuth web flow if they
don’t already. If an application does not need access to DMs it will
not need to make any changes.
Which says they'll be subject to oAuth web flow... but as I understand it, they
already are. It says nothing about the re-auth steps for the own apps.
Maybe someone from Twitter will provide a more clear response regarding re-auth
of their own apps instead of an ambiguous answer. This could defuse some
developer concern and conspiracy theory conjecture.
Damon
On Thursday, May 19, 2011 at 5:22 PM, Frank Ash wrote:
Cartmetrix, We don't know for sure what will happen. That's kinda the
problem. My guess is we all prepare now by making our app request rwdm
access, then when the switch takes effect any token that has been changed
with this update will then need to be reauthorized. Not effecting us now, but
when that change takes hold, I imagine all our tokens will be basically
unauthorized because its an all new permission request, thus forcing each
user to accept the new authorizations before they can use the app to
communicate with the Api. Also I spoke unclear earlier about all apps
failing. It will only be ones that use DM as a feature. Which is basically
any client app. I just assume everyone here is effected by the DM permission
change in some way, so I say all our apps. But little Twitter apps that just
read and write won't be effected at all. Because Twitter isn't afraid of
them, just client apps.
Also there is no way Twitter will make themselves do the same thing. Lol that
would be hilarious. They will in no way form or fashion make all their users
go through this process. That would be something I would be fine with. If
they want this change, let them do it also lol. But yeah, there is no way
they would, because they know exactly what would happen.
--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
https://groups.google.com/forum/#!forum/twitter-development-talk
--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] Re: Issue - My twitter account won't load
I doubt it's network related. http://twitter.com/#!/carlagasparian loads a blank page for me too from my location. -- damonp Sent with Sparrow On Monday, May 16, 2011 at 10:40 PM, Mohan Arun wrote: On May 15, 7:50 pm, Carla Gasparian Sartori carlagaspariansart...@gmail.com wrote: I have already tried to load my account @carlagasparian in several computers and in differentes IPs and it won't load since fryday the 13th. The page appears as if it were blank. My computer manged to load my settings, but not my timeline. Could it be because of some proxy from the place you are trying to access twitter? Check with your network administrator. -=Mohan=- -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] How to query for a single status ID?
This is from a PHP app I built using a the the twitter-async class:
$tweet = $twob-get('/statuses/show/'.$tw_id.'.json?include_entities=true');
Whatever language you are using, the url you are looking for is:
'/statuses/show/'.$tw_id.'.json?include_entities=true'
Documentation:
http://dev.twitter.com/doc/get/statuses/show/:id
--
damonp
On Sunday, May 15, 2011 at 8:30 PM, MyGradThesis wrote:
Hello Twitterati!!!
I'm writing a Twitter feed tool to help me complete my grad thesis
(would be happy to share it, this is non-commercial) and the one
problem I have now is how do I get a single, historical status
returned to me in json format? If someone could reply with the get
syntax for getting a single status that would be great. I found a get
command for direct messages, but these are just plain old statuses
that I need, so the direct message get does not work for me (i.e. GET /
1/direct_messages/show/:id.{format} )
And if anyone from Twitter is out there listening, the crazy limit you
put on from: search queries is why I need an individual status get.
Why do so few records get returned with a from: query? Are you folks
worried someone will make a copycat site using from:? This limit is
making it really hard to finish my research. I am comparing all the
tweets from 60 users with the mentions of those tweets in the greater
community. I can search the last few days of cached data just fine for
the mentions (searching on @users) but I get almost nothing back when
I search with from:. The from: results in some cases include only
1 day of data. So I am continually missing out on the original status
message, while I can see everyone's response to the message with no
problem. The from: limit is really painful. Can you help me out? I
would really like to graduate while I am still young. For now I can
manually look up each status I miss, so how do I get the status (in
JSON, I don't want to scrape the author's page, which I guess would be
my fall back approach)
Thanks!
Jim Skinner
Santa Clara University
--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
https://groups.google.com/forum/#!forum/twitter-development-talk
--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] Protect/Unprotect accounts using Twitter API
As an aside to this thread... In regards to changing the status of an account from public to private or vice versa, does this only affect the tweets coming after the change or does it change the whole user's timeline past to present? Similarly if an account was private and is toggled to public, do all of the previously private tweets all of a sudden become public or just those starting after the toggle. Similarly if an account is public and toggled to private. thanks -- damonp On Monday, May 16, 2011 at 3:22 PM, Taylor Singletary wrote: There is no way to set the protected state of a single tweet. Toggling between the two account-level states effects all tweets issued by that author and changing it for the purposes of a single tweet is inadvisable. -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] Re: what happen if auth token inside search api?
So private feeds aren't indexed by Twitter at all and thus are never searchable? -- damonp Sent with Sparrow On Thursday, May 12, 2011 at 8:44 AM, Rich wrote: You can't unless you have already cached their timeline by either being someone following that user or you are authenticated as that user. Even then you have to write the logic to search their timeline. On May 12, 3:09 am, jimmy6 laise...@gmail.com wrote: Then how can i search private twit? On May 12, 2:04 am, Matt Harris thematthar...@twitter.com wrote: Hi Jimmy, The Search API only indexes public Tweets so it doesn't know about Tweets from protected users. Best, @themattharris Developer Advocate, Twitterhttp://twitter.com/themattharris On Wed, May 11, 2011 at 8:29 AM, jimmy6 laise...@gmail.com wrote: If it is the case, how can i get/search private twit? On May 10, 10:23 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: The Search API will ignore any authentication that you send its way -- it doesn't know anything about authentication. @episod http://twitter.com/episod - Taylor Singletary On Tue, May 10, 2011 at 7:13 AM, jimmy6 laise...@gmail.com wrote: What will happen if i pass in authentication token in search api? Does it return different result? Does it return only my twit and friend twit? -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter:https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources:https://dev.twitter.com/doc API updates via Twitter:https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] Re: what happen if auth token inside search api?
Thanks for the response, but didn't quite answer my question. I was asking about indexing mainly and not specifically just the Search API. Twitter doesn't index any private feeds? If they aren't indexed then they will never be searchable... not just not searchable in the current version of the Search API (by users with access to the private feed). -- damonp On Thursday, May 12, 2011 at 9:28 AM, Taylor Singletary wrote: Correct, the Search API's archive represents only publicly issued tweets. @episod - Taylor Singletary On Thu, May 12, 2011 at 7:14 AM, Damon Parker cartmet...@gmail.com wrote: So private feeds aren't indexed by Twitter at all and thus are never searchable? -- damonp Sent with Sparrow On Thursday, May 12, 2011 at 8:44 AM, Rich wrote: You can't unless you have already cached their timeline by either being someone following that user or you are authenticated as that user. Even then you have to write the logic to search their timeline. On May 12, 3:09 am, jimmy6 laise...@gmail.com wrote: Then how can i search private twit? On May 12, 2:04 am, Matt Harris thematthar...@twitter.com wrote: Hi Jimmy, The Search API only indexes public Tweets so it doesn't know about Tweets from protected users. Best, @themattharris Developer Advocate, Twitterhttp://twitter.com/themattharris On Wed, May 11, 2011 at 8:29 AM, jimmy6 laise...@gmail.com wrote: If it is the case, how can i get/search private twit? On May 10, 10:23 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: The Search API will ignore any authentication that you send its way -- it doesn't know anything about authentication. @episod http://twitter.com/episod - Taylor Singletary On Tue, May 10, 2011 at 7:13 AM, jimmy6 laise...@gmail.com wrote: What will happen if i pass in authentication token in search api? Does it return different result? Does it return only my twit and friend twit? -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter:https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources:https://dev.twitter.com/doc API updates via Twitter:https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] App got switched to 'read-only' access, now can't switch back to 'read-write'
Try with a different browser to see if it is caching the old page for some reason. On Wednesday, May 11, 2011 at 2:11 AM, Jason Ling wrote: I edited my app, added a picture and saved, and now it's changed to 'read only' access. I edit again and select 'read write' and save - and it still says 'read only' on the next screen! (application details) I try to create a new app, select 'read write' and save, and it still says 'read only'! Any ideas anyone? -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
