Re: [twitter-dev] Re: A new permission level
Matt Harris said: *>> Why are permissions attached to the user token? >> Permissions are attached to the user token to ensure an application only has the access a user has authorised. * Only because that is the way the system is currently built, but it doesn't have to be that way (see: Facebook). *>> If permissions were not attached to the user token an application would be able to change the level of access they have without the user’s knowledge. * Not if there were no API for it and permission changes must be done by a user inside twitter.com (the logical thing). For additional security, have an opt-in/out email when permission/settings change on a user's account so they are aware of any changes (see: Banking websites). *>> If you tie the permissions to the application each user token would need to be invalidated whenever an application’s permissions are changed. * Yes, and that's only because that is the way the system currently operates, which is a nuisance for both the developer and user. Imagine if every time I changed any of my Facebook permission settings (a common thing), I had to re-authenticate every. single. app. That eventually leads me to leave permissions as wide-open as possible to avoid the annoying task of re-authentication, defeating the purpose of permissions in the first place. I'm not trying to be argumentative. I understand why it was originally built the way it was and I understand why Twitter is adding the new permission. I'm just saying there are improvements that Twitter should consider to prevent these types of problems going forward. This same outcry will happen next time you add a permission setting, and the time after that, etc... Another suggestion, would it hurt to say "Hey, we're thinking about doing X, what do you guys think?" That way we can give you feedback before any firm decisions or deadlines are set. Those types of conversations used to be very common on this list. Twitter has some smart & talented people working for the company, but there are also many smart & talented people on this list that would love to be involved in these types of things before it becomes an issue and it erupts into a 65+ reply email thread with deadline extensions. On Thu, May 19, 2011 at 5:11 PM, TheGuru wrote: > This is where my confusion stemmed from. > > I'm not sure I was aware of the fact there were 2 OAuth login flows, > "web flow" versus "sign in with Twitter". > > As soon as I flipped the boolean in my PHP include for OAuth to set > sign_in_with_twitter = FALSE, so that it would use /authorize instead > of /authenticate (sign in with twitter), I then saw the correct > permissions on the login page. > > I'm not sure this is obvious to many devs (it wasn't to me), that > there was a difference. I just happened to use / assume "sign in with > twitter" was the only web based login available after the > implementation of OAuth. > > What are the implications / reasons for using one method over the > other? They seem to essentially do the same exact thing / accomplish > the same exact goal. > > On May 19, 3:17 pm, themattharris wrote: > > > The permission level for your application can be edited onhttp:// > dev.twitter.com/apps. When the website is busy, it can take a > > little bit longer for changes to your application to be reflected. > > > > > Is using a web view against the Terms of Service (TOS)? > > > > Using an in-app web view to show the OAuth pages is not against our > > TOS. However, we encourage developers to use the built-in browser > > where appropriate. > > > > > You said you were restricting this permission to the OAuth /authorize > web flow only. Will /oauth/authenticate (Sign in with Twitter) support the > new permission? > > > > The R/W/DM permission can only be granted through the /oauth/authorize > > route. Sign in with Twitter cannot be used to grant R/W/DM. > > > > We understand applications may use other methods of authentication > > like Sign in with Twitter as well. For this reason, if a user has > > authorised your application for R/W/DM and you direct them through > > Sign in with Twitter, we will respect the existing access token > > permission. This means you can use Sign in with Twitter after a user > > has authorized your application for R/W/DM. > > > > -- > 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: A new permission level
I agree with Scott. A token should simply be a bond between the user and the app, it should not contain any knowledge of permissions/restrictions. A token simply represents "Hi, I'm making a call on behalf of Joe User. Attached is the request I want to make. Make sure I'm allowed to do this before you execute it." Forcing re-authentication whenever permissions change is a major pain for both developers and users. Removing permission-based tokens benefits the user because they can modify the access an application has without having to re-authenticate, something 99% of users will not understand. On Wed, May 18, 2011 at 11:51 AM, Scott Wilcox wrote: > Hello, > > There have been a lot of opinions voiced about how this is being > implemented. This not only proves troublesome for xAuth clients, but it > lends me to worry about how the future of permissions will evolve. > Effectively now, every single Twitter user needs to get their application > re-authed for the new tokens to provide DM access by the end of the month. > > The Facebook style of using a 'scope' for individual permissions is so much > more viable. I also believe that the API should provide a lookup for the > permissions that a set of credentials currently provides. I honestly believe > that going down the 'scope' route for permissions will be a lot better for > all concerned. When new permissions are introduced to the API in the future, > it would be a small matter of updating the requesting scope for the > application developer, rather than completely rewriting chunks of code. > > I'd like a response from Matt, Taylor or Raffi on this matter and the plans > for future permissions and their implementation. > > On 18 May 2011, at 19:42, Naveen wrote: > > > I had most of the same thoughts already mentioned in this thread so > > wont reiterate everyone, except to add that this seems like a rather > > sudden and disruptive change coming just after #devnestsf where > > Twitter made a point that it was trying to provide better guidance so > > companies that rely on the platform have time to plan and make > > changes. > > > > @knight9 > > > > -- > > 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 > > -- > Scott Wilcox > > @dordotky | sc...@dor.ky | http://dor.ky > +44 (0) 7538 842418 | +1 (646) 827-0580 > > > > -- > 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: consistency and ecosystem opportunities
My 2 cents... The reason for the perceived mixed messages for some of us is because many developers don't, and never have been interested in doing Twitter development as a business. I've created a dozen Twitter clients & apps over the last 5 years, some of which received enough users and press coverage that I could have attempted to turn it into a business, but I didn't. Why? Because it doesn't interest me. I do it for the challenge and the learning experience. So, the things we hear Twitter saying are "Don't build clients anymore" as well as "Client apps make bad business". Well, first, as long as the APIs are active and it's not against the TOS, I'm still going to build, develop, and use my own clients. Second, I don't care that it makes "bad business", that's isn't a concern to me. Third, developers can determine for themselves what seems like a smart business decision or not. Fourth, frankly, Twitter Inc has never been regarded as an expert in monetization strategies. Plus, this is info we already knew. For the most part, building a company whose main product is a Twitter client hasn't been a good business decision for a few years (if ever, outside of a lucky few). But on the other hand, there are still markets where it could be good business. For example, where is the official Twitter client for webOS? Messages like "Don't build clients anymore" and no official Twitter app on webOS does nothing but hurt the ecosystem for thousands of users. If I were a developer for one of the popular webOS clients, I'd be pretty pissed right now. Heck, as a webOS user I'm not thrilled. I'm sure this is applicable to other ecosystems too. The point is, Twitter should be more vocal about what it is going to do as opposed to coy suggestions to developers (which some perceive as threats) about what they shouldn't do. Twitter is going to heavily focus on front-end user experiences across all platforms? Great! Leave it at that. Let developers decide for themselves what are good/bad ideas. Just arm us with the knowledge of your plans, and we'll worry about our own. Finally, Twitter, you should be excited to compete with your developers. Much of the innovation over the years has been a product of the developer & user community. Things like mentions & hashtags came from your users. Features like saved searches, lists, trends, and ajax driven clients were inventions of developers years before they made it into Twitter.com. Essentially, "New" Twitter is just a compilation of the best features from all the 3rd party clients. Do not be hostile. Do not attack them with your TOS. Do not suspend tokens without working with the developer first. Doing these things hurts the community, which in turn hurts you. Your users are your product. Not your platform. Not your website. Not your ads. Your users. - @derek On Mon, Mar 14, 2011 at 10:50 AM, Pizik wrote: > I get the distinct feeling of someone saying something that they do not > really believe in. > > Money makes puppets as ever. > > -- > 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
Re: [twitter-dev] Re: Introduce yourself!
Hi, I'm Derek Gathright, Yahoo engineer by day, Twitter hacker by night. I first started with the platform by creating a web client a few years ago (Tweenky.com, currently suffering from a little neglect) and since went on to create a number of other random apps. After Tweenky's launch, TechCrunch picked it up and the traffic slammed the site, just about killing it. Performance was horrible, so I decided to fix the scaling issue by getting rid of a backend. Wha? How do you do that? I rewrote it in 99% JavaScript (the 1% being a cross-domain proxy). I first started with jQuery, and am now working on another rewrite in YUI3. In the past, it was easy to out-innovate the Twitter.com client, but nowdays it is hard to keep up with only a few hours/week. Slow down guys! :P By doing all this experimentation with Twitter in JS, it's allowed, and inspired me, to learn so much about that language. Knowledge I otherwise probably wouldn't have, and that's what I love about the Twitter platform. It's so flexible and allows me to use it as the basis for tinkering around with any new technology I want. Feel like learning some new language or framework? Create a Twitter app. When the incredibly awesome JSFiddle.net came out, the first thing I did was hack together a YUI3/YQL/Twitter example to play around (http://jsfiddle.net/derek/Vjxt2/). Doing that with Facebook and other platforms would be more difficult than just a few lines of code. Anyways, Cheers http://twitter.com/derek http://derekville.net On Fri, Mar 19, 2010 at 11:19 AM, Quy wrote: > My name is Quy Le (@quytennis) and I used to be a software engineer > but now I'm product manager at a high-tech company. I've been using > the Twitter API for the past 3 months on a Twitter project that > hopefully will go live in a few weeks. I've been using PHP/mySQL/ > memcached to build my site but it has been a slow process since I have > a day job and I'm relearning some of the new technology since I > haven't touched a piece of code in over 8-9 years. (Designing for IE6 > sucks). > > The feature I would love the most is a conversation API so it's easy > to show conversations based on a tweet. > > Quy > > On Feb 19, 1: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 > > 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. > 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: New Twitter feature & API coming soon: Lists
Yay! Lists are a much needed feature and it's great to get some official word out of Twitter that they are coming. The real killer part of this feature is the ability to subscribe to other people's lists, you really hit the nail on the head with that one. The list subscription functionality I've toyed around with in my Tweenky client and most recently implemented at tweetgroups.net. Being able to create a list and allow others to subscribe to it is huge! Along with the saved searches API, the introduction of these features is great because it is one less thing the client devs have to worry about storing & managing ourselves. And face it... interoperability was never going to happen with groups/lists between clients, so this is a great way to give choice back to the users. Boo to silos. On Wed, Sep 30, 2009 at 6:22 PM, dean.j.robinson wrote: > > Nice stuff! > > Glad I didn't spend a heap of time developing my own list/group > solution for Hahlo, instead I can just drop in the API. sweet. > > > > On Oct 1, 9:13 am, Marcel Molina wrote: > > Over on the main Twitter blog @nk has written about a new Lists > > feature we're getting ready to launch: > http://blog.twitter.com/2009/09/soon-to-launch-lists.html. We just > > wanted to let API developers know that we'll be shipping an API for it > > on day one. You'll be able to do things like create lists, add and > > remove users from lists, find out who has been added to a list and > > read the tweet timeline for a given list. > > > > Stay tuned for documentations on the full Lists API soon. > > > > -- > > Marcel Molina > > Twitter Platform Teamhttp://twitter.com/noradio >
[twitter-dev] Re: Continuous oAuth Issues
Oh, nice. I was unable to get into my client over the last few days, but followed the suggestion of clearing your cookies in Safari and it works fine now. Thanks On Sat, Aug 8, 2009 at 2:15 AM, Rich wrote: > > I still can't get mobile safari to oAuth, some people obviously are as > I can see the number of users occassionally go up in the oAuth clients > page > > On Aug 8, 4:08 am, Chris Corriveau wrote: > > Hi Mike what version of FF are you running? I'mable to use 3.5 now, > > but Twitter may have changed something after I was Able to login and > > get my cookie set. > > > > - > > Chris- > > > > On Aug 7, 2009, at 6:21 PM, Mike Lewis wrote: > > > > > > > > > > > > > Genevate, > > > > > Still doesn't work for me in FF > > > > > On Aug 7, 3:15 pm, Genevate wrote: > > >> Firefox oAuth issue seems to be fixed now. Not sure for how long > > >> but I > > >> can actually login. > > > > >> Chris- > > > > >> On Aug 7, 5:29 pm, Rich wrote: > > > > >>> It also doesn't seem to be working properly on Mobile Safari > > >>> either on > > >>> the iPhone > > > > >>> On Aug 7, 10:12 pm, Ryan Sarver wrote: > > > > Brian, > > > > Thanks for letting us know. We will try to dig in on the OAuth > > issues and > > see if we can come up with any solutions. > > > > Best, Ryan > > > > On a side note, we are seeing more issues withFirefoxand very few > > with > > Safari but we are exploring > > > > On Fri, Aug 7, 2009 at 1:40 PM, Brian Knoth > > wrote: > > > Thanks for update Ryan, but I got to tell you, I have not gotten > > > a single > > > oAuth request through from our app since early yesterday morning > > > before the > > > original attack. It's not intermittent, it's really nothing. > > > Now, out app is > > > hosted in EC2, so I'm not sure if that is making a difference > > > with any IP > > > blacklisting. > > > > > Brian > > > > > On Fri, Aug 7, 2009 at 4:37 PM, Ryan Sarver > > > wrote: > > > > >> We are noticing a number of people are experiencing issues with > > >> OAuth. > > >> There is nothing inherently broken with OAuth, instead the > > >> issue is tied to > > >> API calls periodically timing out due to the attack. All calls, > > >> including > > >> unauthenticated calls are experiencing the same problems. > > > > >> We are working to resolve this and all the other API-related > > >> issues and > > >> will keep you informed as we make progress. > > > > >> Best, Ryan > > > > >> On Fri, Aug 7, 2009 at 10:59 AM, AdamHertz > > >> wrote: > > > > >>> Ours recurred this morning, as well. > > > > >>> On Aug 7, 10:49 am, Rich wrote: > > Mine has re-occured... if you're going to force people to use > > oAuth > > from now on, at least get it running again fast! > > > > On Aug 7, 2:22 pm, Brian wrote: > > > > > Our app is still experiencing oAuth denial issues since the > > > DDOS > > > problem yesterday. Has anyone heard any update to this > > > problem? or > > >>> is > > > there some action that app developers need to take to get > > > back in > > > business? > > > > > Thanks, > > > brian >
[twitter-dev] Re: OAuth and twitter.com home authentication strange behavior
Same issue here. The username/password version of my client works, but not the oAuth version. It just times out when redirecting back. It's weird because some of my users can get through, but none of my accounts can. On Thu, Aug 6, 2009 at 5:00 PM, Sam Street wrote: > > My app also dies straight during auth http://twicli.com/auth > > On Aug 6, 10:45 pm, Rich wrote: > > Especially annoying seeing as I've gone totally oAuth now. I don't > > blame Twitter, just the idiots that initiated the DDoS attack > > > > On Aug 6, 10:33 pm, Andreu Pere wrote: > > > > > The same behaviour for my application. When the app wants to start the > oAuth > > > workflow in order to authenticate and login the user, the server > returns a > > > timeout fromhttps://twitter.com/oauth/authenticate?parameters > > > > > On Thu, Aug 6, 2009 at 11:24 PM, Rich wrote: > > > > > > I can't get oAuth to authenticate on any of my clients either. It > > > > works when the client has previously authenticated... but trying to > > > > get a new token it fails when clicking 'Allow' > > > > > > On Aug 6, 7:42 pm, stephane wrote: > > > > > It's probably linked to the current DDOS but the authentication > flow > > > > > shows some strange behavior : > > > > > > > 1 - I try to initiate an OAuth authentication fromwww.twazzup.com > > > > > <- twazzup server gets a timeout trying to connect to twitter for > > > > > oauth token (ApplicationError 5 on appengine) > > > > > 3 - I go to twitter.com click "sign-in" > > > > > <- strangely twitter redirects me to the oauth authorization form > > > > > (do you want to allow twazzup blabla ...) > > > > > > > So I have to questions there : > > > > > A / did you block incoming OAuth reqs from appengine ? > > > > > B/ is the strange behavior (twitter home authentication mixing with > > > > > another OAuth flow) something we, 3rd party app developers, can or > > > > > should take care of ? > > > > > > > Cheers, > > > > > > > Stephanewww.twazzup.com >
[twitter-dev] Re: Send @replies/mentions via SMS?
> > and doesn't use any server-side code Well, let me clarify, uses *very little* server-side code. (before someone corrects me) On Tue, May 12, 2009 at 1:13 PM, Derek Gathright wrote: > Yeah, I'm thinking about using the search API for a "roll my own" "track" >> functionality too. > > > Rebuilding Track is a fun little project. I've done it various ways, but > the problem I always run into is the scalability once I publicize it. Early > versions of my Twitter client (Tweenky) had the ability to track queries and > have them delivered via SMS, email, DM, and XMPP. Having those delivery > options on a per query basis made it very powerful as some things you care > little about, but still wish to track (hourly aggregate by email). Other > things have high priority and I want to be notified right away (via SMS). > > So, if you feel like building your own Track, consider various delivery > methods per query, as well as keeping in mind the scalability if publicly > launching it, cause it's easy to do up until that point. Most of my Twitter > stuff is just private little projects, for that reason. Tweenky ( > new.tweenky.com) being the exception, because now it's all written in > Javascript and doesn't use any server-side code, eliminating the scalability > issue. =) > > Good luck. > > On Tue, May 12, 2009 at 12:53 PM, TjL wrote: > >> >> On Tue, May 12, 2009 at 11:34 AM, Derek Gathright >> wrote: >> > If you (or anyone else) is still looking for something, I have a bot >> that I >> > wrote a while back at twitter.com/dmreply. Just request to follow, >> I'll >> > approve, and then it will automatically forward any @replies to you via >> a >> > DM. Your account has to be public as it uses Twitter Search to retrieve >> the >> > tweets. Simple, requires no authentication info, unfollow at anytime to >> > turn off the service. >> >> That's how I started, but then I realized that people I have blocked >> would be sent, and I have a (very) few followers whose updates are >> protected, and I wouldn't see there. >> >> Of course as soon as I finished this, I realized that what would be >> *better* for my use would actually be email notification of >> 'mentions', so that's what I'm working on now. The nice thing is that >> you're not bound to 140 characters in email, so I can also include >> what the message was in_reply_to (I have a few followers who @reply >> HOURS later and I often have no idea what they are referring to), and >> hopefully even a link to @reply back to them, including a proper >> in_reply_to also. >> >> >> >> > I remembered trying to do it back in the Track days, but tracking @derek >> > failed miserably as it dropped the @ and I instantly got swamped with >> tweets >> > mentioning "derek". >> >> Yeah, I'm thinking about using the search API for a "roll my own" >> "track" functionality too. >> >> TjL >> > >
[twitter-dev] Re: Send @replies/mentions via SMS?
> > Yeah, I'm thinking about using the search API for a "roll my own" "track" > functionality too. Rebuilding Track is a fun little project. I've done it various ways, but the problem I always run into is the scalability once I publicize it. Early versions of my Twitter client (Tweenky) had the ability to track queries and have them delivered via SMS, email, DM, and XMPP. Having those delivery options on a per query basis made it very powerful as some things you care little about, but still wish to track (hourly aggregate by email). Other things have high priority and I want to be notified right away (via SMS). So, if you feel like building your own Track, consider various delivery methods per query, as well as keeping in mind the scalability if publicly launching it, cause it's easy to do up until that point. Most of my Twitter stuff is just private little projects, for that reason. Tweenky ( new.tweenky.com) being the exception, because now it's all written in Javascript and doesn't use any server-side code, eliminating the scalability issue. =) Good luck. On Tue, May 12, 2009 at 12:53 PM, TjL wrote: > > On Tue, May 12, 2009 at 11:34 AM, Derek Gathright > wrote: > > If you (or anyone else) is still looking for something, I have a bot that > I > > wrote a while back at twitter.com/dmreply. Just request to follow, I'll > > approve, and then it will automatically forward any @replies to you via a > > DM. Your account has to be public as it uses Twitter Search to retrieve > the > > tweets. Simple, requires no authentication info, unfollow at anytime to > > turn off the service. > > That's how I started, but then I realized that people I have blocked > would be sent, and I have a (very) few followers whose updates are > protected, and I wouldn't see there. > > Of course as soon as I finished this, I realized that what would be > *better* for my use would actually be email notification of > 'mentions', so that's what I'm working on now. The nice thing is that > you're not bound to 140 characters in email, so I can also include > what the message was in_reply_to (I have a few followers who @reply > HOURS later and I often have no idea what they are referring to), and > hopefully even a link to @reply back to them, including a proper > in_reply_to also. > > > > > I remembered trying to do it back in the Track days, but tracking @derek > > failed miserably as it dropped the @ and I instantly got swamped with > tweets > > mentioning "derek". > > Yeah, I'm thinking about using the search API for a "roll my own" > "track" functionality too. > > TjL >
[twitter-dev] Re: Send @replies/mentions via SMS?
If you (or anyone else) is still looking for something, I have a bot that I wrote a while back at twitter.com/dmreply. Just request to follow, I'll approve, and then it will automatically forward any @replies to you via a DM. Your account has to be public as it uses Twitter Search to retrieve the tweets. Simple, requires no authentication info, unfollow at anytime to turn off the service. Honestly, I can't use Twitter anymore without it. Getting instant feedback is essential to the real-time nature of Twitter conversations. Hopefully the Twitter team is working on integrating this functionality into the product in the near future. It is something I'd certainly pay for. I remembered trying to do it back in the Track days, but tracking @derek failed miserably as it dropped the @ and I instantly got swamped with tweets mentioning "derek". If anyone wants the source, I'll see what I can dig up, but really it's pretty dead simple. Look for @dmreply followers, loop through each follower looking for mentions in the Twitter Search API, send any new tweets that haven't already been sent. The only trick is storing info on what tweets have been sent, and that's just done with SQLite On Mon, May 11, 2009 at 12:53 PM, TjL wrote: > > Well, I started over and about two hours later I had a script written. > > I've been testing / tweaking it today and it does seem to work. > > Basic premise is fairly simple, it checks > "http://twitter.com/statuses/mentions.rss?since_id=$LAST_ID"; > > where $LAST_ID is stored in a text file as the last ID that was > found/forwarded. > > I then send the message as a DM to myself, which has the added benefit > of being able to use the http://twitter.com/devices setting for "quiet > hours" already. (I have DMs sent to forward to my cell already) > > I also built in some rudimentary filtering to avoid some *people* > (such as reTweet bots) and some regex (such as "RT @tj" and "(via @tj) > since I don't need/want those sent via SMS. > > One benefit of using the 'mentions' API vs the search API (which was > what I had originally tried) is that it automatically excludes people > that you have blocked, which search does not. > > My plan is to check it out for a few days, and if it seems to work > I'll write up a description of how it works and post the code as well. > > If anyone would like to see it in its current state, drop me a note > (preferably offlist, so everyone doesn't have to see it) at > luo...@gmail.com > > TjL >
[twitter-dev] Saved Searches API call?
@Al3x had a tweet a few days ago saying that pulling a user's saved searches would be available via the API. I've looked around for the API documentation on these calls, but couldn't find anything about it. So, is this currently supported within the API? If so, what is the call? If not, any ETA on implementation? Thanks.
[twitter-dev] OAuth question
So I'm able to authenticate & receive the OAuth tokens, but I've yet to find any documentation on what exactly do with them after they're stored. So, instead of providing HTTP basic auth info, what specifically do I pass along with my request to say... update the user's status? Any PHP code examples that show full client support (found one or two that just do 1 call, such as... user->get_info). Thanks.
