[twitter-dev] Re: Introduce yourself!
My name is Maurice Wright. I'm a mechanical engineer turned web designer, turned web developer, turned web marketer. Most of this time was spent in the financial services industry. I first really found out about the Twitter API early last year. Early this year I began working on a Twitter advertising platform (http://www.pay4tweet.com) that will focus on ease of use rather than landing celebrity Tweeters. I spend most of my other free web time maintaining a design awards site (http://www.moluv.com - 10 years) and honing my internet marketing skills. I was relocated out of my job and December, and it feels good...at least until I have to start paying bills again. Anyone need online marketing help? The feature I'd like to most see from Twitter is a non-feature. Please keep it simple. Google has done a great job with this over the years with their main search page. Hopefully, Twitter can do the same. @moluv1 @moluv00 @pay4tweet On Feb 19, 12: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: Chirp is coming to San Francisco April 14 and 15
The Conference is Sold Out! I've never seen such a thing. Anyone have any extra full event passes they'd like to sell? I've been coding for 25 hours straight to launch before the event, and now I can't go. :-( Help...anyone... -Maurice http://www.pay4tweet.com On Apr 5, 12:04 pm, Doug Williams d...@twitter.com wrote: Hi all -- With only nine days left until Biz's opening speech, Chirp -- Twitter's first conference for developers -- is fast approaching! The two day event will be in San Francisco on April 14th and 15th. You can image how excited we are to have a conversation with everyone from the ecosystem in the same room. The conference opens at the Palace of Fine Arts from 9AM to 6PM on April 14th. The schedule features keynotes from Biz Stone, Ev Williams, Ryan Sarver, and Dick Costolo which include announcements and roadmap details. On April 14th at 7PM we all move to Fort Mason to start the Hack Day. Here is where everyone will have a chance to collaborate, meet other members of the ecosystem, and have the entire Twitter team on call to answer questions. After an Ignite session at 8PM on the night of the 14th, we'll leave the doors to Fort Mason open all night for developers who want to dig into their code or conversations. The content on April 15th will pick up at 10AM. The day includes breakout talks on technology, best practices, policy, design, and more. Additionally, we're hosting times for developers to meet with Twitter's designers, Legal team, Platform team, the EFF and others to get their individual questions answered. Even Ev and Biz are hosting an hour so everyone can meet the founders. We'll wrap the entire conference with a rockin' party later that night! We have more space at Fort Mason than the Palace of Fine Arts so last week we opened tickets for the Hack Day. There are still $140 Hack Day passes and a few full conference tickets left so if you would like to attend please head tohttp://chirp.twitter.comand register. We hope to see you there! Thanks, Doug http://twitter.com/dougw -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Chirp is coming to San Francisco April 14 and 15
Thanks for the responses guys, but the first day means more to me than the second day. I'll keep looking around. -Mo On Apr 13, 9:28 am, Ryan Sarver rsar...@twitter.com wrote: Mo, as Taylor said, just grab a Hack Day ticket and we'll see you there! On Tue, Apr 13, 2010 at 9:06 AM, Mo maur...@moluv.com wrote: The Conference is Sold Out! I've never seen such a thing. Anyone have any extra full event passes they'd like to sell? I've been coding for 25 hours straight to launch before the event, and now I can't go. :-( Help...anyone... -Maurice http://www.pay4tweet.com On Apr 5, 12:04 pm, Doug Williams d...@twitter.com wrote: Hi all -- With only nine days left until Biz's opening speech, Chirp -- Twitter's first conference for developers -- is fast approaching! The two day event will be in San Francisco on April 14th and 15th. You can image how excited we are to have a conversation with everyone from the ecosystem in the same room. The conference opens at the Palace of Fine Arts from 9AM to 6PM on April 14th. The schedule features keynotes from Biz Stone, Ev Williams, Ryan Sarver, and Dick Costolo which include announcements and roadmap details. On April 14th at 7PM we all move to Fort Mason to start the Hack Day. Here is where everyone will have a chance to collaborate, meet other members of the ecosystem, and have the entire Twitter team on call to answer questions. After an Ignite session at 8PM on the night of the 14th, we'll leave the doors to Fort Mason open all night for developers who want to dig into their code or conversations. The content on April 15th will pick up at 10AM. The day includes breakout talks on technology, best practices, policy, design, and more. Additionally, we're hosting times for developers to meet with Twitter's designers, Legal team, Platform team, the EFF and others to get their individual questions answered. Even Ev and Biz are hosting an hour so everyone can meet the founders. We'll wrap the entire conference with a rockin' party later that night! We have more space at Fort Mason than the Palace of Fine Arts so last week we opened tickets for the Hack Day. There are still $140 Hack Day passes and a few full conference tickets left so if you would like to attend please head tohttp://chirp.twitter.comandregister. We hope to see you there! Thanks, Doug http://twitter.com/dougw -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Correction in GET users/lookup Documentation
For the GET users/lookup documentation at http://dev.twitter.com/doc/get/users/lookup, the example URLs under Parameters Optional look like http://api.twitter.com/1/users/lookup.xml?user_ids=user_id=1401881,1401882 and http://api.twitter.com/1/users/lookup.xml?screen_names=screen_name=dougw,raffi but, SHOULD BE http://api.twitter.com/1/users/lookup.xml?user_id=1401881,1401882 and http://api.twitter.com/1/users/lookup.xml?screen_name=dougw,raffi Thx http://www.pay4tweet.com -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
[twitter-dev] Re: Correction in GET users/lookup Documentation
Nice! That was fast. Thanks Taylor. -Mo On Apr 27, 12:16 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Mo, This is now updated. Sorry about the confusion. Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod On Tue, Apr 27, 2010 at 9:10 AM, Mo maur...@moluv.com wrote: For the GET users/lookup documentation at http://dev.twitter.com/doc/get/users/lookup, the example URLs under Parameters Optional look like http://api.twitter.com/1/users/lookup.xml?user_ids=user_id=1401881,14... and http://api.twitter.com/1/users/lookup.xml?screen_names=screen_name=do... but, SHOULD BE http://api.twitter.com/1/users/lookup.xml?user_id=1401881,1401882 and http://api.twitter.com/1/users/lookup.xml?screen_name=dougw,raffi Thx http://www.pay4tweet.com -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
[twitter-dev] Whitelist Limits for Direct Messaging
I'm trying to find a reliable source for whitelist limits for Direct Messaging. I looked through the direct messaging limits and best practices for individual services? thread - http://bit.ly/cLVv1Q but there weren't any authoritative descriptions of whitelist limits. What I'm looking for is: 1. DMs allowed per user per hour, and per day - (Where user is defined as someone using an app). 2. DMs allowed per app per hour, and per day I saw that Doug Williams had said that whitelisted users get 5000 DMs per day, but didn't specify whether that was an app total or a total for a random user using an app for DMs. The hourly limit for whitelisted apps wasn't specified at all. -Mo http://www.pay4tweet.com
[twitter-dev] Re: did they lift the limits on direct messages?
Hi Taylor, This is different than what Doug Williams stated in this post - http://bit.ly/cLVv1Q Whitelisted users have a direct messaging limit of 5K messages per day. What I'm still not clear on, though, is how user is being defined. Is the user the app owner or the someone using the app? Also, is 5K DMs a day stated by Doug correct or is it 250 DMs? Apparently Alex and I posted essentially the same request 5 minutes apart. Answering to either this message or to my other post would be much appreciated. -Mo http://www.pay4tweet.com On May 12, 8:39 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Alex, Whitelisting only effects API call rate limiting -- so the answer to your question is no. T On Wed, May 12, 2010 at 8:35 AM, alex urdea alex.urdea.fi...@gmail.comwrote: Thanks for your answer. One more: is the 250 MD limit increased if the application is whitelisted? Or does the whitelist concernt the rates only? Thanks On Wed, May 12, 2010 at 5:15 PM, Taylor Singletary taylorsinglet...@twitter.com wrote: Rate limits and limits on particular actions are different. We could do better in providing a X-FeatureRateLimit header on tweets and DMs and the such that have their own issuance limit -- but I can imagine potential performance issues with that. Rate limits provide a ceiling on the amount of API calls you can make. Their main purpose is to keep the entire platform running smoothly and to not allow any one application to spoil the resource pool for its peers. Twitter, aside from the API itself, has limits on how many status updates and DMs can be sent -- the API just respects the rules of Twitter here. If you're concerned you might be hitting the upper limit, for now the best thing to do would be to implement a counter in your application and queue updates when your counter is full. A user may issue 1000 tweets per day and 250 DMs. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Wed, May 12, 2010 at 4:47 AM, alex alex.urdea.fi...@gmail.com wrote: I'm confused: - here it says that there's a limit on direct messages URL:http://help.twitter.com/entries/15364 In the documentation page for this method you have : API rate limited false: URL: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-direct_messages new Here it says that API methods that use HTTP POST to submit data to Twitter, such as statuses/update do not affect rate limits. I guess that this is a POST method that submits data and is not subject to limits? URL:http://apiwiki.twitter.com/Rate-limiting Which one is true? Thank you!
[twitter-dev] Re: did they lift the limits on direct messages?
Does that mean if @account has a whitelisted app, 5000 messages/day can be sent through that app, but each app user (say @user_of_account) only gets 250/day? If so, is the 100 DM/hour limit the same for both @account and @user_of_account, or is there a different hourly limit for @account? -Mo On May 12, 9:25 am, Abraham Williams 4bra...@gmail.com wrote: I read Doug's email as any account that is specifically whitelisted has 5k DM and that DMs are not effected by IP whitelisting. Abraham On Wed, May 12, 2010 at 09:21, Mo maur...@moluv.com wrote: Hi Taylor, This is different than what Doug Williams stated in this post - http://bit.ly/cLVv1Q Whitelisted users have a direct messaging limit of 5K messages per day. What I'm still not clear on, though, is how user is being defined. Is the user the app owner or the someone using the app? Also, is 5K DMs a day stated by Doug correct or is it 250 DMs? Apparently Alex and I posted essentially the same request 5 minutes apart. Answering to either this message or to my other post would be much appreciated. -Mo http://www.pay4tweet.com On May 12, 8:39 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Alex, Whitelisting only effects API call rate limiting -- so the answer to your question is no. T On Wed, May 12, 2010 at 8:35 AM, alex urdea alex.urdea.fi...@gmail.com wrote: Thanks for your answer. One more: is the 250 MD limit increased if the application is whitelisted? Or does the whitelist concernt the rates only? Thanks On Wed, May 12, 2010 at 5:15 PM, Taylor Singletary taylorsinglet...@twitter.com wrote: Rate limits and limits on particular actions are different. We could do better in providing a X-FeatureRateLimit header on tweets and DMs and the such that have their own issuance limit -- but I can imagine potential performance issues with that. Rate limits provide a ceiling on the amount of API calls you can make. Their main purpose is to keep the entire platform running smoothly and to not allow any one application to spoil the resource pool for its peers. Twitter, aside from the API itself, has limits on how many status updates and DMs can be sent -- the API just respects the rules of Twitter here. If you're concerned you might be hitting the upper limit, for now the best thing to do would be to implement a counter in your application and queue updates when your counter is full. A user may issue 1000 tweets per day and 250 DMs. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Wed, May 12, 2010 at 4:47 AM, alex alex.urdea.fi...@gmail.com wrote: I'm confused: - here it says that there's a limit on direct messages URL:http://help.twitter.com/entries/15364 In the documentation page for this method you have : API rate limited false: URL: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-direct_messages new Here it says that API methods that use HTTP POST to submit data to Twitter, such as statuses/update do not affect rate limits. I guess that this is a POST method that submits data and is not subject to limits? URL:http://apiwiki.twitter.com/Rate-limiting Which one is true? Thank you! -- Abraham Williams | Developer for hire |http://abrah.am @abraham |http://projects.abrah.am|http://blog.abrah.am This email is: [ ] shareable [x] ask first [ ] private.
[twitter-dev] Re: Whitelist Limits for Direct Messaging
Thanks Brian and Taylor. This definitely adds some clarification. There is one last thing, though. Brian, you mentioned that the limits you specified were NOT for IPs and apps. What would be the DM limit for a whitelisted app? I can't find that explicitly stated in any of the references. On May 12, 12:31 pm, Brian Sutorius bsutor...@twitter.com wrote: As I posted in another thread [1], here is information from our help center [2] to hopefully clarify this: - By default, Twitter accounts can send 250 DMs per day. - Accounts (not IPs and not apps) that are on the REST whitelist can send up to 10,000 DMs per day Taylor's point about the limit being account-based and not application- based is important to note. Brian Sutorius [1]http://bit.ly/9DyGDB [2]http://help.twitter.com/entries/160385 On May 12, 9:08 am, Taylor Singletary taylorsinglet...@twitter.com wrote: To my knowledge (and I might be wrong, but this is what I understand to be true): - there is a limit of 250 DMs per day for a user account, blanketly applied. Whitelisting for an application has no effect on this limit. This isn't an API limit. It's a limit for a Twitter user. A twitter user could contribute to their allocation by using the website or an API client. Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod On Wed, May 12, 2010 at 8:43 AM, Mo maur...@moluv.com wrote: I'm trying to find a reliable source for whitelist limits for Direct Messaging. I looked through the direct messaging limits and best practices for individual services? thread -http://bit.ly/cLVv1Qbut there weren't any authoritative descriptions of whitelist limits. What I'm looking for is: 1. DMs allowed per user per hour, and per day - (Where user is defined as someone using an app). 2. DMs allowed per app per hour, and per day I saw that Doug Williams had said that whitelisted users get 5000 DMs per day, but didn't specify whether that was an app total or a total for a random user using an app for DMs. The hourly limit for whitelisted apps wasn't specified at all. -Mo http://www.pay4tweet.com
[twitter-dev] Re: Whitelist Limits for Direct Messaging
Got it. Thanks again Brian. -Mo On May 12, 4:27 pm, Brian Sutorius bsutor...@twitter.com wrote: I'm not sure what you mean - our REST whitelist only accepts usernames and IP addresses as whitelistable entities. Applications don't send direct messages, users do; the DM limit is on a per-user basis. Brian On May 12, 1:27 pm, Mo maur...@moluv.com wrote: Thanks Brian and Taylor. This definitely adds some clarification. There is one last thing, though. Brian, you mentioned that the limits you specified were NOT for IPs and apps. What would be the DM limit for a whitelisted app? I can't find that explicitly stated in any of the references. On May 12, 12:31 pm, Brian Sutorius bsutor...@twitter.com wrote: As I posted in another thread [1], here is information from our help center [2] to hopefully clarify this: - By default, Twitter accounts can send 250 DMs per day. - Accounts (not IPs and not apps) that are on the REST whitelist can send up to 10,000 DMs per day Taylor's point about the limit being account-based and not application- based is important to note. Brian Sutorius [1]http://bit.ly/9DyGDB [2]http://help.twitter.com/entries/160385 On May 12, 9:08 am, Taylor Singletary taylorsinglet...@twitter.com wrote: To my knowledge (and I might be wrong, but this is what I understand to be true): - there is a limit of 250 DMs per day for a user account, blanketly applied. Whitelisting for an application has no effect on this limit. This isn't an API limit. It's a limit for a Twitter user. A twitter user could contribute to their allocation by using the website or an API client. Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod On Wed, May 12, 2010 at 8:43 AM, Mo maur...@moluv.com wrote: I'm trying to find a reliable source for whitelist limits for Direct Messaging. I looked through the direct messaging limits and best practices for individual services? thread -http://bit.ly/cLVv1Qbut there weren't any authoritative descriptions of whitelist limits. What I'm looking for is: 1. DMs allowed per user per hour, and per day - (Where user is defined as someone using an app). 2. DMs allowed per app per hour, and per day I saw that Doug Williams had said that whitelisted users get 5000 DMs per day, but didn't specify whether that was an app total or a total for a random user using an app for DMs. The hourly limit for whitelisted apps wasn't specified at all. -Mo http://www.pay4tweet.com
[twitter-dev] TWITTER BANS 3rd PARTY ADVERTISING
You guys couldn't have hinted about this to me at the developer meetup or at Chirp before I built up a team? Thanks. It's fitting that the author of the post is named Dick. http://blog.twitter.com/2010/05/twitter-platform.html
[twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING
Just so that I'm clear, the fact that Twitter chose to do this isn't a surprise. It's the fact that I've been participating in events, developing, networking, and building a team all year AFTER getting affirmations from individuals at Twitter that I had nothing to worry about in building a Twitter advertising platform. I've seen a lot of bad behavior from ad platforms that incent users to tweet for short-term financial gain, so I understand the need to tidy up from time to time. But, this was more like sand-blasting the living room in order to do some dusting. Maybe you guys have a Google Adsense-type shared revenue model (or something similar) in the works that enables those who know how to properly add value and relevance to generate an income stream in a way that is beneficial to Twitter users and Twitter. That would make sense. Another great strategy would have been issuing a warning to bad players while also incenting everyone to build mechanisms to support Promoted Tweets. There are a number of paths that could have been chosen that would have been a win-win. ...we will not allow any third party to inject paid tweets into a timeline on any service that leverages the Twitter API The way this reads, you can't even have a WordPress blog that puts ads near a Twitter stream. Please correct me if I'm misinterpreting this. RIP Ad.ly, Sponsored Tweets, Magpie, Pay4Tweet, StockTwits, MuckRack, (No more ads Listorious), TwittAd (and the non-profits you've supported), 140Proof, etc., etc. -Mo On May 24, 9:23 am, Mo maur...@moluv.com wrote: You guys couldn't have hinted about this to me at the developer meetup or at Chirp before I built up a team? Thanks. It's fitting that the author of the post is named Dick. http://blog.twitter.com/2010/05/twitter-platform.html
[twitter-dev] Re: Twitter Platform blog post
Ryan, I asked explicitly about this at the Developer meetup earlier this year, and received No Comment for an answer. Twice. Maybe there needed to be a lot of discussion about this before a decision was announced, but ... wow! To Liz's point there is no language in the blog post about partnership or cooperation based on Twitter's guidelines (which I'm sure most would be very open to). The post does mention there being opportunities to sell ads, but are those opportunities only available to Twitter? Please elaborate. On May 24, 10:01 am, Larry Wright larrywri...@gmail.com wrote: That's how I read it as well, but there's certainly some gray area there. Some twitter clients just display an ad at the top of bottom of the app, those would seem to be ok. Some I've seen recently put things in the timeline that look exactly like tweets (except for a line at the bottom that says sponsored tweet or similar. Those would seem to be obviously NOT ok. But then there are apps that insert a graphical ad in the timeline (clearly not a tweet)... are those ok? I think Tweetie for OS X used to do this. On May 24, 11:27 am, Shannon Clark shannon.cl...@gmail.com wrote: I'm not at Twitter but I read the blog post as saying that ads around the Twitter timeline (as part of the UI of an application or website) are fine but ads IN the Twitter timeline (as paid tweets) are not. Shannon Sent from my iPhone On May 24, 2010, at 12:19 PM, Liz nwjersey...@gmail.com wrote: Ryan, It's confusing to me that Dick says there will be no third party ads (8th paragraph) but under Fostering Innovation, #2, he talks apps about selling ads. Does this decision do away with services like Sponsored Tweets? I appreciate such a thoughtful blog post (and hope there are more in the future) but what is absent is any language of partnership or collaboration. Twitter's goals are stated and basically, everyone else has to deal with the consequence. Also, the language of optimizing user experience. Can you tell me what is the basis of user experience testing that occurs at Twitter? Because there is no mechanism for users to offer feedback to Twitter about their experience. How do you know whether a development enhances user experience or not? It seems like Twitter does what they think is best, regardless of what the bulk of users might want. Thanks for any answers you can provide. Liz Pullen nwjer...@yahoo.com
[twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING
Peter, The strength of Twitter is that the user has control, not a developer. If they want to post an offer on their page, or anything else for that matter, for pay or just because they want to share one, they should be allowed to. The Twitter infrastructure is a great filter for weeding out posts, users, and apps that have poor intentions. You, as a developer, can always exclude tweets based on where the tweet came from. I also support Twitter's intent, but this was not the best way to get it done. On May 24, 10:24 am, Peter Denton petermden...@gmail.com wrote: I want to voice support of this decision. I build third party apps that are 100% about consuming, purposing, and displaying tweet streams. If different clients inevitably begin selling tweet injections, I really don't want to deal with those on my end. The tweet stream should remain a pure data entity. Dick has already said apps can opt out of displaying tweets, but if other apps are injecting, I lose control of that, and it will wreck the integrity of my app. Trust is ensuring that tweets coming to me through streams, are, to the best of twitter's ability, not spam. On Mon, May 24, 2010 at 10:18 AM, Duane Roelands duane.roela...@gmail.comwrote: The way this reads, you can't even have a WordPress blog that puts ads near a Twitter stream. Please correct me if I'm misinterpreting this. You're misinterpreting it. There's not a problem if you're displaying a Twitter feed on a page and there are ads -near- it. What is now forbidden is the injection of ads into the stream itself.
[twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING
Ryan, Thanks for writing the clarification. It sounds as if the intent of the ban is to prevent anyone from emulating and distributing a stream of Twitter data to Twitter mobile/web/desktop clients and inserting ads into it. Tweets posted in individual accounts by account owners or by proxies/3rd parties on behalf of the account owners are still allowed. The blog post did not suggest that this was the case, nor did most of the press about the subject (as mentioned earlier in this thread). Your post clears this up a lot. Apologies to Dick On May 24, 10:28 pm, Ryan Sarver rsar...@twitter.com wrote: I want to make sure this part is clear -- this policy change isn't meant to say that we are going to start policing if the content of something a user tweets is an ad or not. The policy change affects 3rd party services that were putting ads in the middle of a timeline. So if Liz is paid by Reebok to tweet about how much she loves their new shoes, we are not going to be policing that any more than we were on Friday. This policy also *does not prohibit* services like Ad.ly that help facilitate those relationships or even help her post the ads to her timeline on her behalf. It *does prohibit* an application from calling out to a service to find an ad to serve to Liz that will get inserted into the timeline she is viewing. The language is somewhat nuanced but it sounds like we might need to make the policy more explicit as a number of people are misinterpreting it. Let me know if you have more questions. Ryan On Mon, May 24, 2010 at 12:26 PM, Dewald Pretorius dpr...@gmail.com wrote: Liz, You are 100% correct in summarizing the problem. Not only were those businesses built with the full knowledge of Twitter, Twitter even had specific rules governing sponsored tweets (had to be clearly marked as sponsored, etc.). I'm really baffled by this decision of Twitter, because I don't understand how they expect to have integrity and trust with developers while doing this type of stuff. Right now we are all being pointed to Annotations as the holy grail of new development. But how do we know that they won't yet again change a rule in the future that will kill businesses that were built on top of Annotations? On May 24, 3:56 pm, Liz nwjersey...@gmail.com wrote: Peter, I think the problem is that business have been created, received funding and developed over the past year, with the full knowledge of Twitter, and this just undercuts destroys them. I think people can understand the rationale (and the desire for Twitter to eliminate competition) but this is a policy decision that should have been made over a year ago. Twitter should have included this in an earlier terms of service instead of giving an implicit okay to services like Sponsored Tweets which has turned into a successful company. It also seems disingenuous that the blog post says that a guiding principle of Twitter is that We don't seek to control what users tweet. And users own their own tweets. and allow adult-oriented content and photos but for some reason, users can't Tweet ads. That sounds like control of content to me. Liz
[twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING
Taylor, I'm glad Twitter thought to do this, but it still doesn't explain as clearly as Ryan's post here about what's acceptable and what's not. Not Acceptable: Paid Tweets injected into any timeline on a service that leverages the Twitter API (other than Promoted Tweets). This applies to any Twitter stream, whether user based, search based, or other. This makes it sound like Ryan was wrong, and actually confuses the issue again. From Ryan: This policy also *does not prohibit* services like Ad.ly that help facilitate those relationships or even help her post the ads to her timeline on her behalf. These sound like they are conflicting. Is Ryan correct, or not? What would also be helpful is a link to information on how the Promoted Tweets rev share works. On May 26, 9:20 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Hello Everyone, We recently updated our Advertising FAQ to answer many of the questions that you may have.http://bit.ly/twitter-ad-faq Taylor On Wed, May 26, 2010 at 9:15 AM, Liz nwjersey...@gmail.com wrote: I hope some answers are forthcoming, James. Twitter doesn't seem very talkative.
[twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING
Dewald, Thanks for the clarification. What you're saying makes sense and is in line with what Ryan was saying. I hope you're right. On May 27, 2:35 pm, Dewald Pretorius dpr...@gmail.com wrote: Mo, I think the word injected is causing the confusion. As I understand it it means: - I pull a list of tweets from the API into an array. - Before displaying the list to the user, I inject entries that look like tweets (but are actually entries I get paid to display) into that array. - Then I display the list to the user making it look as if everything in the list came from Twitter. As I said, that's how I understand it. But with that understanding, it does not make sense why Dick was going on about the infrastructure cost of Twitter, because this injection does not impact Twitter's infrastructure at all. It all happens exclusively on the application's server or the desktop or mobile device. Anyway, hopefully at some point in time there will be an authoritative and unambiguous explanation from Twitter. On May 27, 10:16 am, Mo maur...@moluv.com wrote: Taylor, I'm glad Twitter thought to do this, but it still doesn't explain as clearly as Ryan's post here about what's acceptable and what's not. Not Acceptable: Paid Tweets injected into any timeline on a service that leverages the Twitter API (other than Promoted Tweets). This applies to any Twitter stream, whether user based, search based, or other. This makes it sound like Ryan was wrong, and actually confuses the issue again. From Ryan: This policy also *does not prohibit* services like Ad.ly that help facilitate those relationships or even help her post the ads to her timeline on her behalf. These sound like they are conflicting. Is Ryan correct, or not? What would also be helpful is a link to information on how the Promoted Tweets rev share works. On May 26, 9:20 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Hello Everyone, We recently updated our Advertising FAQ to answer many of the questions that you may have.http://bit.ly/twitter-ad-faq Taylor On Wed, May 26, 2010 at 9:15 AM, Liz nwjersey...@gmail.com wrote: I hope some answers are forthcoming, James. Twitter doesn't seem very talkative.
[twitter-dev] Open Call for Twitter Marketing and Advertising Blog Submissions
Twitter developers have a lot of insight into what works and what doesn't in a Twitter application, but there is no road map yet to building one that is commercially successful. Yesterday I launched a blog at http://blog.pay4tweet.com and I'd like to showcase articles, blog posts, charts, data, analysis, infographics, and insights about the commercial use of Twitter. - If you have a startup or are building an application that uses Twitter, and you'd like to have a place to discuss your insights consider this an open call for article submissions. - If you already have a blog, please send us a link and we'll add it to our blogroll. Also, feel free to send us a link to your new articles, or @reply @pay4tweet with the post title and link. Hopefully, with your contributions, we can create a blog that developers and startups can reference to figure out the best way to promote and monetize their applications. -Mo http://www.pay4tweet.com
[twitter-dev] Re: Open Call for Twitter Marketing and Advertising Blog Submissions
Good question. The answer is rev share on text ads, and text ad networks. Pay4Tweet.com enables transactions for tweets. Those tweets will serve as the datasource for ads similar to Adsense. The trick is that these types of ads and networks have to grow organically first. http://www.pay4tweet.com provides a very simplified interface to help that happen. You can see an example of what a final text ad unit can look like at http://www.moluv.com . There are also a lot of other creative possibilities for text ads. Twistori and Digg Labs Big Spy are some pretty good examples. Hope that sheds a little light. Maybe I should put this in a blog post. :-) Twistori: http://www.twistori.com Digg Labs Big Spy: http://labs.digg.com/bigspy/ On May 28, 10:29 am, M. Edward (Ed) Borasky zn...@borasky- research.net wrote: Quoting Mo maur...@moluv.com: Twitter developers have a lot of insight into what works and what doesn't in a Twitter application, but there is no road map yet to building one that is commercially successful. Yesterday I launched a blog athttp://blog.pay4tweet.comand I'd like to showcase articles, blog posts, charts, data, analysis, infographics, and insights about the commercial use of Twitter. - If you have a startup or are building an application that uses Twitter, and you'd like to have a place to discuss your insights consider this an open call for article submissions. - If you already have a blog, please send us a link and we'll add it to our blogroll. Also, feel free to send us a link to your new articles, or @reply @pay4tweet with the post title and link. Hopefully, with your contributions, we can create a blog that developers and startups can reference to figure out the best way to promote and monetize their applications. -Mo http://www.pay4tweet.com What's your business model? How do *you* make money?
[twitter-dev] Re: Thoughts on annotations
Great update! I don't feel so bad for missing the event now. -Mo @pay4tweet On May 31, 11:39 am, Zac Bowling zbowl...@gmail.com wrote: This weekend's hackfest was at Twitter HQ was fun. About a couple dozen of us stayed awake for about 30 hours and still had enough to energy to present. Some pretty amazing things created and we helped identified a bunch of bugs. Now that I've had a chance to go home and catch up on some sleep, here is a brain dump of my thoughts. * One of the documented recommended types is place/location, but this data is similar to what we store in the geo fields. I'm not sure what issues we may run into privacy using it rather then storing the Geo fields (users can enable/disable geo and remove geo data from all previous status updates). * We will always have twitter clients that will not understand or look even look at our attributes. This means that we can't can't have annotations that change the meaning of a tweet or make the meaning of the tweet useless. This is basically graceful degradation, and not progressive enhancement. We joked that want to see tweets that say: This tweet can only be read in clients that support X annotations. Please upgrade your twitter client or try X client.. * You have to treat annotations as potentially hostile attack vectors. As was proved with some awesome cornfied and flashing unicorn injections this weekend, any raw data can be store in annotations. Just because you stored it there, anyone can do store any raw data and anyone can post tweets that copy your annotation format. Twitter may sanitize javascript injections, but it doesn't stop other types of injections from occurring if you don't check. It's extremely important to validate, html encode, or whatever you need to with the data stored in the annotations. As I did with my twitter remote shell execution example, I added my own signature and noance of my own into the twitter annotation to validate the sender had my secret. It may be one solution. * Attributes work at the time of creation because status updates are immutable. This may be obvious to most, but its a limitation that hits you a few times as you develop. Because of that we need to make sure that we can get most of the clients, including Twitter.com, support the most popular annotation formats. We can't fix update status updates after the fact so we have to get it right. (Adding annotations to new style retweets is in theory possible) * Can't remind people enough to switch from twitter.com to api.twitter.com. A bunch of little differences between the two that give you headaches. Our board of wasted time at the hackfest summed it up pretty well. * A good number of us spent a good deal of time on just getting past OAuth this weekend. We had a lot of people that understood the OAuth spec fairly well thankfully and @jmhodges was there to help (although not his area he deals with in the code). Since you update twitter with POST, it's optional to store the authentication data in the postdata instead of the authentication header according to the spec, and some our libraries were doing just that, but twitter only works with the Authentication header. We didn't know but this was documented on the Wiki and had to learned from trial and error. A bunch of us got caught up on using twitter.com instead of api.twitter.com. I think we all worked through it at about midnight late saturday. In the end it was pretty awesome. I want to thank @jonashuckestein for the the bookmarklet. It was awesome and saved us all time. http://jonashuckestein.github.com/Twitter.com-Annotations-Bookmarklet/(see my stream with ithttp://twitpic.com/1st8sd) I won't cover the bugs. I'll leave twitter to document those if and when they open up annotations to more developers. Thanks all! Zac Bowling @zbowling
[twitter-dev] Twitter Infographics Data
I'd like to create a series of blog posts that take Twitter application data from various Twitter apps and converts it into something visual. If you have access to data from your own Twitter app that you are willing to share, and that you think can reflect a major trend in the Twitter ecosphere, or that you've already built an infographic/chart/graph/visualizatoin for, please let me know. The first post in the series is 18 Tittilating Twitter Infographics and Visualizations. You can find it at http://blog.pay4tweet.com/2010/06/02/18-tittilating-twitter-infographics-and-visualizations/ Thanks. -Mo @pay4tweet
[twitter-dev] users/lookup not working for JSON
I might be overlooking something, but it seems like users/lookup isn't
working. I tried it using my app credentials and got the following
message:
{
errors: [
{
code: 17,
message: No user matches for specified terms
}
]
}
Just to be sure, I went to http://dev.twitter.com/console and entered
the parameters from the documentation
http://api.twitter.com/1/users/lookup.xml?user_id=1401881,1401882
http://api.twitter.com/1/users/lookup.xml?screen_name=dougw,raffi
I tried
1. user_id in the left field and 1401881,1401882 then followed
that unsuccessful attempt with
2. screen_name and dougw,raffi in the right field
The second setting was attempted using both GET and POST with
JSON selected as output, and I got the same message.
After trying a bunch of combinations, using XML seemed to still work,
but no more JSON.
[twitter-dev] Re: Twitter Infographics Data
Thanks Abraham. After I started writing I found a few other compilations, but none of them referenced the originating article and designer, so I kept going. There are a lot of mad geniuses out there. The videos are especially creative. On Jun 3, 10:20 am, Abraham Williams 4bra...@gmail.com wrote: Nice collection of infographics. Abraham On Thu, Jun 3, 2010 at 07:43, Mo maur...@moluv.com wrote: I'd like to create a series of blog posts that take Twitter application data from various Twitter apps and converts it into something visual. If you have access to data from your own Twitter app that you are willing to share, and that you think can reflect a major trend in the Twitter ecosphere, or that you've already built an infographic/chart/graph/visualizatoin for, please let me know. The first post in the series is 18 Tittilating Twitter Infographics and Visualizations. You can find it at http://blog.pay4tweet.com/2010/06/02/18-tittilating-twitter-infograph... Thanks. -Mo @pay4tweet -- Abraham Williams | Developer for hire |http://abrah.am @abraham |http://projects.abrah.am|http://blog.abrah.am This email is: [ ] shareable [x] ask first [ ] private.
[twitter-dev] Re: users/lookup not working for JSON
It looks like things are working again. Thanks unknown developer. I
also noticed that the extensions (json,xml,atom) seem to be case-
sensitive. I don't know how I got this far without noticing that.
On Jun 3, 9:04 pm, Mo maur...@moluv.com wrote:
I might be overlooking something, but it seems like users/lookup isn't
working. I tried it using my app credentials and got the following
message:
{
errors: [
{
code: 17,
message: No user matches for specified terms
}
]
}
Just to be sure, I went tohttp://dev.twitter.com/consoleand entered
the parameters from the documentation
http://api.twitter.com/1/users/lookup.xml?user_id=1401881,1401882http://api.twitter.com/1/users/lookup.xml?screen_name=dougw,raffi
I tried
1. user_id in the left field and 1401881,1401882 then followed
that unsuccessful attempt with
2. screen_name and dougw,raffi in the right field
The second setting was attempted using both GET and POST with
JSON selected as output, and I got the same message.
After trying a bunch of combinations, using XML seemed to still work,
but no more JSON.
[twitter-dev] jQuery Twitter Plugin
I just finished building a jQuery-based Twitter plugin - http://www.pay4tweet.com/pay4tweet_plugin.php . I couldn't find one that allowed for all the customizations I wanted. The problem is that now it's pretty complex. If anyone can find any problems with it (or the demo page for that matter), please let me know. Also, although, I'm not an open source guru, I'd like to eventually make it open once I'm comfortable with the stability of the starting code. Any suggestions, or references, on where to begin that process? Or, are there any other 3rd party open source Twitter development projects that people are aware of? -Mo
[twitter-dev] New Status Using A Query String
It may just be me, but is anyone else having any problems adding a status to Twitter by passing a query string? -- 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] Re: New Status Using A Query String
Ok. Thanks. On May 17, 3:15 pm, Arnaud Meunier arn...@twitter.com wrote: Hey Mo, There is already a thread about this subject:http://bit.ly/j2v5Kd:) I recommend you switch to Web Intents. That's the recommended (and supported way) to do it. More info on this documentation page:http://dev.twitter.com/pages/intents Arnaud / @rno http://twitter.com/rno On Tue, May 17, 2011 at 2:29 PM, Mo maur...@moluv.com wrote: It may just be me, but is anyone else having any problems adding a status to Twitter by passing a query string? -- 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] Unwanted Link Shortening with t.co
Since switching to the new Intents linking, by URLs are being shortened. I have a registered Twitter application, and a relatively short URL already ( http://TagsBy.me ). I'd like to continue using my own URLs, even if it means I have to build a shortener with an even shorter domain. However, I'd like to know what the rules/guidelines are that Twitter uses for overriding links, since there are many exceptions that I see in my Twitter stream. -- 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] Re: Unwanted Link Shortening with t.co
I understand what's happening. The issue is that now my domain doesn't appear in my tweets. It's a marketing issue. I'd like to know what the workaround is, since one seems to exist for other link shorteners. On May 18, 5:21 pm, Jonathan Strauss jonat...@awe.sm wrote: Twitter is just wrapping your link int.co. When it gets displayed in Twitter, it will show the link on your domain as you passed it in. On May 18, 12:35 pm, Mo maur...@moluv.com wrote: Since switching to the new Intents linking, by URLs are being shortened. I have a registered Twitter application, and a relatively short URL already (http://TagsBy.me). I'd like to continue using my own URLs, even if it means I have to build a shortener with an even shorter domain. However, I'd like to know what the rules/guidelines are that Twitter uses for overriding links, since there are many exceptions that I see in my Twitter stream. -- 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] Unwanted T.CO shortening
How do I register my domain as a URL shortener (like bit.ly or ow.ly) so that the links I post do not get shortened with a T.CO domain when I use intents? I just looked through some old tweets and apparently even those URLs have been replaced with T.CO. When someone looks at my tweet stream they should see the domains I post, not T.CO. If I want to talk about a friend or partners site, they should see that URL, not T.CO. If I want to help promote a non- profit like the Red Cross, Oil Spill Relief, Joplin, Missouri Tornado Relief, etc., they should see their URLs not T.CO. There was a time when developers were really rooting for Twitter. Moves like this only benefit Twitter AND are detrimental to everyone else. Not only is changing links to past tweets bad for developers, but for marketers as well. Not to mention that it borders on being unethical. Can you imagine Google, Facebook, Yahoo, or Bing replacing URLs with their shorteners? Of course, they could do it, if they chose to, but they won't. I realize it's your company, you have a great product, and you can do what you want. But, Twitter's success came on the backs of many dedicated developers, who also have the choice of putting their time elsewhere. If only there were an open source microblogging solution. -- 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] Re: Unwanted T.CO shortening
The shortened links I originally saw were all in HootSuite. I've since logged out and logged back in and the T.CO shortened URLs went away. However, my original question was never answered. Is there a process for getting on a list of approved shortened URLs? Ben, your screenshot and the tweet page do not have the same content in the mouseover. John, you're smoking something. I just checked Google, Facebook, Bing, and Yahoo with a search of the term PHP. None of the exposed URLs are shortened. What they do in the background is irrelevant for the general public and for the purpose of this discussion. Kosso, I'm with you on the unexpected destinations. In short, whoever is in control at Twitter is either not in direct communication with users and developers in regard to this or is simply not listening. -Mo On Jun 10, 2:23 pm, Ben Ward benw...@twitter.com wrote: On Jun 10, 2011, at 1:21 PM, Kosso wrote: The massive trouble I have with all this is that I like to know what the hell I'm clicking on before clicking a link. It's kind of my right as a citizen of the web. I personally can't stand it when, for example a link fires up iTunes or goes to some site I don't want to waste (possibly mobile and limited) bandwidth on. I like to choose WHO I give MY visit/traffic to. To be clear, the API returns all the information for all clients to display the original short URL, and navigate via t.co. We also look up the full destination URL and return that too, allowing even clearer navigation of where you as a user will end up when following a link. You can see this implemented on twitter.com today: https://twitter.com/joshtpm/status/79283124747501568 * The URL destination points to t.co * The displayed text of the URL is a cropped and shortened version of the real URL * The title (tooltip) of the URL displays the full address of the destination. I've further illustrated it with a screenshot here:https://skitch.com/benward/frff8/ The documentation for the URL entities that provide all of this information in the API response is here:http://dev.twitter.com/pages/tweet_entities Ben -- Platform Developer, Twitter -- 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
