[twitter-dev] Re: Access tokens changing on their own?

[Dewald Pretorius]

There's an open issue about this:

http://code.google.com/p/twitter-api/issues/detail?id=2197

-- 
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: A new permission level

[Dewald Pretorius]

> Please continue to send
> us your feedback about the permission model and what you would like to
> see it offer.

Why?

-- 
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: A new permission level

[Dewald Pretorius]

The more I think about this, the less it makes any sense whatsoever to
force everyone through a re-authentication if DM access is required.

Here's why:

1) For existing user tokens, the users have already granted access
with the knowledge that it is to their DMs as well. In other words,
they have already granted access to their DMs.

2) If an app needs access to the users' DMs, it is going to force
thousands of people to waste thousands of hours to re-authorize
something they want the app to do and something they have already
implicitly granted to the app.

3) Many users are going to miss the memo, and then be very upset with
the app owner(s) because what had worked before suddenly stopped
working.

4) Additional and completely unnecessary workload and costs are going
to be added to the support staff of the app, to help users who do not
understand why they need to re-authorize, or who have missed the memo
in the first place.

5) By forcing re-authorization for apps that require DM access and
already have DM access, Twitter gains absolutely nothing. After
forcing thousands of people through a redundant process, we're back at
where we started, namely, the app has access to the user's DMs. It's
not like the user has a choice of not granting a requesting app access
to his DMs, but only to his followers and tweets. If the app request
DM access, the user can either grant it, or deny access completely.
Exactly the same way it works today.

The only benefit here is for apps who don't need DM access, which will
now be able to request account access without DM access. But, if the
app does not need or use access to DMs, it provides absolutely no
benefit to take existing DM access of already granted user tokens
away. It is not used.

It makes perfect sense to implement this change from a date going
forward, meaning all user tokens granted after that date will be
either Read, Read & Write, or Read & Write & DM. That provides more
transparency for the user. But to yank away existing access rights and
then force the equivalent of a small nation through a re-
authentication process just to re-establish what had already been
granted and then unilaterally taken away, that makes no sense at all.

-- 
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: A new permission level

[Dewald Pretorius]

Matt,

If I understand correctly, activate the new permission, all Read and
Read/Write user_tokens issued to third-party applications will lose
their ability to read direct messages.

That is a HUGE and MAJOR headache for existing apps and their
thousands of users who are currently using any of the /1/
direct_messages methods.

Can't you rather grand-father in apps and user_tokens that have
already been granted?

-- 
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: At Reply Spam

[Dewald Pretorius]

Arnaud,

Know what I totally cannot understand? Why is it that Twitter, through
various spokespersons, continually reinforces the impression that they
pay scant lip service to the alleged notion that they value the third
party developer ecosystem?

Under any circumstances, "Do as I say, not as I do," is disrespectful
and demonstrates that the intended audience of that approach is viewed
by the perpetrators of the approach as occupying a lower and less
privileged strata of society. It is disrespectful when you treat your
kids that way.  It is disrespectful when you treat your life partner
that way. It is disrespectful when you treat your business partners
that way.

Does Twitter like pointing a loaded gun at its own foot and pulling
the trigger, again and again?


On May 6, 4:38 am, Arnaud Meunier  wrote:
> Dewald,
>
> These rules apply to third party apps. @twittersuggests is not a third
> party app, but an experimental feature, developed and owned by
> Twitter.
>
> Now I can also understand this "Do as I Say, not as I Do" situation
> can be irritating. But I guess the best thing to do at this point is
> probably to share your thoughts on the experiment through his
> dedicated feedback 
> form:https://spreadsheets.google.com/a/twitter.com/spreadsheet/viewform?fo...
>
> Arnaud / @rno
>
> On May 5, 2011, at 11:56 AM, Dewald Pretorius  wrote:
>
>
>
> > Arnaud,
>
> > That's comforting to know. With that being the case, can you please
> > enlighten us as to why Twitter is apparently violating its own rules,
> > which, as you said, are still in force and we all still are apparently
> > expected to adhere to?
>
> > Let me help you and quote from your rules the appropriate text: "If
> > you are automatically sending @reply messages or Mentions to a bunch
> > of users, the recipients must request or approve this action in
> > advance."
>
> > Have any of the users targeted by @twittersuggests, which is sending
> > automated @reply messages "to a bunch of users", explicitly requested
> > or approved this action in advance?
>
> > If not, then you may have de facto invalidated that section of your
> > rules and by implication exempted all developers and applications from
> > it.
>
> > On May 5, 12:45 pm, Arnaud Meunier  wrote:
> >> Hey Dewald,
>
> >> Neither our TOS nor our Automation Rules & Best Practices 
> >> (http://support.twitter.com/articles/76915) have changed since the launch
> >> of @twittersuggests experimental feature :)
>
> >> Arnaud / @rno <http://twitter.com/rno>
>
> >> On Thu, May 5, 2011 at 6:00 AM, TjL  wrote:
> >>> On Thu, May 5, 2011 at 8:31 AM, Dewald Pretorius  wrote:
> >>>> With reference to @twittersuggests, is other unsolicited @reply spam
> >>>> now also officially sanctioned by Twitter?
>
> >>> When has Twitter ever given you the idea that they were playing by the
> >>> same rules as everyone else?
>
> >>> --
> >>> Twitter developer documentation and resources:http://dev.twitter.com/doc
> >>> API updates via Twitter:http://twitter.com/twitterapi
> >>> Issues/Enhancements Tracker:
> >>>http://code.google.com/p/twitter-api/issues/list
> >>> Change your membership to this group:
> >>>http://groups.google.com/group/twitter-development-talk
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this 
> > group:http://groups.google.com/group/twitter-development-talk

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

[twitter-dev] Re: At Reply Spam

[Dewald Pretorius]

Arnaud,

That's comforting to know. With that being the case, can you please
enlighten us as to why Twitter is apparently violating its own rules,
which, as you said, are still in force and we all still are apparently
expected to adhere to?

Let me help you and quote from your rules the appropriate text: "If
you are automatically sending @reply messages or Mentions to a bunch
of users, the recipients must request or approve this action in
advance."

Have any of the users targeted by @twittersuggests, which is sending
automated @reply messages "to a bunch of users", explicitly requested
or approved this action in advance?

If not, then you may have de facto invalidated that section of your
rules and by implication exempted all developers and applications from
it.

On May 5, 12:45 pm, Arnaud Meunier  wrote:
> Hey Dewald,
>
> Neither our TOS nor our Automation Rules & Best Practices 
> (http://support.twitter.com/articles/76915) have changed since the launch
> of @twittersuggests experimental feature :)
>
> Arnaud / @rno <http://twitter.com/rno>
>
>
>
>
>
>
>
> On Thu, May 5, 2011 at 6:00 AM, TjL  wrote:
> > On Thu, May 5, 2011 at 8:31 AM, Dewald Pretorius  wrote:
> > > With reference to @twittersuggests, is other unsolicited @reply spam
> > > now also officially sanctioned by Twitter?
>
> > When has Twitter ever given you the idea that they were playing by the
> > same rules as everyone else?
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:
> >http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group:
> >http://groups.google.com/group/twitter-development-talk

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

[twitter-dev] At Reply Spam

[Dewald Pretorius]

With reference to @twittersuggests, is other unsolicited @reply spam
now also officially sanctioned by Twitter?

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

[twitter-dev] Five-Oh-Two Fest

[Dewald Pretorius]

Twitter, are you aware that your API is throwing 502s left right and
center on blocks/create/nnn.json and report_spam.json?

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

[twitter-dev] Re: consistency and ecosystem opportunities

[Dewald Pretorius]

Here's one of the best and most thoughtful articles yet on this latest
ecosystem bomb:

http://radar.oreilly.com/2011/03/twitter-developers.html

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

[twitter-dev] Re: consistency and ecosystem opportunities

[Dewald Pretorius]

Taylor,

Would you mind taking a stab at clarifying Section 5.E of the new TOS,
which reads, "You may not use Twitter Content or other data collected
from end users of your Client to create or maintain a separate status
update or social network database or service."

It appears to say that a Client is not allowed to offer its users the
ability to create status updates on other services (StatusNet,
Facebook, etc.). Had it not been for the "or other data collected from
end users" I would have interpreted it that one cannot use any Twitter
Content (user data and tweets obtained via the Twitter API) and feed
that Twitter Data into other and/or competing social network
platforms. But, "or other data collected from end users" seems to
suggest that one cannot so much as offer any support for any other and/
or competing social network platform. Meaning, if you have a Client,
you can support Twitter OR Everything Else, not both.


On Mar 14, 11:12 am, Taylor Singletary 
wrote:
> Hi Adam,
>
> Thanks for your comments as always. I can help clarify a bit around how
> clients will be held to higher standards.
>
> Criteria we may examine include: is the application in tune with the spirit
> of the developer guidelines? Does the application refrain from storing
> username & password if it's using xAuth? Are tweets displayed with the
> proper attribution? Are the actions presented for the tweet appropriate in
> respect to it being a tweet? Does the application frame portions of our
> mobile site? Does it store non-public user data in a public way? Does the
> application provide a privacy policy? Is the client application paying for
> installation on mobile carriers?
>
> The new terms also offer some examples that are reasonably specific:
>
>
>
>
>
> >> A. Your Client must use the Twitter API as the sole source for features
> >> that are substantially similar to functionality offered by Twitter. Some
> >> examples include trending topics, who to follow, and suggested user lists.
>
> >  B. You may not pay, or offer to pay, third parties for distribution of
> >> your Client. This includes offering compensation for downloads (other than
> >> transactional fees), pre-installations, or other mechanisms of traffic
> >> acquisition.
>
> >  C. Your Client cannot frame or otherwise reproduce significant portions of
> >> the Twitter service. You should display Twitter Content from the Twitter
> >> API.
>
> > D. Do not store non-public user profile data or content.
>
> > E. You may not use Twitter Content or other data collected from end users
> >> of your Client to create or maintain a separate status update or social
> >> network database or service
>
> Using a Twitter client is like using an extension of Twitter, and though the
> user interfaces may change we want to ensure that the user experience is
> consistent, whether it's consistency in the actions a user can perform with
> a Tweet, the way their private information is treated, or how slowly,
> quickly, and with what tact advertising flows or does not flow through the
> network.
>
> Taylor
>
> On Sun, Mar 13, 2011 at 9:55 PM, Adam Green <140...@gmail.com> wrote:
> > Yes! Transparency!  That is what we are really craving. That is the subtext
> > for every developer responding to this thread. What we all want is
> > transparency about being shut down. Why does Twitter "revoke literally
> > hundreds of API tokens / apps a week" as Ryan said? Is it for something
> > obvious, like pumping out thousand of spam tweets or abusive follows, or is
> > it for something innocent, like not putting the right text on a tweet
> > button? I have never seen a description of an app that was blocked, except
> > for a few loons like Edward H. What if you told us about apps that get
> > blocked as examples, and explain what they did wrong? You don't even have to
> > identify them by name. Just explain exactly what type of transgressions are
> > causing rejection. That could calm people down.
>
> > Who doesn't meet the "high bar" and why? I know "high bar" has a lot of
> > meaning to you Twitter guys, since you all use the same term (a real example
> > of groupthink, BTW), but it means nothing to us. Tell us where this high bar
> > is exactly, by showing examples of not reaching it. Then we can learn and
> > improve, rather than guessing at what you mean.
>
> > Nobody here would bitch and moan if they didn't really want to learn
> > something. Please, help us by giving us examples.
>
> > On Mon, Mar 14, 2011 at 12:07 AM, Matt Harris  wrote:
>
> >> Innovation and development with the APIs are not being prevented. There
> >> have always been guidelines, and rules of the road so we all know what is
> >> and isn't allowed.
>
> >> If you build a client you are touching the majority of Twitter features.
> >> The APIs allow you to do this, and Twitter and your users trust you to use
> >> them in the way the terms or service allow. The high bar covers your use of
> >> these methods, and how you present inf

[twitter-dev] Re: consistency and ecosystem opportunities

[Dewald Pretorius]

Sometimes it takes just a slightly different perspective for the sun
to raise its head above the horizon of the blatantly obvious. And
everything suddenly makes perfect sense.

In other news, Echofon Pro is a better iPhone client, IMHO.

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

[twitter-dev] Re: consistency and ecosystem opportunities

[Dewald Pretorius]

Raffi, now is the right time to ask for a raise. Just saying...


On Mar 13, 8:09 pm, Ryan Sarver  wrote:
> To be clear, Raffi is clearly articulating the situation. It's a complex
> thing and we can't expect to get it perfectly right the first time, so the
> dialogue and questions are great.
>
> Raffi is also a much better communicator than I am :)
>
> --
> Ryan Sarver
> @rsarver 
>
> On Sun, Mar 13, 2011 at 4:04 PM, Craig  wrote:
> > Yes, Raffi's posts have made me feel a *lot* better about all of this. I
> > hope his comments will be reflected in some way by an 'official' message
> > from Twitter. It's not that I don't believe Raffi, I do, but it bothers me
> > that Ryan or someone hasn't yet come back to explicitly confirm Raffi's
> > comments (which, it should be noted, came with a disclaimer).
>
> > -Craig
>
> > On 13 March 2011 11:38, Rich  wrote:
>
> >> Similar situation, although Raffi's response above is slightly more
> >> reassuring.
>
> >> On Mar 13, 3:34 pm, Jef Poskanzer  wrote:
> >> > I have a set of apps that basically just reproduces the official
> >> > Twitter user experience, exactly what Twitter says we should not do.
> >> > However, I add value by running on a platform that Twitter does not
> >> > support and is unlikely to ever support.  I believe this should be
> >> > allowed and encouraged and would appreciate a statement to that
> >> > effect.
>
> >> > Furthermore, this is probably not the only exception to the "don't
> >> > just reproduce Twitter" rule.  Please consider that there may be
> >> > entire areas of innovation that you have not thought of - that's why
> >> > it's called innovation.
>
> >> --
> >> Twitter developer documentation and resources:http://dev.twitter.com/doc
> >> API updates via Twitter:http://twitter.com/twitterapi
> >> Issues/Enhancements Tracker:
> >>http://code.google.com/p/twitter-api/issues/list
> >> Change your membership to this group:
> >>http://groups.google.com/group/twitter-development-talk
>
> >  --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:
> >http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group:
> >http://groups.google.com/group/twitter-development-talk

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

[twitter-dev] Re: consistency and ecosystem opportunities

[Dewald Pretorius]

Raffi,

Can you (Twitter) please get your message straight?

Here's what Ryan said, "More specifically, developers ask us if they
should build client apps that mimic or reproduce the mainstream
Twitter consumer client experience.  The answer is no."

No you're saying something different. So, which is it?

On Mar 13, 6:23 pm, Raffi Krikorian  wrote:
> i don't think we've said its a waste of time, especially for something like
> dabr.  and, again, its not that we're stopping the competition -- we've said
> that if you are building a regular timeline client, we're going to be
> holding you to a higher bar.  in our opinion, its not a good -business- to
> be in.  i would love to see dabr, and other smaller, niche clients that are
> done out of enjoyment of coding, love of programming, etc. to continue!
>
>
>
> On Sun, Mar 13, 2011 at 11:25 AM, artesea  wrote:
> > Except every day I hear people go "I hate new twitter", "I want
> > feature y", "I wish it didn't do that".
> > I run a port of dabr, I don't do it for the money (no ads on the site)
> > I do it for the love of programming. Working out ways to get thumbnail
> > images in to the timeline. To have different displays depending on the
> > device or choice of the user. Being able to come up with an idea
> > whilst at work, and 2 hours at the keyboard when I get home to have it
> > working.
>
> > The number of users on my client is probably five, but I'm finding it
> > odd that Twitter insist that I'm wasting my efforts.
> > If you are so confident that you have a large enough market of the
> > timeline clients why stop competition?
>
> > Ryan
> > ps, I'm guessing that I'm counted in the 90% who "use" a twitter
> > client, but it's install on my android device any is only used to sync
> > up to my contacts.
>
> > On Mar 13, 4:38 am, Raffi Krikorian  wrote:
> > > hey adam.
>
> > > i can't speak officially and definitively, however, we don't think there
> > are
> > > as many business opportunities in making a piece of software that
> > > *simply* renders
> > > any of our timeline methods
> > (/1/statuses/home_timeline,/1/statuses/mentions,
> > > lists, etc.).  that's your #1.
>
> > > you're right, we do think there is a lot to be done with tweet
> > > summarization, curation, selection, matching, etc.  focus your efforts on
> > > that and just follow our lead with tweet rendering and interaction.
>
> > > does that help?
>
> > > On Sat, Mar 12, 2011 at 7:45 PM, Adam Green <140...@gmail.com> wrote:
> > > > Can we get a definition of "client?" This seems to be where we are
> > talking
> > > > across each other.
>
> > > > 1.  Twitter HQ sees a client as an app that displays *only* a user's
> > home
> > > > time line and allows the user to tweet, retweet, follow, etc.
>
> > > > 2.  Developers see a client as an app that displays tweets from any
> > source,
> > > > including the home timeline *and* those that are curated by editors and
> > > > algorithms, and allows the user to tweet, retweet, follow, etc.
>
> > > > I think to Twitter HQ, these are two very different things. I believe
> > that
> > > > this is what Ryan was trying to say. I believe that Ryan was trying to
> > say,
> > > > don't build apps that *only* do 1. You will have more luck with 2.
> > > > Developers heard don't build apps that do 2 or you will be instantly
> > shut
> > > > down.
>
> > > > If Ryan hadn't combined his message with things that inadvertently also
> > > > were perceived as a threat of instant shutdown as a result of an
> > innocent
> > > > misunderstanding of the rules, his statement would have been taken as
> > > > advice, rather than a threat. I believe he meant well. He failed. He
> > should
> > > > keep trying until everyone understands. That is his job. Or it should
> > at
> > > > least be someone's job. Collectively the developers are worth the
> > effort.
>
> > > > Hey, why not hold a conference, put everyone together, and talk until
> > this
> > > > is clear? You can afford it. We all need it.
>
> > > > Your future IPO investors aren't stupid. Well, at least not all of
> > them. It
> > > > is not just your revenue numbers they will see. It is lots of either
> > happy
> > > > or unhappy developers. We will raise your valuation. Keep saying that
> > to
> > > > Dick and the Board. They need to understand that.
>
> > > > On Sat, Mar 12, 2011 at 10:26 PM, Raffi Krikorian  > >wrote:
>
> > > >> is the "twitter client" what's the most useful thing there?  i would
> > think
> > > >> the algorithms and system to match tweets to that content is the most
> > > >> fruitful place for entrepreneurship?
>
> > > >> On Sat, Mar 12, 2011 at 7:22 PM, Shannon Whitley <
> > > >> shannon.whit...@gmail.com> wrote:
>
> > > >>> Thanks, Raffi, but obviously I'm not the only one reaching these
> > > >>> conclusions.  If our interpretation is incorrect, then the policy
> > > >>> isn't clear.
>
> > > >>> Television shows, newspaper articles, and band pages are perfect
> > > >>> examples of places where 

[twitter-dev] Re: consistency and ecosystem opportunities

[Dewald Pretorius]

Ed,

I don't have an issue with the size, placing, or color of the #DickBar
box. I have an issue with the fact that it shoves stuff in my face
that is of absolutely no interest to me.

Google got ads right. When your search results include a list of news
articles about the Japan earthquake, they don't show ads next to them
that yell, "#WHATNOTTOSAYTOAFATWOMAN".

On Mar 13, 4:18 pm, "M. Edward (Ed) Borasky"  wrote:
>  On Sun, 13 Mar 2011 11:49:45 -0700 (PDT), Dewald Pretorius
>
>
>
>   wrote:
> > I used to be counted in the 90% until they defaced Tweetie, sorry,
> > Twitter for iPhone with that moronic #DickBar that shoves irrelevant
> > nonsense in your face. It's like yelling at you, "I KNOW YOU DON'T
> > WANT TO SEE THIS AND HAVE NO INTEREST IN THIS, BUT HERE, TAKE IT
> > ANYWAY. LEARN #WHATNOTTOSAYTOAFATWOMAN AND TRY TO
> > #FARTLIKEJUSTINBIEBER AND OH, JUST WHILE YOU'RE AT IT, HERE'S ANOTHER
> > STUPID ONE THAT'S NOT TRENDING AT ALL, BUT SOMEONE PAID US TO SHOVE
> > IT
> > IN YOUR FACE!!!"
>
> > Are any of you guys developing a better Twitter client for iPhone,
> > because I'll switch in a heartbeat.
>
> > Oh...
>
> > Wait
>
>  Dewald, you have to remember that Twitter isn't the only granfalloon
>  that one must deal with on the iPhone - there's Apple, too. If Steve
>  Jobs didn't like the #DickBar, how long do you suppose it would last?
>  ;-)
>
> --
>  http://twitter.com/znmebhttp://borasky-research.net
>
>  "A mathematician is a device for turning coffee into theorems." -- Paul
>  Erdős

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

[twitter-dev] Re: consistency and ecosystem opportunities

[Dewald Pretorius]

You're missing the next step, Scott. The #DickBar will become
mandatory for all clients.

On Mar 13, 3:54 pm, Scott Wilcox  wrote:
> You still have the ability to change to a newly developed client if you want 
> to.
>
> Sent from my iPhone
>
> On 13 Mar 2011, at 18:50, "Dewald Pretorius"  wrote:
>
> > I used to be counted in the 90% until they defaced Tweetie, sorry,
> > Twitter for iPhone with that moronic #DickBar that shoves irrelevant
> > nonsense in your face. It's like yelling at you, "I KNOW YOU DON'T
> > WANT TO SEE THIS AND HAVE NO INTEREST IN THIS, BUT HERE, TAKE IT
> > ANYWAY. LEARN #WHATNOTTOSAYTOAFATWOMAN AND TRY TO
> > #FARTLIKEJUSTINBIEBER AND OH, JUST WHILE YOU'RE AT IT, HERE'S ANOTHER
> > STUPID ONE THAT'S NOT TRENDING AT ALL, BUT SOMEONE PAID US TO SHOVE IT
> > IN YOUR FACE!!!"
>
> > Are any of you guys developing a better Twitter client for iPhone,
> > because I'll switch in a heartbeat.
>
> > Oh...
>
> > Wait
>
> > On Mar 13, 3:25 pm, artesea  wrote:
> >> Except every day I hear people go "I hate new twitter", "I want
> >> feature y", "I wish it didn't do that".
> >> I run a port of dabr, I don't do it for the money (no ads on the site)
> >> I do it for the love of programming. Working out ways to get thumbnail
> >> images in to the timeline. To have different displays depending on the
> >> device or choice of the user. Being able to come up with an idea
> >> whilst at work, and 2 hours at the keyboard when I get home to have it
> >> working.
>
> >> The number of users on my client is probably five, but I'm finding it
> >> odd that Twitter insist that I'm wasting my efforts.
> >> If you are so confident that you have a large enough market of the
> >> timeline clients why stop competition?
>
> >> Ryan
> >> ps, I'm guessing that I'm counted in the 90% who "use" a twitter
> >> client, but it's install on my android device any is only used to sync
> >> up to my contacts.
>
> >> On Mar 13, 4:38 am, Raffi Krikorian  wrote:
>
> >>> hey adam.
>
> >>> i can't speak officially and definitively, however, we don't think there 
> >>> are
> >>> as many business opportunities in making a piece of software that
> >>> *simply* renders
> >>> any of our timeline methods 
> >>> (/1/statuses/home_timeline,/1/statuses/mentions,
> >>> lists, etc.).  that's your #1.
>
> >>> you're right, we do think there is a lot to be done with tweet
> >>> summarization, curation, selection, matching, etc.  focus your efforts on
> >>> that and just follow our lead with tweet rendering and interaction.
>
> >>> does that help?
>
> >>> On Sat, Mar 12, 2011 at 7:45 PM, Adam Green <140...@gmail.com> wrote:
> >>>> Can we get a definition of "client?" This seems to be where we are 
> >>>> talking
> >>>> across each other.
>
> >>>> 1.  Twitter HQ sees a client as an app that displays *only* a user's home
> >>>> time line and allows the user to tweet, retweet, follow, etc.
>
> >>>> 2.  Developers see a client as an app that displays tweets from any 
> >>>> source,
> >>>> including the home timeline *and* those that are curated by editors and
> >>>> algorithms, and allows the user to tweet, retweet, follow, etc.
>
> >>>> I think to Twitter HQ, these are two very different things. I believe 
> >>>> that
> >>>> this is what Ryan was trying to say. I believe that Ryan was trying to 
> >>>> say,
> >>>> don't build apps that *only* do 1. You will have more luck with 2.
> >>>> Developers heard don't build apps that do 2 or you will be instantly shut
> >>>> down.
>
> >>>> If Ryan hadn't combined his message with things that inadvertently also
> >>>> were perceived as a threat of instant shutdown as a result of an innocent
> >>>> misunderstanding of the rules, his statement would have been taken as
> >>>> advice, rather than a threat. I believe he meant well. He failed. He 
> >>>> should
> >>>> keep trying until everyone understands. That is his job. Or it should at
> >>>> least be someone's job. Collectively the developers are worth the effort.
>
>

[twitter-dev] Re: consistency and ecosystem opportunities

[Dewald Pretorius]

I used to be counted in the 90% until they defaced Tweetie, sorry,
Twitter for iPhone with that moronic #DickBar that shoves irrelevant
nonsense in your face. It's like yelling at you, "I KNOW YOU DON'T
WANT TO SEE THIS AND HAVE NO INTEREST IN THIS, BUT HERE, TAKE IT
ANYWAY. LEARN #WHATNOTTOSAYTOAFATWOMAN AND TRY TO
#FARTLIKEJUSTINBIEBER AND OH, JUST WHILE YOU'RE AT IT, HERE'S ANOTHER
STUPID ONE THAT'S NOT TRENDING AT ALL, BUT SOMEONE PAID US TO SHOVE IT
IN YOUR FACE!!!"

Are any of you guys developing a better Twitter client for iPhone,
because I'll switch in a heartbeat.

Oh...

Wait


On Mar 13, 3:25 pm, artesea  wrote:
> Except every day I hear people go "I hate new twitter", "I want
> feature y", "I wish it didn't do that".
> I run a port of dabr, I don't do it for the money (no ads on the site)
> I do it for the love of programming. Working out ways to get thumbnail
> images in to the timeline. To have different displays depending on the
> device or choice of the user. Being able to come up with an idea
> whilst at work, and 2 hours at the keyboard when I get home to have it
> working.
>
> The number of users on my client is probably five, but I'm finding it
> odd that Twitter insist that I'm wasting my efforts.
> If you are so confident that you have a large enough market of the
> timeline clients why stop competition?
>
> Ryan
> ps, I'm guessing that I'm counted in the 90% who "use" a twitter
> client, but it's install on my android device any is only used to sync
> up to my contacts.
>
> On Mar 13, 4:38 am, Raffi Krikorian  wrote:
>
> > hey adam.
>
> > i can't speak officially and definitively, however, we don't think there are
> > as many business opportunities in making a piece of software that
> > *simply* renders
> > any of our timeline methods (/1/statuses/home_timeline,/1/statuses/mentions,
> > lists, etc.).  that's your #1.
>
> > you're right, we do think there is a lot to be done with tweet
> > summarization, curation, selection, matching, etc.  focus your efforts on
> > that and just follow our lead with tweet rendering and interaction.
>
> > does that help?
>
> > On Sat, Mar 12, 2011 at 7:45 PM, Adam Green <140...@gmail.com> wrote:
> > > Can we get a definition of "client?" This seems to be where we are talking
> > > across each other.
>
> > > 1.  Twitter HQ sees a client as an app that displays *only* a user's home
> > > time line and allows the user to tweet, retweet, follow, etc.
>
> > > 2.  Developers see a client as an app that displays tweets from any 
> > > source,
> > > including the home timeline *and* those that are curated by editors and
> > > algorithms, and allows the user to tweet, retweet, follow, etc.
>
> > > I think to Twitter HQ, these are two very different things. I believe that
> > > this is what Ryan was trying to say. I believe that Ryan was trying to 
> > > say,
> > > don't build apps that *only* do 1. You will have more luck with 2.
> > > Developers heard don't build apps that do 2 or you will be instantly shut
> > > down.
>
> > > If Ryan hadn't combined his message with things that inadvertently also
> > > were perceived as a threat of instant shutdown as a result of an innocent
> > > misunderstanding of the rules, his statement would have been taken as
> > > advice, rather than a threat. I believe he meant well. He failed. He 
> > > should
> > > keep trying until everyone understands. That is his job. Or it should at
> > > least be someone's job. Collectively the developers are worth the effort.
>
> > > Hey, why not hold a conference, put everyone together, and talk until this
> > > is clear? You can afford it. We all need it.
>
> > > Your future IPO investors aren't stupid. Well, at least not all of them. 
> > > It
> > > is not just your revenue numbers they will see. It is lots of either happy
> > > or unhappy developers. We will raise your valuation. Keep saying that to
> > > Dick and the Board. They need to understand that.
>
> > > On Sat, Mar 12, 2011 at 10:26 PM, Raffi Krikorian 
> > > wrote:
>
> > >> is the "twitter client" what's the most useful thing there?  i would 
> > >> think
> > >> the algorithms and system to match tweets to that content is the most
> > >> fruitful place for entrepreneurship?
>
> > >> On Sat, Mar 12, 2011 at 7:22 PM, Shannon Whitley <
> > >> shannon.whit...@gmail.com> wrote:
>
> > >>> Thanks, Raffi, but obviously I'm not the only one reaching these
> > >>> conclusions.  If our interpretation is incorrect, then the policy
> > >>> isn't clear.
>
> > >>> Television shows, newspaper articles, and band pages are perfect
> > >>> examples of places where a "Twitter client" might be useful.  I could
> > >>> build a full-featured Twitter client around a single news site and
> > >>> that might be the perfect solution for that set of users.  Under the
> > >>> new guidelines, it sounds like I'd be shutdown.
>
> > >>> On Mar 12, 6:39 pm, Raffi Krikorian  wrote:
> > >>> > in reading your blog post, i think you're misunderstanding what

[twitter-dev] Re: consistency and ecosystem opportunities

[Dewald Pretorius]

Raffi,

You wrote, "...focus your efforts on that and just follow our lead
with tweet rendering and interaction".

This approach perpetuates and aggravates the fears and hostility in
the developer community that you (Twitter) sprouted when you bought
Tweetie, and absolutely nothing has been said or done by Twitter to
address or allay any fears or concerns that Twitter will, soon or at
some point in the future, rake in another segment of developer-
provided functionality.

Since so much money and potential lie in analytics, it will not
surprise me in the least if that will be the target of Twitter's next
take-over.

You've already clearly illustrated:

a) The willingness and capability to grab a segment away from the
ecosystem;

b) The willingness and capability to guide and even force developers
out of that segment.

Meaning, you have the blueprint of how to do it to any of the other
segments that you're now encouraging developers to focus on. This is
like deja vu. It's the pre-Chirp discussion all over again. Much has
changed and nothing has changed.

Twitter has not yet answered the following question, even though it is
a question on everyone's minds and has been since last year:

"Why should anyone believe you will not encroach and push developers
out of the segments that you now encourage them to focus on?"

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

[twitter-dev] Re: consistency and ecosystem opportunities

[Dewald Pretorius]

The most telling change in the Terms of Service occurred in sentence
#2 or paragraph #1 under section Rules of the Road.

It used to read: "We want to empower our ecosystem partners to build
valuable BUSINESSES around the information flowing through Twitter."

It now (since March 11, 2011) reads: "We want to empower our ecosystem
partners to build valuable TOOLS around the information flowing
through Twitter."

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

[twitter-dev] Re: Apps that Site Hack

[Dewald Pretorius]

Apart from implementing reCAPTCHA on tweet submission, follow, and
unfollow, I can't see what Twitter can do to prevent that kind of
abuse (can you imagine the revolt by bona fide users?). How else do
you determine that it is an actual human and not a piece of automated
software behind the browser on the user's desktop or laptop? The only
other option is legally, and that depends on the country of residence
of the owners of the software. At this point in time, it appears that
anyone who is able to and have the inclination to write desktop
software that bypasses the API might have carte blanche to do so.

On Feb 24, 7:00 am, Alan Hamlyn  wrote:
> Spam applications like Tweetadder, TheTweetTank and many others like
> it are currently hacking the website to get round oauth and basic auth
> restrictions - what is Twitter doing to level the playing field for
> serious developers who use oauth and follow Twitter guidelines?
>
> Many thanks in advance,
>
> Alan Hamlyn
> MarketMeSuite

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

[twitter-dev] Re: Follower analysis without whitelisting breaks limits?

[Dewald Pretorius]

Thanks Tim. So the point is, we still need to rely on the follower ids
list API method if we want to maintain an up to date picture of an
account's followers. For larger accounts this becomes impractical with
a limit of 350 calls per hour.

On Feb 15, 4:13 am, Tim Haines  wrote:
> It sends you an event when our subject user follows someone else, unfollows
> someone else, or when they are followed by someone else.  It does not send
> an event when they are unfollowed by someone else.
>
> Tim.
>
>
>
> On Tue, Feb 15, 2011 at 3:08 AM, Dewald Pretorius  wrote:
> > If I remember correctly, Site Streams sends you a transaction only
> > when the user follows another user (adding to Following). It does not
> > send you a transaction when someone else follows that user (adding to
> > Followers). I don't know if this work the same in User Streams.
> > Clarification by Twitter will be appreciated.
>
> > On Feb 14, 12:38 pm, David Giamanco  wrote:
> > > I believe the new way to do this is to initially call the REST API to get
> > > all of the ids for the first time you process this user. Then you setup a
> > > User Stream on the user and process any requests that come in through
> > there.
> > > For your uses, if you only show users the differences in follower counts
> > > then you don't need the initial call to the REST API to collect all ids.
> > All
> > > you need is a count of the ids and then to initiate a User Stream. The
> > User
> > > Stream will give you the differences in real time and you can store just
> > the
> > > differences, instead of the entire set of ids.
>
> > > David Giamanco
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:
> >http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group:
> >http://groups.google.com/group/twitter-development-talk

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

[twitter-dev] Re: Follower analysis without whitelisting breaks limits?

[Dewald Pretorius]

If I remember correctly, Site Streams sends you a transaction only
when the user follows another user (adding to Following). It does not
send you a transaction when someone else follows that user (adding to
Followers). I don't know if this work the same in User Streams.
Clarification by Twitter will be appreciated.

On Feb 14, 12:38 pm, David Giamanco  wrote:
> I believe the new way to do this is to initially call the REST API to get
> all of the ids for the first time you process this user. Then you setup a
> User Stream on the user and process any requests that come in through there.
> For your uses, if you only show users the differences in follower counts
> then you don't need the initial call to the REST API to collect all ids. All
> you need is a count of the ids and then to initiate a User Stream. The User
> Stream will give you the differences in real time and you can store just the
> differences, instead of the entire set of ids.
>
> David Giamanco

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

[twitter-dev] Re: Twitter Development platform - A Rant

[Dewald Pretorius]

If you're basing your business on the Search API it definitely sounds
as if you're not aware yet of the [mostly unofficially documented]
limits and constraints [mostly just alluded to by John Kalucki and
others through their exhortations on this list for people to rather
use the Streaming API] on using the Search API.

If your application is based on the assumption that you can throw an
unlimited [or even just a reasonably elevated] number of queries at
the Search API as and when your app needs scaling or hits a volume
spike, you will be wise to rethink your approach.

On Feb 13, 4:03 pm, Umashankar Das  wrote:
>      We ,as a team , have planned on working with a worst case scenario.
> twitter's search API is very important to us. We never planned for
> whitelisting, we dont need it.  The only worry is if tomorrow, (hopefully),
> if we generate traffic from our product, will twitter just stop the 'SEARCH
> API' . We need to know that.

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

[twitter-dev] Re: Twitter + Gnip Partnership

[Dewald Pretorius]

John,

I'm not sure how you draw that comparison. Google/Yahoo/Microsoft do
not sell the content of the sites that they index. Neither do
WordPress or Blogger sell the content of the blog posts. Facebook/Buzz
do not sell the content of people's status updates. They monetize
"around" the content, with ads, etc., just as Twitter does with
promoted content.

This is not a question of right or wrong. The Twitter TOS make it
clear that you can / will provide the content to third-parties with no
compensation to Twitter users.

I'm just trying to figure out who else uses the same business model.

On Nov 18, 12:48 am, John Kalucki  wrote:
> Every search engine, social network, blogging platform, content aggregator,
> and to a certain extent, every used book store and used record store...
>
> -John
>
> On Wed, Nov 17, 2010 at 1:04 PM, Dewald Pretorius  wrote:
> > As a business model, is there another company that takes content,
> > which its users create and enter into the company's service with no
> > compensation, and then turns around and sells that content to third
> > parties, still with no compensation to the creators of the content?
>
> > I've been trying to think of another company that does this, but I'm
> > striking a blank. I'm sure there must be others.
>
> > On Nov 17, 4:55 pm, Adam Green <140...@gmail.com> wrote:
> > > Ryan, I understand. I'm just happy to see you help companies put a
> > > real value on Twitter data in any form. And I'm happy to see Twitter
> > > find new ways to make money. You'll never hear "everything online must
> > > be free" from me.  I go way back to when people paid for software, in
> > > a box, in stores.
>
> > > I'm also willing to bet that Twitter will eventually allow a paid
> > > market to develop in actual tweets as well as data derived from them.
> > > When Twitter IPOs, the market will demand that. Paying a third party
> > > to filter and rank tweets that can be displayed on a website seems
> > > perfectly legitimate. Why should every company have to pay to do their
> > > own API programming to display aggregated tweets, when they can pay
> > > someone for high quality tweets as a service? It seems illogical to
> > > me, and from the point of view of the tweet's author, the copyright
> > > issues are identical.
>
> > > On Wed, Nov 17, 2010 at 3:31 PM, Ryan Sarver 
> > wrote:
> > > > Adam, it's a good question and it really comes down to what you are
> > > > trying to re-sell.
>
> > > > Re-syndication or re-sale of the actual tweets is strictly prohibited
> > > > and won't change on our end. We are however, ok with reselling of data
> > > > that results from analysis of the Twitter API.
>
> > > > So a great example is Klout. They do a lot of work to determine a
> > > > user's Klout score by analyzing the Twitter API and the content of
> > > > tweets. They *are* able to resell their score, but they would not be
> > > > able to resell the tweets that were used to determine that score.
>
> > > > It's nuanced, so let me know if that makes sense.
>
> > > > On Wed, Nov 17, 2010 at 12:55 PM, Adam Green <140...@gmail.com> wrote:
> > > >> Ryan:
>
> > > >> Shannon raises a lot of great points, but I'd like to hear more about
> > > >> the issue of reselling data derived from a purchased stream. Right now
> > > >> the TOS says that you can't resell data from the API. I've been
> > > >> telling clients that eventually Twitter will decide to make money from
> > > >> the API, and when that happens there would have to be a way to resell
> > > >> what has been paid for. Now that you are selling access to the API,
> > > >> which I strongly agree with, will you allow a free market to evolve
> > > >> around that by making it possible for Twitter data retailers to grow
> > > >> businesses, as well as wholesalers like Gnip? Please, say yes. I'm
> > > >> hoping an Apple-style, control the distribution channel completely
> > > >> mindset doesn't develop at Twitter.  I'm hoping Twitter wants to help
> > > >> the developer ecosystem turn into a true third party market. Letting
> > > >> developers sell data or help clients sell data is essential for that.
>
> > > >> On Wed, Nov 17, 2010 at 1:27 PM, Shannon Clark <
> > shannon.cl...@gmail.com> wrote:
> >

[twitter-dev] Re: Twitter + Gnip Partnership

[Dewald Pretorius]

ing the new
> >>> Mentions feed from Gnip cannot display the underlying Tweets that are
> >>> returned by that feed? This would seem to severely limit the value and
> >>> utility of such analytics to many businesses (who might want to reply to
> >>> many of those messages, might want to follow people on Twitter discussing
> >>> their company/brand/industry/competitors, and in almost all cases will 
> >>> want
> >>> to view the full Tweet w/rich metadata not just a summarization of #s of
> >>> tweets etc.)
>
> >>> And/or would a business focused Twitter client - CoTweet, Hootsuite,
> >>> Tweetdeck etc be able to offer (perhaps as part of a professional version)
> >>> such enhanced Mentions feeds and display them within that application?
>
> >>> thanks,
>
> >>> Shannon
>
> >>> (I'm not an active developer at the moment but I am consulting some 
> >>> business
> >>> clients on a range of social media tools and as analytics and the
> >>> appropriate use of them is a core part of my recommendations I'm following
> >>> these developments closely and look forward to I hope new competitors in 
> >>> the
> >>> analytics space soon)
>
> >>> -
> >>> Real Things -http://realthings.posterous.com/
> >>> Slow Brand -http://slowbrand.com
> >>> Searching for the Moon -http://shannonclark.wordpress.com
> >>> -
> >>> cell: 1.510.333.0295 Twitter - rycaut
>
> >>> On Wed, Nov 17, 2010 at 10:09 AM, Ryan Sarver  wrote:
>
> >>>> Dewald,
>
> >>>> The basic levels of all of the streaming APIs -- Spritzer, Follow,
> >>>> Track -- will remain open, free and direct from us. Elevated levels
> >>>> for non-display use will be served through Gnip.
>
> >>>> Hope that answers the question.
>
> >>>> Best, Ryan
>
> >>>> On Wed, Nov 17, 2010 at 5:44 PM, Dewald Pretorius 
> >>>> wrote:
> >>>> > Ryan,
>
> >>>> > The Gnip blog post states:
>
> >>>> > [QUOTE]Twitter Decahose. This volume-based product is comprised of 10%
> >>>> > of the full firehose. Starting today, developers who want to access
> >>>> > this sample rate will access it via Gnip instead of Twitter. Twitter
> >>>> > will also begin to transition non-display developers with existing
> >>>> > Twitter Gardenhose access over to Gnip.[/QUOTE]
>
> >>>> > How does this affect the basic statuses/sample method of the Streaming
> >>>> > API? Are you discontinuing it? If so, when?
>
> >>>> > --
> >>>> > Twitter developer documentation and resources:
> >>>> >http://dev.twitter.com/doc
> >>>> > API updates via Twitter:http://twitter.com/twitterapi
> >>>> > Issues/Enhancements Tracker:
> >>>> >http://code.google.com/p/twitter-api/issues/list
> >>>> > Change your membership to this group:
> >>>> >http://groups.google.com/group/twitter-development-talk
>
> >>>> --
> >>>> Twitter developer documentation and resources:http://dev.twitter.com/doc
> >>>> API updates via Twitter:http://twitter.com/twitterapi
> >>>> Issues/Enhancements Tracker:
> >>>>http://code.google.com/p/twitter-api/issues/list
> >>>> Change your membership to this group:
> >>>>http://groups.google.com/group/twitter-development-talk
>
> >>> --
> >>> Twitter 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
>
> >> --
> >> Adam Green
> >> Twitter API Consultant and Trainer
> >>http://140dev.com
> >> @140dev
>
> >> --
> >> 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
>
> --
> Adam Green
> Twitter API Consultant and Trainerhttp://140dev.com
> @140dev

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

[twitter-dev] Re: Twitter + Gnip Partnership

[Dewald Pretorius]

Ryan,

Gnip will have to extend the Twitter API Rules into their TOS,
otherwise good luck with enforcing the Twitter API Rules if the stream
consumer has a contract only with Gnip.

Your answer about elevated access answers my question about value.

For completeness, here's what ReadWriteWeb says about the prices:

Gnip will offer 50% of all the messages posted to Twitter for $360,000
per year, or 5% of all messages for $60,000 per year. [1]

http://www.readwriteweb.com/archives/twitter_to_sell_50_of_all_tweets_for_360kyear_thro.php

On Nov 17, 4:31 pm, Ryan Sarver  wrote:
> That's explicitly not true. You are bound by both the Twitter API
> Rules and Gnip's TOS
>
> On Wed, Nov 17, 2010 at 1:31 PM, Dewald Pretorius  wrote:
> > By the way, if you get Twitter data from Gnip, you are not bound to
> > the Twitter TOS. Your business and contractual relationship is with
> > Gnip, not Twitter.
>
> > On Nov 17, 3:28 pm, Dewald Pretorius  wrote:
> >> The minimum Gnip charge is $500 per month, with a minimum of a year
> >> contract, if you want to use Gnip in a production application.
>
> >> And that's before the -- still unknown -- additional access charges
> >> for the Twitter feeds.
>
> >> You can't use Gnip in a production application if you are not an
> >> incorporated business, so that excludes access for many developers,
> >> even if they can afford the charges.
>
> >> Maybe there's a secondary market here, for an incorporated business to
> >> provide access for one-man developers to Gnip data for a fee. Meaning,
> >> Reseller Inc subscribes to Gnip and gets the data feeds, and resells
> >> them to one-man developers. I haven't checked Gnip's TOS to see if
> >> that's expressly prohibited.
>
> >> On Nov 17, 2:51 pm, "M. Edward (Ed) Borasky" 
> >> research.net> wrote:
> >> > Ryan, what about User Streams? I'm building something around User
> >> > Streams but it is a "non-display" analytics application. Am I at risk
> >> > for Twitter inserting another business into *my* data stream as well?
> >> > And I'm curious how some of the other Streaming consumers are going to
> >> > react to insertion of a monopoly middleman into their data source. I
> >> > briefly dealt with Gnip a while back and found their API hard to use
> >> > and their pricing exorbitant.
> >> > --
> >> > M. Edward (Ed) Boraskyhttp://borasky-research.nethttp://twitter.com/znmeb
>
> >> > "A mathematician is a device for turning coffee into theorems." - Paul 
> >> > Erdos
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this 
> > group:http://groups.google.com/group/twitter-development-talk

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

[twitter-dev] Re: Twitter + Gnip Partnership

[Dewald Pretorius]

Adam, what I wrote was not a case for or against Gnip and/or Twitter
selling the stream through Gnip. I simply quoted Gnip prices and
conditions from the Gnip pricing page, because it is relevant to this
discussion.

This time I will venture further and say that I do not see where is
the value-add for the developer in getting his Twitter stream data
from Gnip instead of directly from Twitter. Perhaps it's because the
details on Gnip's site are still very scant on the Twitter feeds, or
perhaps it's a deal where only the benefits for Twitter and Gnip were
fully considered. I'd love to hear what are the benefits for the
developer.

On Nov 17, 3:49 pm, Adam Green <140...@gmail.com> wrote:
> Dewald, I can't speak for Twitter, but I think you are missing the
> path they seem to be building. As an independent developer you can
> still use the streaming API at the default level of 400 keywords and
> 5,000 follows for free. That is plenty to get a site started or build
> a proof of concept for a client at no cost. If the site gets traction
> or a client likes it, then you charge for it and get the money to
> scale up. The client could be the corporate purchaser of the feed, or
> if you have a site that charges for access, then you'd be crazy not to
> get limited liability by incorporating as an LLC or S corp. That costs
> $500 to file for in most states.
>
> I have no idea what Gnip's final prices will be. If they are
> exhorbitant, Twitter will either die, or they will give wholesale
> status to multiple vendors and let the market figure out the wholesale
> price. I think they are smart enough to choose the later. The big
> thing, the REALLY BIG thing, is that I just used the word price twice
> in relation to Twitter. That means people will pay for Twitter stuff.
> That means developers can get paid for Twitter stuff. Hooray! I like
> getting paid. I don't mind paying others if it means I can also get
> paid. As long as everything is free, nobody gets paid.
>
> Don't you want to get paid for your work?
>
>
>
> On Wed, Nov 17, 2010 at 2:28 PM, Dewald Pretorius  wrote:
> > The minimum Gnip charge is $500 per month, with a minimum of a year
> > contract, if you want to use Gnip in a production application.
>
> > And that's before the -- still unknown -- additional access charges
> > for the Twitter feeds.
>
> > You can't use Gnip in a production application if you are not an
> > incorporated business, so that excludes access for many developers,
> > even if they can afford the charges.
>
> > Maybe there's a secondary market here, for an incorporated business to
> > provide access for one-man developers to Gnip data for a fee. Meaning,
> > Reseller Inc subscribes to Gnip and gets the data feeds, and resells
> > them to one-man developers. I haven't checked Gnip's TOS to see if
> > that's expressly prohibited.
>
> > On Nov 17, 2:51 pm, "M. Edward (Ed) Borasky"  > research.net> wrote:
> >> Ryan, what about User Streams? I'm building something around User
> >> Streams but it is a "non-display" analytics application. Am I at risk
> >> for Twitter inserting another business into *my* data stream as well?
> >> And I'm curious how some of the other Streaming consumers are going to
> >> react to insertion of a monopoly middleman into their data source. I
> >> briefly dealt with Gnip a while back and found their API hard to use
> >> and their pricing exorbitant.
> >> --
> >> M. Edward (Ed) Boraskyhttp://borasky-research.nethttp://twitter.com/znmeb
>
> >> "A mathematician is a device for turning coffee into theorems." - Paul 
> >> Erdos
>
> > --
> > 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
>
> --
> Adam Green
> Twitter API Consultant and Trainerhttp://140dev.com
> @140dev

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

[twitter-dev] Re: Twitter + Gnip Partnership

[Dewald Pretorius]

By the way, if you get Twitter data from Gnip, you are not bound to
the Twitter TOS. Your business and contractual relationship is with
Gnip, not Twitter.

On Nov 17, 3:28 pm, Dewald Pretorius  wrote:
> The minimum Gnip charge is $500 per month, with a minimum of a year
> contract, if you want to use Gnip in a production application.
>
> And that's before the -- still unknown -- additional access charges
> for the Twitter feeds.
>
> You can't use Gnip in a production application if you are not an
> incorporated business, so that excludes access for many developers,
> even if they can afford the charges.
>
> Maybe there's a secondary market here, for an incorporated business to
> provide access for one-man developers to Gnip data for a fee. Meaning,
> Reseller Inc subscribes to Gnip and gets the data feeds, and resells
> them to one-man developers. I haven't checked Gnip's TOS to see if
> that's expressly prohibited.
>
> On Nov 17, 2:51 pm, "M. Edward (Ed) Borasky" 
> research.net> wrote:
> > Ryan, what about User Streams? I'm building something around User  
> > Streams but it is a "non-display" analytics application. Am I at risk  
> > for Twitter inserting another business into *my* data stream as well?  
> > And I'm curious how some of the other Streaming consumers are going to  
> > react to insertion of a monopoly middleman into their data source. I  
> > briefly dealt with Gnip a while back and found their API hard to use  
> > and their pricing exorbitant.
> > --
> > M. Edward (Ed) Boraskyhttp://borasky-research.nethttp://twitter.com/znmeb
>
> > "A mathematician is a device for turning coffee into theorems." - Paul Erdos

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

[twitter-dev] Re: Twitter + Gnip Partnership

[Dewald Pretorius]

The minimum Gnip charge is $500 per month, with a minimum of a year
contract, if you want to use Gnip in a production application.

And that's before the -- still unknown -- additional access charges
for the Twitter feeds.

You can't use Gnip in a production application if you are not an
incorporated business, so that excludes access for many developers,
even if they can afford the charges.

Maybe there's a secondary market here, for an incorporated business to
provide access for one-man developers to Gnip data for a fee. Meaning,
Reseller Inc subscribes to Gnip and gets the data feeds, and resells
them to one-man developers. I haven't checked Gnip's TOS to see if
that's expressly prohibited.

On Nov 17, 2:51 pm, "M. Edward (Ed) Borasky"  wrote:
> Ryan, what about User Streams? I'm building something around User  
> Streams but it is a "non-display" analytics application. Am I at risk  
> for Twitter inserting another business into *my* data stream as well?  
> And I'm curious how some of the other Streaming consumers are going to  
> react to insertion of a monopoly middleman into their data source. I  
> briefly dealt with Gnip a while back and found their API hard to use  
> and their pricing exorbitant.
> --
> M. Edward (Ed) Boraskyhttp://borasky-research.nethttp://twitter.com/znmeb
>
> "A mathematician is a device for turning coffee into theorems." - Paul Erdos

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

[twitter-dev] Re: Twitter + Gnip Partnership

[Dewald Pretorius]

Ryan,

Thanks. Can I then suggest that you request Gnip to modify the
description of their Twitter Decahose feed. They refer to it as a
sample rate, which immediately creates confusion with your statuses/
sample.

On Nov 17, 2:09 pm, Ryan Sarver  wrote:
> Dewald,
>
> The basic levels of all of the streaming APIs -- Spritzer, Follow,
> Track -- will remain open, free and direct from us. Elevated levels
> for non-display use will be served through Gnip.
>
> Hope that answers the question.
>
> Best, Ryan
>
> On Wed, Nov 17, 2010 at 5:44 PM, Dewald Pretorius  wrote:
> > Ryan,
>
> > The Gnip blog post states:
>
> > [QUOTE]Twitter Decahose. This volume-based product is comprised of 10%
> > of the full firehose. Starting today, developers who want to access
> > this sample rate will access it via Gnip instead of Twitter. Twitter
> > will also begin to transition non-display developers with existing
> > Twitter Gardenhose access over to Gnip.[/QUOTE]
>
> > How does this affect the basic statuses/sample method of the Streaming
> > API? Are you discontinuing it? If so, when?
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this 
> > group:http://groups.google.com/group/twitter-development-talk

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

[twitter-dev] Re: Twitter + Gnip Partnership

[Dewald Pretorius]

Ryan,

The Gnip blog post states:

[QUOTE]Twitter Decahose. This volume-based product is comprised of 10%
of the full firehose. Starting today, developers who want to access
this sample rate will access it via Gnip instead of Twitter. Twitter
will also begin to transition non-display developers with existing
Twitter Gardenhose access over to Gnip.[/QUOTE]

How does this affect the basic statuses/sample method of the Streaming
API? Are you discontinuing it? If so, when?

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

[twitter-dev] Re: Streaming API and OAuth

[Dewald Pretorius]

Does that mean the application can use any active token that was
granted via the normal OAuth connections process to authenticate on
the Streaming API?

If that is so, then even just that information in the documentation
will be a help.

>From reading the documentation one cannot figure out whether you can
use any access token, or must request a token from an endpoint
specific to the Streaming API.

On Nov 8, 7:46 pm, Tom van der Woerdt  wrote:
> Streaming API doesn't differ from the REST API with it's authentication.
> Both use OAuth 1.0.
>
> Tom
>
> On 11/8/10 11:55 PM, Dewald Pretorius wrote:
>
> > Please update your documentation [1] for more detail information on
> > authenticating on the Streaming API with OAuth.
>
> > We need to know the same type of information that you currently
> > provide [2] for REST OAuth.
>
> > [1]http://developer.twitter.com/pages/stre0aming_api_concepts#authentica...
> > [2]http://developer.twitter.com/pages/auth

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

[twitter-dev] Streaming API and OAuth

[Dewald Pretorius]

Please update your documentation [1] for more detail information on
authenticating on the Streaming API with OAuth.

We need to know the same type of information that you currently
provide [2] for REST OAuth.

[1] http://developer.twitter.com/pages/stre0aming_api_concepts#authentication
[2] http://developer.twitter.com/pages/auth

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

[twitter-dev] Re: "Over the limit for this type of request, please wait a while and try again"

[Dewald Pretorius]

Matt,

I'm aware of those rate limits. I was referring to methods that used
to be, "Give us all you got," such as destroy friendship. For example,
create block, destroy block, etc.


On Oct 6, 3:38 pm, Matt Harris  wrote:
> Hi Dewald,
>
> There are other methods which are similarly rate limited. They are
> documented on our help center:
>    http://support.twitter.com/articles/15364
>
> The overview of rate limits on the developer site provides some more
> background about rate limits in general and then goes onto link to the
> above document. The overview is published here:
>    http://dev.twitter.com/pages/rate-limiting
>
> Hope that answers your question,
>
> @themattharris
> Developer Advocate, Twitterhttp://twitter.com/themattharris
>
>
>
> On Wed, Oct 6, 2010 at 8:13 AM, Dewald Pretorius  wrote:
> > Are any of the other POST methods now also similarly rate limited, or
> > is it only destroy friendship?
>
> > On Oct 5, 11:13 am, Taylor Singletary 
> > wrote:
> >> Hi James,
>
> >> I'll re-post this in the group thread as well.
>
> >> Due to potential abuse, we've begun locking down bulk deletions that were
> >> previously unbound. These lack of limits lead to many application
> >> suspensions and blacklisting as the lack of a rate limit was often
> >> interpreted as "give us all you've got, non stop," in addition to obvious
> >> system gaming.
>
> >> We're unfortunately not yet publishing the limits on these kinds of 
> >> actions.
> >> Though this limit is trickle-down reflected in the API, it's actually a
> >> site-wide construct. It's an IP-based limit, and not a user-based limit.
>
> >> As you'll most likely be able to discover the limits yourself, I'll work on
> >> getting these numbers released and hopefully get an X-FeatureRateLimit set
> >> of HTTP headers attached to these requests also.
>
> >> I would recommend developing the following strategy when you run into this
> >> error:
>
> >> - Back off for 5-6 minutes (stop retrying this specific kind of request)
> >> - Try the request again.
> >>   - If it succeeds, great, continue until you're limited again (or work on
> >> ways to never get limited, such as preventing bulk actions in your UI)
> >>   - If it fails again, wait another 2 minutes, retry & repeat.
>
> >> I think the current limits are pretty reasonable, and the time window
> >> refreshes often.
>
> >> The error will be a Error 420, Rate Limited. The error code embedded in
> >> either JSON or XML structures will be "33" and the accompanying message:
> >> "Over the limit for this type of request, please wait a while and try 
> >> again"
>
> >> Taylor Singletary
> >> @episod
>
> >> On Tue, Oct 5, 2010 at 1:56 AM, James Peter  wrote:
> >> > Hi folks,
>
> >> > Our service has been down for over 3 days now due to broken API calls.
>
> >> > Still waiting on any information from Twitter about what's going on,
> >> > but still in the dark.
>
> >> > About 3 days ago we started receiving messages (incorrectly in the new
> >> > error structure) saying "Over the limit for this type of request,
> >> > please wait a while and try again" with error code 33 when calling
> >> > friendships/destroy. According to the API docs, this call is not rate
> >> > limitedhttp://dev.twitter.com/doc/post/friendships/destroyAllour
> >> > API requests are authenticated with the requesting user.
>
> >> > This happens after about 100 calls. It makes our app completely
> >> > unusable. I'm guessing it's a bug, but after 3 days I'm wondering if
> >> > anyone else is seeing this problem. As the errors are returned in the
> >> > new error structure they didn't appear in our logs at first, so you
> >> > might be experiencing this problem and not noticing. The new error
> >> > structure returns a set of error messages under "errors" instead of
> >> > just a string under "error".
>
> >> > James
>
> >> > --
> >> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> >> > API updates via Twitter:http://twitter.com/twitterapi
> >> > Issues/Enhancements Tracker:
> >> >http://code.google.com/p/twitter-api/issues/list
> >> > Change your membership to this group:
> >> >http://groups.google.com/group/twitter-development-talk
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this 
> > group:http://groups.google.com/group/twitter-development-talk

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

[twitter-dev] Re: "Over the limit for this type of request, please wait a while and try again"

[Dewald Pretorius]

Are any of the other POST methods now also similarly rate limited, or
is it only destroy friendship?


On Oct 5, 11:13 am, Taylor Singletary 
wrote:
> Hi James,
>
> I'll re-post this in the group thread as well.
>
> Due to potential abuse, we've begun locking down bulk deletions that were
> previously unbound. These lack of limits lead to many application
> suspensions and blacklisting as the lack of a rate limit was often
> interpreted as "give us all you've got, non stop," in addition to obvious
> system gaming.
>
> We're unfortunately not yet publishing the limits on these kinds of actions.
> Though this limit is trickle-down reflected in the API, it's actually a
> site-wide construct. It's an IP-based limit, and not a user-based limit.
>
> As you'll most likely be able to discover the limits yourself, I'll work on
> getting these numbers released and hopefully get an X-FeatureRateLimit set
> of HTTP headers attached to these requests also.
>
> I would recommend developing the following strategy when you run into this
> error:
>
> - Back off for 5-6 minutes (stop retrying this specific kind of request)
> - Try the request again.
>   - If it succeeds, great, continue until you're limited again (or work on
> ways to never get limited, such as preventing bulk actions in your UI)
>   - If it fails again, wait another 2 minutes, retry & repeat.
>
> I think the current limits are pretty reasonable, and the time window
> refreshes often.
>
> The error will be a Error 420, Rate Limited. The error code embedded in
> either JSON or XML structures will be "33" and the accompanying message:
> "Over the limit for this type of request, please wait a while and try again"
>
> Taylor Singletary
> @episod
>
>
>
> On Tue, Oct 5, 2010 at 1:56 AM, James Peter  wrote:
> > Hi folks,
>
> > Our service has been down for over 3 days now due to broken API calls.
>
> > Still waiting on any information from Twitter about what's going on,
> > but still in the dark.
>
> > About 3 days ago we started receiving messages (incorrectly in the new
> > error structure) saying "Over the limit for this type of request,
> > please wait a while and try again" with error code 33 when calling
> > friendships/destroy. According to the API docs, this call is not rate
> > limitedhttp://dev.twitter.com/doc/post/friendships/destroyAll our
> > API requests are authenticated with the requesting user.
>
> > This happens after about 100 calls. It makes our app completely
> > unusable. I'm guessing it's a bug, but after 3 days I'm wondering if
> > anyone else is seeing this problem. As the errors are returned in the
> > new error structure they didn't appear in our logs at first, so you
> > might be experiencing this problem and not noticing. The new error
> > structure returns a set of error messages under "errors" instead of
> > just a string under "error".
>
> > James
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:
> >http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group:
> >http://groups.google.com/group/twitter-development-talk

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

[twitter-dev] Re: #newtwitter and the API

[Dewald Pretorius]

Is the URL format
http://twitter.com/themattharris
earmarked to be phased out at some point in the medium future?

In many places in my app the @username is linked to
http://twitter.com/username
and I will have to modify all those URLs to
http://twitter.com/#!/username
if the old format is going to disappear.

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

[twitter-dev] Re: Why is Basic Auth still enabled on some sources?

[Dewald Pretorius]

Ryan,

Proactive transparency in situations like these is very important,
because that is the only way not to undermine your own credibility.

Is there any way that the enforcement of rules can be made more equal
for all services and developers? The last issue I encountered (Brian
has the details) is where, a full four months after he asked me to
remove something, I noticed another service that is very well-known to
you, that is still doing exactly the same thing in a more egregious
form than what my service ever did. If it were a few days after I
could have chalked it up to still being in the process, but 4 months
cannot be chalked up to that.

And this is the second time that this kind of inequality has happened
to me.

On Sep 14, 1:09 pm, Ryan Sarver  wrote:
> Ed,
>
> As part of the migration we worked with many developers to help them with
> the transition and some of them, including our own Android app, had some
> extenuating circumstances that made them unable to make the date. For those
> few exceptions and extreme cases we granted them a stay of execution as long
> as they provided a reasonable timeline to make the transition.
>
> It pained us to do it for one of our own applications, but I'll give you
> some detail to help you understand why we needed to. And to be clear, we did
> this for a number of non-Twitter applications as well if we deemed their
> situation to be one that needed the stay as well. In the end all of the apps
> that got the stay were mobile apps that were unable to flash new versions
> out to devices on their own schedule and that includes the Android app on a
> number of devices.
>
> We have a hard shut-off date from Google which is only a few weeks away and
> from every other app that was given an exemption. Rest assured that EVERY
> app will be moved over in a timely fashion, so using their keys will only
> give you a short window to continue to use Basic Auth.
>
> When looking at all the possible options and scenarios, we think this was
> the right decision in order to move the entire ecosystem over to the new
> authentication model while also being reasonable when we needed to be.
>
> Best, Ryan
>
>
>
> On Mon, Sep 13, 2010 at 1:40 PM, funkatron  wrote:
> > Read on this post:http://blog.nelhage.com/2010/09/dear-twitter/
>
> > Tested just now:http://gist.github.com/577273
>
> > If I pass "source=twitterandroid", it appears to work on all API
> > methods.
>
> > In light of basic auth being "disabled," why does this work?
>
> > --
> > Ed Finkler
> >http://funkatron.com
> > @funkatron
> > AIM: funka7ron / ICQ: 3922133 / 
> > XMPP:funkat...@gmail.com
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:
> >http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group:
> >http://groups.google.com/group/twitter-development-talk?hl=en

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

[twitter-dev] Re: Why is Basic Auth still enabled on some sources?

[Dewald Pretorius]

They must have known that this was going to be discovered. We're
developers. We like building, testing, and breaking stuff.

Unequal applications of the rules. Happens all the time. Months after
you've disabled something at the request of Twitter, you find well-
known services that do exactly the same thing with apparent impunity
in a much worse form than you did.

On Sep 13, 10:40 am, funkatron  wrote:
> Read on this post:http://blog.nelhage.com/2010/09/dear-twitter/
>
> Tested just now:http://gist.github.com/577273
>
> If I pass "source=twitterandroid", it appears to work on all API
> methods.
>
> In light of basic auth being "disabled," why does this work?
>
> --
> Ed Finklerhttp://funkatron.com
> @funkatron
> AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com

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

[twitter-dev] t.co and fail whales

[Dewald Pretorius]

Twitter folks, how are you going to ensure that t.co links are not
affected by over-capacity situations on your infrastructure?

If you're routing t.co links through your existing infrastructure,
absolutely *everyone's* links are going to be broken when you start
throwing fail whales, even when the link is clicked in third-party
applications.

Are you running t.co on its own separate and dedicated infrastructure?

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

[twitter-dev] Re: all my client users report failed to validate oauth signature ...

[Dewald Pretorius]

I'm seeing a similar thing. Some of my users who have been OAuth
authorized for many weeks now suddenly get an invalid OAuth signature.

On Sep 1, 1:59 pm, mostafa farghaly  wrote:
> Hi,
> i switched to oauth since 2 weeks or so, and deprecated basic auth
> completely, and all my client users upgrade, and the app stats show
> that every thing is fine and they're enjoying oauth, yesterday i get
> the message failed to validate oauth signature , and all my client
> users report the same message, i believe that the application my be
> black listed because i do alot of requests during my development of
> iphone app? plz help.

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

[twitter-dev] Re: [twitter-api-announce] Announcing Site Streams Beta

[Dewald Pretorius]

John,

That page still says exactly the same.

On Aug 30, 5:24 pm, John Kalucki  wrote:
> It's cached. It'll update via a process that is mysterious to me.
>
>
>
> On Mon, Aug 30, 2010 at 1:21 PM, Dewald Pretorius  wrote:
> > John,
>
> > Is that page cached, because the third sentence of the first bullet
> > under Important Items still says *exactly* the same?
>
> > On Aug 30, 5:15 pm, John Kalucki  wrote:
> > > Thanks. I've clarified the language.
>
> > > -John
>
> > > On Mon, Aug 30, 2010 at 12:42 PM, Dewald Pretorius 
> > wrote:
> > > > John,
>
> > > > Perhaps you should then rephrase the following at
> > > >http://bit.ly/sitestream_doc
>
> > > > "One Site Streams graduates to production, sites must only use the
> > > > REST API for data that is not available through User Streams or as a
> > > > fall-back data source."
>
> > > > It's in the first paragraph of Important Items.
>
> > > > Here's another issue that probably needs to be considered.
>
> > > > It applies mostly to DMs, because people will tend to use DMs for
> > > > sensitive information, and would expect a certain level of privacy.
>
> > > > Right now, an OAuth authorized site can query a user's DMs and do with
> > > > that info what it likes. It could present privacy issues, but at least
> > > > you have an audit trail of the DM request by the authorized site in
> > > > your logs/system.
>
> > > > You lose that audit trail with Site Streams. The DMs are
> > > > indiscriminately distributed out to all OAuth authorized sites that
> > > > subscribe to the user's stream.
>
> > > > It may not seem like a big deal, because it's status quo minus the
> > > > audit trail. Until you're hit with a multi-million dollar class-action
> > > > lawsuit for indiscriminately distributing potentially sensitive
> > > > information. Then it is a big deal. It's not only the lawsuit, it's a
> > > > privacy PR disaster as well.
>
> > > > On Aug 30, 4:25 pm, John Kalucki  wrote:
> > > > > We're not forcing people over to Site Streams. If, on the other hand,
> > if
> > > > you
> > > > > start to consume Site Streams, we want you to stop regular polling on
> > the
> > > > > REST API.
>
> > > > > If your service is modest, any excess delivery will be modest.
> > Excessive
> > > > > options add complexity and slow development for what may be little
> > > > > practical efficiency gain. Bandwidth and CPU are nearly free at
> > > > 1mbit/sec.
> > > > > It's all a balance.
>
> > > > > -John Kaluckihttp://twitter.com/jkalucki
> > > > > Twitter, Inc.
>
> > > > > On Mon, Aug 30, 2010 at 12:15 PM, Dewald Pretorius 
> > > > wrote:
> > > > > > This is super news.
>
> > > > > > However, if you're going to force web services to use Site Streams
> > > > > > when it is in production ("sites must only use the REST API for
> > data
> > > > > > that is not available through User Streams"), then please add the
> > > > > > ability to subscribe only to certain elements. For example, we need
> > > > > > the ability to subscribe to only Follows, or to only Tweets and
> > > > > > Retweets, etc.
>
> > > > > > You make note that each stream may consume significant bandwidth (>
> > > > > > 1MB).
>
> > > > > > If a web service does not make use of the user's Follows, or of the
> > > > > > user's Tweets, then it makes no sense to consume that bandwidth
> > with
> > > > > > the dead-weight of the elements that are not used by the service.
>
> > > > > > I understand that Site Streams is in beta now. I'm putting in this
> > > > > > request for when it is in production and we are forced to use it.
>
> > > > > > --
> > > > > > Twitter developer documentation and resources:
> > > >http://dev.twitter.com/doc
> > > > > > API updates via Twitter:http://twitter.com/twitterapi
> > > > > > Issues/Enhancements Tracker:
> > > > > >http://code.google.com/p/twitter-api/issues/list
> > > > > > Change your membership to this group:
> > > > > >http://groups.google.com/group/twitter-development-talk?hl=en
>
> > > > --
> > > > Twitter developer documentation and resources:
> >http://dev.twitter.com/doc
> > > > API updates via Twitter:http://twitter.com/twitterapi
> > > > Issues/Enhancements Tracker:
> > > >http://code.google.com/p/twitter-api/issues/list
> > > > Change your membership to this group:
> > > >http://groups.google.com/group/twitter-development-talk?hl=en
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:
> >http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group:
> >http://groups.google.com/group/twitter-development-talk?hl=en

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

[twitter-dev] Re: [twitter-api-announce] Announcing Site Streams Beta

[Dewald Pretorius]

I think you're missing my point. A signed agreement does not prevent
anything for the evil-minded. At best it establishes the parameters
for damage control by Twitter (revoking access, banning, etc.), except
in this case Twitter won't have the forensics to determine who did the
damage.

On Aug 30, 5:44 pm, "M. Edward (Ed) Borasky"  wrote:
> Try getting access to Site Streams without a signed agreement between  
> your organization and Twitter prohibiting such shenanigans. ;-)
>
> --
> M. Edward (Ed) Boraskyhttp://borasky-research.nethttp://twitter.com/znmeb
>
> "A mathematician is a device for turning coffee into theorems." - Paul Erdos
>
> Quoting Dewald Pretorius :
>
>
>
> > Ed,
>
> > Developer responsibilities and developer agreements mean absolutely
> > nothing to that person who wants to abuse users' DMs.
>
> > In fact, they will probably trick users to authorize their app with a
> > neat feature, and then in the background collect received and sent
> > DMs.
>
> > Twitter will not have the foggiest idea of which service it could be,
> > because they will have no record of API requests, or pattern of
> > requests, for received and sent DMs.
>
> > On Aug 30, 5:15 pm, "M. Edward (Ed) Borasky"  > research.net> wrote:
> >> Quoting Dewald Pretorius :
>
> >> > Here's another issue that probably needs to be considered.
>
> >> > It applies mostly to DMs, because people will tend to use DMs for
> >> > sensitive information, and would expect a certain level of privacy.
>
> >> > Right now, an OAuth authorized site can query a user's DMs and do with
> >> > that info what it likes. It could present privacy issues, but at least
> >> > you have an audit trail of the DM request by the authorized site in
> >> > your logs/system.
>
> >> > You lose that audit trail with Site Streams. The DMs are
> >> > indiscriminately distributed out to all OAuth authorized sites that
> >> > subscribe to the user's stream.
>
> >> > It may not seem like a big deal, because it's status quo minus the
> >> > audit trail. Until you're hit with a multi-million dollar class-action
> >> > lawsuit for indiscriminately distributing potentially sensitive
> >> > information. Then it is a big deal. It's not only the lawsuit, it's a
> >> > privacy PR disaster as well.
>
> >> Ayup - *Twitter* loses an audit trail - they can track sends / TCP  
> >> acknowledgements but have no idea what the receiver is doing with the  
> >> packets. The consuming site must maintain an audit trail, though, right?
>
> >> Something like this happened at Facebook when they changed their  
> >> developer TOS. Here's the wording they used:
>
> >> ?You must give users control over their data by posting a privacy  
> >> policy that explains what data you collect, and how you will use,  
> >> store, and/or transfer their data. You may cache data you receive from  
> >> the Facebook API in order to improve your application?s user  
> >> experience, but you should try to keep the data up to date. You will  
> >> delete all data you receive from us concerning a user if the user asks  
> >> you to do so, and will provide a mechanism for users to make such a  
> >> request.?
>
> >> I'm assuming Twitter will want to do something similar, and I'd think  
> >> it would also include honoring the "delete" messages that come down  
> >> the streams. That could be *very* interesting if the service was doing  
> >> indexing. ;-)
> >> --
> >> M. Edward (Ed) Boraskyhttp://borasky-research.nethttp://twitter.com/znmeb
>
> >> "A mathematician is a device for turning coffee into theorems." - Paul 
> >> Erdos
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group:  
> >http://groups.google.com/group/twitter-development-talk?hl=en

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

[twitter-dev] Re: [twitter-api-announce] Announcing Site Streams Beta

[Dewald Pretorius]

Ed,

Developer responsibilities and developer agreements mean absolutely
nothing to that person who wants to abuse users' DMs.

In fact, they will probably trick users to authorize their app with a
neat feature, and then in the background collect received and sent
DMs.

Twitter will not have the foggiest idea of which service it could be,
because they will have no record of API requests, or pattern of
requests, for received and sent DMs.


On Aug 30, 5:15 pm, "M. Edward (Ed) Borasky"  wrote:
> Quoting Dewald Pretorius :
>
>
>
>
>
> > Here's another issue that probably needs to be considered.
>
> > It applies mostly to DMs, because people will tend to use DMs for
> > sensitive information, and would expect a certain level of privacy.
>
> > Right now, an OAuth authorized site can query a user's DMs and do with
> > that info what it likes. It could present privacy issues, but at least
> > you have an audit trail of the DM request by the authorized site in
> > your logs/system.
>
> > You lose that audit trail with Site Streams. The DMs are
> > indiscriminately distributed out to all OAuth authorized sites that
> > subscribe to the user's stream.
>
> > It may not seem like a big deal, because it's status quo minus the
> > audit trail. Until you're hit with a multi-million dollar class-action
> > lawsuit for indiscriminately distributing potentially sensitive
> > information. Then it is a big deal. It's not only the lawsuit, it's a
> > privacy PR disaster as well.
>
> Ayup - *Twitter* loses an audit trail - they can track sends / TCP  
> acknowledgements but have no idea what the receiver is doing with the  
> packets. The consuming site must maintain an audit trail, though, right?
>
> Something like this happened at Facebook when they changed their  
> developer TOS. Here's the wording they used:
>
> ?You must give users control over their data by posting a privacy  
> policy that explains what data you collect, and how you will use,  
> store, and/or transfer their data. You may cache data you receive from  
> the Facebook API in order to improve your application?s user  
> experience, but you should try to keep the data up to date. You will  
> delete all data you receive from us concerning a user if the user asks  
> you to do so, and will provide a mechanism for users to make such a  
> request.?
>
> I'm assuming Twitter will want to do something similar, and I'd think  
> it would also include honoring the "delete" messages that come down  
> the streams. That could be *very* interesting if the service was doing  
> indexing. ;-)
> --
> M. Edward (Ed) Boraskyhttp://borasky-research.nethttp://twitter.com/znmeb
>
> "A mathematician is a device for turning coffee into theorems." - Paul Erdos

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

[twitter-dev] Re: [twitter-api-announce] Announcing Site Streams Beta

[Dewald Pretorius]

John,

Is that page cached, because the third sentence of the first bullet
under Important Items still says *exactly* the same?

On Aug 30, 5:15 pm, John Kalucki  wrote:
> Thanks. I've clarified the language.
>
> -John
>
>
>
> On Mon, Aug 30, 2010 at 12:42 PM, Dewald Pretorius  wrote:
> > John,
>
> > Perhaps you should then rephrase the following at
> >http://bit.ly/sitestream_doc
>
> > "One Site Streams graduates to production, sites must only use the
> > REST API for data that is not available through User Streams or as a
> > fall-back data source."
>
> > It's in the first paragraph of Important Items.
>
> > Here's another issue that probably needs to be considered.
>
> > It applies mostly to DMs, because people will tend to use DMs for
> > sensitive information, and would expect a certain level of privacy.
>
> > Right now, an OAuth authorized site can query a user's DMs and do with
> > that info what it likes. It could present privacy issues, but at least
> > you have an audit trail of the DM request by the authorized site in
> > your logs/system.
>
> > You lose that audit trail with Site Streams. The DMs are
> > indiscriminately distributed out to all OAuth authorized sites that
> > subscribe to the user's stream.
>
> > It may not seem like a big deal, because it's status quo minus the
> > audit trail. Until you're hit with a multi-million dollar class-action
> > lawsuit for indiscriminately distributing potentially sensitive
> > information. Then it is a big deal. It's not only the lawsuit, it's a
> > privacy PR disaster as well.
>
> > On Aug 30, 4:25 pm, John Kalucki  wrote:
> > > We're not forcing people over to Site Streams. If, on the other hand, if
> > you
> > > start to consume Site Streams, we want you to stop regular polling on the
> > > REST API.
>
> > > If your service is modest, any excess delivery will be modest. Excessive
> > > options add complexity and slow development for what may be little
> > > practical efficiency gain. Bandwidth and CPU are nearly free at
> > 1mbit/sec.
> > > It's all a balance.
>
> > > -John Kaluckihttp://twitter.com/jkalucki
> > > Twitter, Inc.
>
> > > On Mon, Aug 30, 2010 at 12:15 PM, Dewald Pretorius 
> > wrote:
> > > > This is super news.
>
> > > > However, if you're going to force web services to use Site Streams
> > > > when it is in production ("sites must only use the REST API for data
> > > > that is not available through User Streams"), then please add the
> > > > ability to subscribe only to certain elements. For example, we need
> > > > the ability to subscribe to only Follows, or to only Tweets and
> > > > Retweets, etc.
>
> > > > You make note that each stream may consume significant bandwidth (>
> > > > 1MB).
>
> > > > If a web service does not make use of the user's Follows, or of the
> > > > user's Tweets, then it makes no sense to consume that bandwidth with
> > > > the dead-weight of the elements that are not used by the service.
>
> > > > I understand that Site Streams is in beta now. I'm putting in this
> > > > request for when it is in production and we are forced to use it.
>
> > > > --
> > > > Twitter developer documentation and resources:
> >http://dev.twitter.com/doc
> > > > API updates via Twitter:http://twitter.com/twitterapi
> > > > Issues/Enhancements Tracker:
> > > >http://code.google.com/p/twitter-api/issues/list
> > > > Change your membership to this group:
> > > >http://groups.google.com/group/twitter-development-talk?hl=en
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:
> >http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group:
> >http://groups.google.com/group/twitter-development-talk?hl=en

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

[twitter-dev] Re: [twitter-api-announce] Announcing Site Streams Beta

[Dewald Pretorius]

John,

Perhaps you should then rephrase the following at
http://bit.ly/sitestream_doc

"One Site Streams graduates to production, sites must only use the
REST API for data that is not available through User Streams or as a
fall-back data source."

It's in the first paragraph of Important Items.

Here's another issue that probably needs to be considered.

It applies mostly to DMs, because people will tend to use DMs for
sensitive information, and would expect a certain level of privacy.

Right now, an OAuth authorized site can query a user's DMs and do with
that info what it likes. It could present privacy issues, but at least
you have an audit trail of the DM request by the authorized site in
your logs/system.

You lose that audit trail with Site Streams. The DMs are
indiscriminately distributed out to all OAuth authorized sites that
subscribe to the user's stream.

It may not seem like a big deal, because it's status quo minus the
audit trail. Until you're hit with a multi-million dollar class-action
lawsuit for indiscriminately distributing potentially sensitive
information. Then it is a big deal. It's not only the lawsuit, it's a
privacy PR disaster as well.

On Aug 30, 4:25 pm, John Kalucki  wrote:
> We're not forcing people over to Site Streams. If, on the other hand, if you
> start to consume Site Streams, we want you to stop regular polling on the
> REST API.
>
> If your service is modest, any excess delivery will be modest. Excessive
> options add complexity and slow development for what may be little
> practical efficiency gain. Bandwidth and CPU are nearly free at 1mbit/sec.
> It's all a balance.
>
> -John Kaluckihttp://twitter.com/jkalucki
> Twitter, Inc.
>
>
>
> On Mon, Aug 30, 2010 at 12:15 PM, Dewald Pretorius  wrote:
> > This is super news.
>
> > However, if you're going to force web services to use Site Streams
> > when it is in production ("sites must only use the REST API for data
> > that is not available through User Streams"), then please add the
> > ability to subscribe only to certain elements. For example, we need
> > the ability to subscribe to only Follows, or to only Tweets and
> > Retweets, etc.
>
> > You make note that each stream may consume significant bandwidth (>
> > 1MB).
>
> > If a web service does not make use of the user's Follows, or of the
> > user's Tweets, then it makes no sense to consume that bandwidth with
> > the dead-weight of the elements that are not used by the service.
>
> > I understand that Site Streams is in beta now. I'm putting in this
> > request for when it is in production and we are forced to use it.
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:
> >http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group:
> >http://groups.google.com/group/twitter-development-talk?hl=en

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

[twitter-dev] Re: [twitter-api-announce] Announcing Site Streams Beta

[Dewald Pretorius]

This is super news.

However, if you're going to force web services to use Site Streams
when it is in production ("sites must only use the REST API for data
that is not available through User Streams"), then please add the
ability to subscribe only to certain elements. For example, we need
the ability to subscribe to only Follows, or to only Tweets and
Retweets, etc.

You make note that each stream may consume significant bandwidth (>
1MB).

If a web service does not make use of the user's Follows, or of the
user's Tweets, then it makes no sense to consume that bandwidth with
the dead-weight of the elements that are not used by the service.

I understand that Site Streams is in beta now. I'm putting in this
request for when it is in production and we are forced to use it.

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

[twitter-dev] Re: Change in error response objects

[Dewald Pretorius]

Raffi,

Will the new error construct always be:

[errors][code]
[errors][message]

Or can it be sometimes:

[errors][0][code]
[errors][0][message]
[errors][1][code]
[errors][1][message]

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

[twitter-dev] Re: API Service Disruptions

[Dewald Pretorius]

Taylor,

I don't any longer have the details of the errors during that 18-24
hour period.

But, all seems to be good now.

On Jul 15, 10:57 am, Taylor Singletary 
wrote:
> Dewald, you mentioned having problems with user/show -- can you elaborate?
>
>
>
> On Wed, Jul 14, 2010 at 2:47 PM, Dewald Pretorius  wrote:
> > Because things may not be really falling apart internally, even though
> > it may appear that way from the outside.
>
> > On Jul 14, 2:59 pm, Dossy Shiobara  wrote:
> > > Why not?  I tell my users that all the time, if it's the truth.
>
> > > What benefit is there in lying to your users?
>
> > > On Jul 14, 11:42 am, Dewald Pretorius  wrote:
>
> > > > We all need something to tell our users. Telling them Twitter is
> > > > falling apart is not an option.

[twitter-dev] Re: API Service Disruptions

[Dewald Pretorius]

Because things may not be really falling apart internally, even though
it may appear that way from the outside.

On Jul 14, 2:59 pm, Dossy Shiobara  wrote:
> Why not?  I tell my users that all the time, if it's the truth.
>
> What benefit is there in lying to your users?
>
> On Jul 14, 11:42 am, Dewald Pretorius  wrote:
>
>
>
> > We all need something to tell our users. Telling them Twitter is
> > falling apart is not an option.

[twitter-dev] API Service Disruptions

[Dewald Pretorius]

Please give us something credible to tell our users.

users/show has been effectively down for the past 18 hours.

I've beaten the Soccer World Cup excuse to a bloody pulp, but now it
doesn't fly with my users any more. The SSL certificate thing is also
wearing thin guys, especially since this the second time in quick
succession.

We all need something to tell our users. Telling them Twitter is
falling apart is not an option.

[twitter-dev] Re: Dev Portal Login

[Dewald Pretorius]

Taylor,

When is developer.twitter.com/login going to be fixed? It's been down
now for at least the past 5 days already.

Really weird that nobody complains about it here. Doesn't anybody
register new Twitter applications anymore?

On Jun 16, 12:15 pm, Taylor Singletary 
wrote:
> There is no SSL certificate for developer.twitter.com or dev.twitter.com --
> there's only one for twitter.com. Normally that form submits via SSL to
> twitter.com and then redirects back to dev.twitter.com. It will be fixed
> soon.
>
>
>
> On Wed, Jun 16, 2010 at 7:53 AM, Dewald Pretorius  wrote:
> > Login to developer.twitter.com kicks back "developer.twitter.com uses
> > an invalid security certificate."
>
> > Are things falling apart in the Twitter world?
>
> > On Jun 15, 4:55 pm, Taylor Singletary 
> > wrote:
> > > Sorry for all the issues around this login -- I really want to get this
> > > login functioning correctly but we've had some system-wide changes
> > recently
> > > that have made some elements of fixing this "for reals though" difficult.
> > > It's an incredibly basic issue that's overcomplicated by the
> > particularities
> > > of our production environment, the interaction of SSL, and subdomains. I
> > > hope to have it fixed by the end of the week.
>
> > > For now -- login to twitter.com, then go to the portal.
>
> > > Taylor Singletary
> > > Developer Advocate, Twitterhttp://twitter.com/episod
>
> > > On Tue, Jun 15, 2010 at 12:41 PM, Brian Wigginton
> > > wrote:
>
> > > > Is anyone else having problems logging into the dev portal?
>
> > > > I keep getting directed tohttps://twitter.com/sessionswiththe
> > > > message Sorry, that page doesn’t exist!
>
> > > > -Brian Wigginton

[twitter-dev] Re: Dev Portal Login

[Dewald Pretorius]

Login to developer.twitter.com kicks back "developer.twitter.com uses
an invalid security certificate."

Are things falling apart in the Twitter world?

On Jun 15, 4:55 pm, Taylor Singletary 
wrote:
> Sorry for all the issues around this login -- I really want to get this
> login functioning correctly but we've had some system-wide changes recently
> that have made some elements of fixing this "for reals though" difficult.
> It's an incredibly basic issue that's overcomplicated by the particularities
> of our production environment, the interaction of SSL, and subdomains. I
> hope to have it fixed by the end of the week.
>
> For now -- login to twitter.com, then go to the portal.
>
> Taylor Singletary
> Developer Advocate, Twitterhttp://twitter.com/episod
>
> On Tue, Jun 15, 2010 at 12:41 PM, Brian Wigginton
> wrote:
>
>
>
> > Is anyone else having problems logging into the dev portal?
>
> > I keep getting directed tohttps://twitter.com/sessionswith the
> > message Sorry, that page doesn’t exist!
>
> > -Brian Wigginton

[twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API

[Dewald Pretorius]

Perhaps I'm missing something here, but I do not see any security in
this solution, except for the user not having to enter his Twitter
credentials in an app that only he uses anyway.

Open source means, well, open (readable and modifiable by anyone)
source. Meaning, your API Consumer Key is readable to anyone, and it
is also the only piece of identity used when requesting keys and
secrets.

Let's say you have an XYZ open source project, and Twitter assigns to
it API Consumer Key "QWER".

What exactly prevents any spammer / hacker / bad person out there from
masquerading as your app by using your API Consumer Key "QWER" to
request keys and secrets? There is no way for Twitter to determine
that the request was actually made from within the code of your XYZ
project.

[twitter-dev] Re: tco crawler details

[Dewald Pretorius]

My guess is that Twitter uses the Google SafeBrowsing API, in addition
to other blacklist APIs.

http://code.google.com/apis/safebrowsing/

Google SafeBrowsing is basically two databases, which you can host
locally, and are constantly updated by Google. One database consists
of potential phishing addresses and the other one contains potential
malware addresses.

You do lookups against these databases. You don't visit the actual
destination site. The same applies to other blacklist databases.

That's why there is no need to check for a tco user agent or IP
address. Tco never visits or crawls your site. It simply redirects the
user's browser to your site.

[twitter-dev] T.co and Privacy Policies

[Dewald Pretorius]

Initially I did not see a privacy issue with t.co  But, having thought
more about Twitter forcing us to use the t.co link as the first-hop
destination, I believe there are some potential privacy issues that
need to be clarified.

1)

Normally you need to specify in your service or product's privacy
policy that you are doing click tracking and other individual or
aggregate data collection. How does t.co affect your privacy policy
when you knowingly divert a user to an intermediary service (Twitter)
that collects data, without the user knowing about the collection or
having an opportunity to read and agree to the privacy policy of
Twitter?

Many clicks will come from people who do not use Twitter or do not
have a Twitter account.

2)

When you display anchor text of http://cnn.com but send the user to
http://t.co/xx when they click the anchor text, isn't that
deceptive?

The user expects to be sent directly to CNN.com, as inferred by the
anchor text, and not to an intermediary service that the user has no
knowledge of what that service is going to do or collect. This goes
hand in hand with 1) above.

[twitter-dev] Re: link wrapping on the API

[Dewald Pretorius]

Rich,

That of course would be the right thing for Twitter to do. In other
words, if they want this change, then they must take the bulk of the
pain, instead of creating a problem and dumping it on the developers
to solve.

On Jun 9, 11:46 am, Rich  wrote:
> My proposal is you need to keep the 140 limit as it is now, if your
> own link shortener makes it over 140 then so be it, that's your
> decision, not ours... but the original posted text was 140.

[twitter-dev] Re: link wrapping on the API

[Dewald Pretorius]

This thing really is a can of worms, in terms of:

1) The impact on the ecosystem if characters are counted after link
wrapping.
2) The impact on Twitter's core system and SMS communication if
characters are counted before link wrapping.
3) The perception that there is no guaranteed stability in the TOS,
which makes developing and investing in the ecosystem increasingly
unattractive.

I don't buy the click tracking privacy argument. Twitter will have no
more insight into clicks than what bit.ly or any other shortening
service has, and they won't have any insight into clicks on links that
are not in tweets. For example, if I tweet something with a bit.ly
link and I use that same bit.ly link in other places, Twitter will
track only the clicks on the link in the tweet. They are not able to
track the clicks on that bit.ly link in the other places I've used it
(Facebook, Buzz, StatusNet, blog, etc.). If the privacy argument
carried any water, then bit.ly would be a far greater privacy threat
than Twitter.

[twitter-dev] Re: [twitter-api-announce] link wrapping on the API

[Dewald Pretorius]

Raffi: Never mind. I just saw the Twitter blog post. The motivation
for this is to get metrics for Promoted Tweets and Resonance. Hence,
the answer is: Suck it up.

DeWitt: Yikes, discarding all shortens between t.co and the final link
will seriously mess with the click stats of a few million people.

[twitter-dev] Re: link wrapping on the API

[Dewald Pretorius]

So what are you saying? Suck it up? That's what I am hearing.

I have a work-around for the problem, in that I can simply adjust my
in-house shortening service to start generating 19-character URLs. But
other developers don't have that option.

On Jun 8, 8:58 pm, Raffi Krikorian  wrote:
> its true, and we understand that.
>
> just to correct my previous post, however -- t.co links are 19 characters.
>
>
>
>
>
> On Tue, Jun 8, 2010 at 4:53 PM, Dewald Pretorius  wrote:
> > This is not unique to me. This will be problematic for anyone who uses
> > a shortening service that shortens URLs to less than 20 characters.
>
> > In these cases, you are basically adding characters to the submitted
> > text, and then rejecting the submitted text as being too long.
>
> > On Jun 8, 8:33 pm, Dewald Pretorius  wrote:
> > > Raffi,
>
> > > I'm fine with everything up to the new 140 character count.
>
> > > If you count the characters *after* link wrapping, you are seriously
> > > going to mess up my system. My short URLs are currently 18 characters
> > > long, and they will be 18 long for quite some time to come. After that
> > > they will be 19 for a very long time to come.
>
> > > If you implement this change, a ton, and I mean a *huge* number of my
> > > system's updates are going to be rejected for being over 140
> > > characters.
>
> > > On Jun 8, 7:57 pm, Raffi Krikorian  wrote:
>
> > > > hi all.
>
> > > > twitter has been wrapping links in e-mailed DMs for a couple months
> > > > now<http://bit.ly/twttldmemail>.
> > > > with that feature, we're trying to protect users against phishing and
> > other
> > > > malicious attacks. the way that we're doing this is that any URL that
> > comes
> > > > through in a DM gets currently wrapped with a twt.tl URL -- if the URL
> > turns
> > > > out to be malicious, Twitter can simply shut it down, and whoever
> > follows
> > > > that link will be presented with a page that warns them of potentially
> > > > malicious content. in a few weeks, we're going to start slowly enabling
> > this
> > > > throughout the API for all statuses as well, but instead of twt.tl, we
> > will
> > > > be using t.co.
>
> > > > practically, any tweet that is sent through statuses/update that has a
> > link
> > > > on it will have the link automatically converted to a t.co link on its
> > way
> > > > through the Twitter platform. if you fetch any tweet created after this
> > > > change goes live, then its text field will have all its links
> > automatically
> > > > wrapped with t.co links. when a user clicks on that link, Twitter will
> > > > redirect them to the original URL after first confirming with our
> > database
> > > > that that URL is not malicious.  on top of the end-user benefit, we
> > hope to
> > > > eventually provide all developers with aggregate usage data around your
> > > > applications such as the number of clicks people make on URLs you
> > display
> > > > (it will, of course, be in aggregate and not identifiable manner).
> > > > additionally, we want to be able to build services and APIs that can
> > make
> > > > algorithmic recommendations to users based on the content they are
> > > > consuming. gathering the data from t.co will help make these possible.
>
> > > > our current plan is that no user will see a t.co URL on twitter.combut 
> > > > we
> > > > still have some details to work through. the links will still be
> > displayed
> > > > as they were sent in, but the target of the link will be the t.co link
> > > > instead. and, we want to provide the same ability to display original
> > links
> > > > to developers. we're going to use the entities attribute to make this
> > > > possible.
>
> > > > let's say i send out the following tweet: "you have to check outhttp://
> > dev.twitter.com!"
>
> > > > a returned (and truncated) status object may look like:
>
> > > > {
> > > >   "text" : "you have to check outhttp://t.co/s9gfk2d4!";,
> > > >   ...
> > > >   "user" : {
> > > >     "screen_name" : "raffi",
> > > >     ...
> > > >   },
> > > >   ...
> > > >   "entities" : {
> > > >    

[twitter-dev] Re: link wrapping on the API

[Dewald Pretorius]

This is not unique to me. This will be problematic for anyone who uses
a shortening service that shortens URLs to less than 20 characters.

In these cases, you are basically adding characters to the submitted
text, and then rejecting the submitted text as being too long.

On Jun 8, 8:33 pm, Dewald Pretorius  wrote:
> Raffi,
>
> I'm fine with everything up to the new 140 character count.
>
> If you count the characters *after* link wrapping, you are seriously
> going to mess up my system. My short URLs are currently 18 characters
> long, and they will be 18 long for quite some time to come. After that
> they will be 19 for a very long time to come.
>
> If you implement this change, a ton, and I mean a *huge* number of my
> system's updates are going to be rejected for being over 140
> characters.
>
> On Jun 8, 7:57 pm, Raffi Krikorian  wrote:
>
>
>
> > hi all.
>
> > twitter has been wrapping links in e-mailed DMs for a couple months
> > now<http://bit.ly/twttldmemail>.
> > with that feature, we're trying to protect users against phishing and other
> > malicious attacks. the way that we're doing this is that any URL that comes
> > through in a DM gets currently wrapped with a twt.tl URL -- if the URL turns
> > out to be malicious, Twitter can simply shut it down, and whoever follows
> > that link will be presented with a page that warns them of potentially
> > malicious content. in a few weeks, we're going to start slowly enabling this
> > throughout the API for all statuses as well, but instead of twt.tl, we will
> > be using t.co.
>
> > practically, any tweet that is sent through statuses/update that has a link
> > on it will have the link automatically converted to a t.co link on its way
> > through the Twitter platform. if you fetch any tweet created after this
> > change goes live, then its text field will have all its links automatically
> > wrapped with t.co links. when a user clicks on that link, Twitter will
> > redirect them to the original URL after first confirming with our database
> > that that URL is not malicious.  on top of the end-user benefit, we hope to
> > eventually provide all developers with aggregate usage data around your
> > applications such as the number of clicks people make on URLs you display
> > (it will, of course, be in aggregate and not identifiable manner).
> > additionally, we want to be able to build services and APIs that can make
> > algorithmic recommendations to users based on the content they are
> > consuming. gathering the data from t.co will help make these possible.
>
> > our current plan is that no user will see a t.co URL on twitter.com but we
> > still have some details to work through. the links will still be displayed
> > as they were sent in, but the target of the link will be the t.co link
> > instead. and, we want to provide the same ability to display original links
> > to developers. we're going to use the entities attribute to make this
> > possible.
>
> > let's say i send out the following tweet: "you have to check 
> > outhttp://dev.twitter.com!";
>
> > a returned (and truncated) status object may look like:
>
> > {
> >   "text" : "you have to check outhttp://t.co/s9gfk2d4!";,
> >   ...
> >   "user" : {
> >     "screen_name" : "raffi",
> >     ...
> >   },
> >   ...
> >   "entities" : {
> >     "urls" : [
> >       {
> >         "url" : "http://t.co/s9gfk2d4";,
> >         "display_url" : "http://dev.twitter.com";,
> >         "indices" : [23, 43]
> >       }
> >     ],
> >     ...
> >   },
> >   ...
>
> > }
>
> > two things to note: the text of the returned status object doesn't have the
> > original URL and instead it has a t.co URL, and the entities block now has a
> > display_url attribute associated with it. what we're hoping is that with
> > this data, it should be relatively easy to create a UI where you replace 
> > thehttp://t.co/s9gfk2d4inthe text with the equivalent of
>
> > http://t.co/s9gfk2d4";>http://dev.twitter.com
>
> > this means the user would not see the t.co link, but we all can still
> > provide the protection and gather data from the wrapped link. for the
> > applications that don't choose to update, the t.co link will be shown (and
> > the goal to protect users will be met). i just want to emphasize -- we
> > really do hope that you all render the original URL, but please send 

[twitter-dev] Re: link wrapping on the API

[Dewald Pretorius]

Raffi,

I'm fine with everything up to the new 140 character count.

If you count the characters *after* link wrapping, you are seriously
going to mess up my system. My short URLs are currently 18 characters
long, and they will be 18 long for quite some time to come. After that
they will be 19 for a very long time to come.

If you implement this change, a ton, and I mean a *huge* number of my
system's updates are going to be rejected for being over 140
characters.

On Jun 8, 7:57 pm, Raffi Krikorian  wrote:
> hi all.
>
> twitter has been wrapping links in e-mailed DMs for a couple months
> now.
> with that feature, we're trying to protect users against phishing and other
> malicious attacks. the way that we're doing this is that any URL that comes
> through in a DM gets currently wrapped with a twt.tl URL -- if the URL turns
> out to be malicious, Twitter can simply shut it down, and whoever follows
> that link will be presented with a page that warns them of potentially
> malicious content. in a few weeks, we're going to start slowly enabling this
> throughout the API for all statuses as well, but instead of twt.tl, we will
> be using t.co.
>
> practically, any tweet that is sent through statuses/update that has a link
> on it will have the link automatically converted to a t.co link on its way
> through the Twitter platform. if you fetch any tweet created after this
> change goes live, then its text field will have all its links automatically
> wrapped with t.co links. when a user clicks on that link, Twitter will
> redirect them to the original URL after first confirming with our database
> that that URL is not malicious.  on top of the end-user benefit, we hope to
> eventually provide all developers with aggregate usage data around your
> applications such as the number of clicks people make on URLs you display
> (it will, of course, be in aggregate and not identifiable manner).
> additionally, we want to be able to build services and APIs that can make
> algorithmic recommendations to users based on the content they are
> consuming. gathering the data from t.co will help make these possible.
>
> our current plan is that no user will see a t.co URL on twitter.com but we
> still have some details to work through. the links will still be displayed
> as they were sent in, but the target of the link will be the t.co link
> instead. and, we want to provide the same ability to display original links
> to developers. we're going to use the entities attribute to make this
> possible.
>
> let's say i send out the following tweet: "you have to check 
> outhttp://dev.twitter.com!";
>
> a returned (and truncated) status object may look like:
>
> {
>   "text" : "you have to check outhttp://t.co/s9gfk2d4!";,
>   ...
>   "user" : {
>     "screen_name" : "raffi",
>     ...
>   },
>   ...
>   "entities" : {
>     "urls" : [
>       {
>         "url" : "http://t.co/s9gfk2d4";,
>         "display_url" : "http://dev.twitter.com";,
>         "indices" : [23, 43]
>       }
>     ],
>     ...
>   },
>   ...
>
> }
>
> two things to note: the text of the returned status object doesn't have the
> original URL and instead it has a t.co URL, and the entities block now has a
> display_url attribute associated with it. what we're hoping is that with
> this data, it should be relatively easy to create a UI where you replace 
> thehttp://t.co/s9gfk2d4in the text with the equivalent of
>
> http://t.co/s9gfk2d4";>http://dev.twitter.com
>
> this means the user would not see the t.co link, but we all can still
> provide the protection and gather data from the wrapped link. for the
> applications that don't choose to update, the t.co link will be shown (and
> the goal to protect users will be met). i just want to emphasize -- we
> really do hope that you all render the original URL, but please send the
> user through the t.co link.   if you do choose to prefetch all the URLs on a
> timeline, then, when a user actually clicks on one of the links, please
> still send him or her through t.co. We will be updating the TOS to require
> you to check t.co and register the click.
>
> related to this: the way the Twitter API counts characters is going to
> change ever so slightly. our 140 characters is now going to be defined as
> 140 characters after link wrapping. t.co links are of a predictable length
> -- they will always be 20 characters. after we make this live, it will be
> feasible to send in the text for a status that is greater than 140
> characters. the rule is after the link wrapping, the text transforms to 140
> characters or fewer. we'll be using the same logic that is in
> twitter-text-rb to figure out what is a URL.
>
> look for an update to dev.twitter.com where we'll have a best practices
> document on how to use these t.co links.
>
> what's the timeline?  "soon" we'll enable this on @twitterapi, @rsarver,
> @raffi, and a few other test accounts so you all have live data to play
> with.  on the timescal

[twitter-dev] Re: What is the condition of "status is duplicated"?

[Dewald Pretorius]

Taylor,

It's about creating confusion and uncertainty.

Is Twitter not going to suspend a user or an application that
generates duplicate content, and appends a randomly generated string
of nonsense to each tweet to thwart your duplicate prevention
measures?

I see this notion of "we don't want to tell you how to use Twitter"
more and more. It also came to out of the advertisement banning thing
the other day.

In principle it is good. But, to what extent is Twitter really serious
about that? Every one of the Twitter rules tells me and everyone else
how we must and mustn't use Twitter.

On Jun 3, 2:54 pm, Taylor Singletary 
wrote:
> People use Twitter differently. Duplicate prevention is mainly a
> protection for standard user use cases and spam protection. There is
> value in programmatic use of Twitter that is outside of typical user
> experiences, and there are corner cases where duplicate tweets can be
> useful.  I'm not here to tell you how to use Twitter.
>
>
>
>
>
> On Thursday, June 3, 2010, Dewald Pretorius  wrote:
> > Taylor,
>
> > I don't understand. Why would Twitter on the one hand do duplicate
> > checking and on the other hand advise people to add some kind of
> > unique string to the tweet to circumvent the duplicate checking?
> > You're basically saying it's okay for an application to automatically
> > add a randomly generated string of nonsense to each tweet, to ensure
> > it is unique and will thwart Twitter's duplication content prevention
> > measures.
>
> > Isn't that a perfect exercise in self-defeat, or what the military
> > folks call "chickenshit"?
>
> > On Jun 3, 12:49 pm, Taylor Singletary 
> > wrote:
> >> We tune the duplicate tweet detection algorithm regularly, so it's 
> >> difficult
> >> to say with any hard rules at what point a tweet will be considered a
> >> duplicate -- it's not necessarily time-based and more tuned toward the
> >> contents of the last few tweets issued by the user account. If you're use
> >> case is such that you'd be issuing the same tweet multiple times, you might
> >> want to provide some kind of unique string to each tweet, or otherwise
> >> insure that the tweet is not a duplicate.
>
> >> Taylor Singletary
> >> Developer Advocate, Twitterhttp://twitter.com/episod
>
> >> On Thu, Jun 3, 2010 at 12:10 AM, kimtree  wrote:
>
> >> >  I have no idea to understand condition of "status is duplicated".
> >> >  "status is duplicated" condition is update same tweet in few minutes?
> >> > or a day?
> >> >  I want to know exact condition.  Have any Ideas?
>
> --
> Taylor Singletary
> Developer Advocate, Twitterhttp://twitter.com/episod

[twitter-dev] Re: What is the condition of "status is duplicated"?

[Dewald Pretorius]

Taylor,

I don't understand. Why would Twitter on the one hand do duplicate
checking and on the other hand advise people to add some kind of
unique string to the tweet to circumvent the duplicate checking?
You're basically saying it's okay for an application to automatically
add a randomly generated string of nonsense to each tweet, to ensure
it is unique and will thwart Twitter's duplication content prevention
measures.

Isn't that a perfect exercise in self-defeat, or what the military
folks call "chickenshit"?

On Jun 3, 12:49 pm, Taylor Singletary 
wrote:
> We tune the duplicate tweet detection algorithm regularly, so it's difficult
> to say with any hard rules at what point a tweet will be considered a
> duplicate -- it's not necessarily time-based and more tuned toward the
> contents of the last few tweets issued by the user account. If you're use
> case is such that you'd be issuing the same tweet multiple times, you might
> want to provide some kind of unique string to each tweet, or otherwise
> insure that the tweet is not a duplicate.
>
> Taylor Singletary
> Developer Advocate, Twitterhttp://twitter.com/episod
>
>
>
> On Thu, Jun 3, 2010 at 12:10 AM, kimtree  wrote:
>
> >  I have no idea to understand condition of "status is duplicated".
> >  "status is duplicated" condition is update same tweet in few minutes?
> > or a day?
> >  I want to know exact condition.  Have any Ideas?

[twitter-dev] Re: Sorry, your query is too complex. Please reduce complexity and try again.

[Dewald Pretorius]

How can this query be too complex?

http://search.twitter.com/search?q=%22for+sale+by+owner%22+near:%22fort+worth%22+within:100mi

It's a very simple geo-targeted query.

Has Search suffered a frontal lobotomy? These searches used to work
before.

On May 24, 2:32 am, Cameron Kaiser  wrote:
> > I keep getting the message:  Sorry, yourqueryistoocomplex. Please
> > reduce complexity and try again.
>
> > Is there a way around this?
>
> Post yourquery, perhaps?
>
> In general, no. You might have to combine two less complicated searches into
> a single set on your end rather than expecting the Search API to do it.
>
> --
>  personal:http://www.cameronkaiser.com/--
>   Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com
> -- Backup not found. Abort, Retry, Vomit, Panic, Write Resume File? 
> ---

[twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING

[Dewald Pretorius]

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  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 
> 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  wrote:
> > > I hope some answers are forthcoming, James. Twitter doesn't seem very
> > > talkative.

[twitter-dev] Re: Search api returning results based on walking shortened URLS: causing problems.

[Dewald Pretorius]

I've seen the same thing with some of my own searches, and I just
figured the search algo was broken, because it returns results that
have absolutely nothing to do with the phrase you searched for.

On May 26, 6:24 pm, Jeffrey Greenberg 
wrote:
> So we have customer that is searching, for example, for hotels.com.
> So we use the search api and we get from Twitter a tweet that has no
> such text in it, but it turns out that the shortened URL contains the
> string 'hotels.com':
>
> Here's the tweet:
>     Siam Bayview Hotel Pattaya, Beach Rd. from THB 2,010 incl
> breakfast Special Ratehttp://bit.ly/295HOIThailand hotels
> He're the walked bit.ly url:
>    http://www.r24.org/patong-beach-hotels.com/pattaya/siambayview/
>
> In this case, this match isn't good.  They don't want r24.org stuff,
> they want hotels.com stuff...  On the other hand, it's great when it
> really shows hotels.com stuff..
>
> I'm not sure what the 'right" thing to do is at this moment, as I'm
> reacting to the customer's urgency and problem in getting unrelated
> stuff showing up in their search...
>
> I'm not sure how I should address this:
> 1. recommend that twitter do some sort of mod to the search api  ( I
> don't have a good idea at the moment about what you should do: make
> such url walking optional?  etc?)
> 2. do some sort of processing on our end, and communicating about
> better about what search does to our customers
>
> So:
> a. What's ya'll thoughts on this one?
>
> b. I believe that you (twitter) walk some shorteners but not all of
> them: e.g. bit.ly urls and your own shortener   What is the current
> list that you do walk?
>
> This is related to entity parsing discussion 
> here:http://groups.google.com/group/twitter-development-talk/browse_thread...
>
> Thanks,
> Jeffrey Greenberg
> tweettronics.com

[twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING

[Dewald Pretorius]

Taylor,

Perhaps you should ask someone to add the http://bit.ly/twitter-ad-faq
link as a further reading reference into the "2. Advertising Around
Twitter Content" section of the API TOS.

Stuff is very fragmented at the moment, and you have to accidentally
discover pages on separate domains just to get the full picture.

The same goes for further reading on other sections of the API TOS as
well.

On May 26, 1:20 pm, Taylor Singletary 
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  wrote:
> > I hope some answers are forthcoming, James. Twitter doesn't seem very
> > talkative.

[twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING

[Dewald Pretorius]

Taylor,

Read this part of that FAQ: "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."

Do you realize how confusing that is?

1) Does it mean I can publish a paid tweet via the API? (I know I can,
but someone who just reads the FAQ won't be able to figure that out.)

2) Does it mean I can inject "tweets" into any displayed timeline, as
long as they are not "paid tweets"? If so, it means I can insert
entries that look exactly like tweets, except they did not come from
Twitter and they contain my affiliate link.

You guys really need to sit down and read all these things through the
eyes of people who are not privy to your internal discussions,
decisions, and understanding of the matter. And then write your TOS
and FAQs so that everyone can understand them.

On May 26, 1:20 pm, Taylor Singletary 
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  wrote:
> > I hope some answers are forthcoming, James. Twitter doesn't seem very
> > talkative.

[twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING

[Dewald Pretorius]

Ryan,

I think this is at the level where Dick needs to post a clarification
on the Twitter blog.

Everyone in the media, and there are tons of articles everywhere, have
interpreted this policy change to mean the death of Ad.ly,
SponsoredTweets.com, etc.

The policy is very poorly worded because it is not clear on the exact
scope of the ban.

The way I understand it now is:

1) Publishing via the web interface or via the API, by the user or by
a third-party service authorized by the user, of paid or sponsored
tweets are allowed provided that the tweet text contains a clear and
unambiguous identification that it is a paid tweet. These paid tweets
form part of the normal tweet stream and are not affected or
prohibited by 2).

2) When reading tweets from the API (REST, Search or Streaming) and
displaying the tweets in any list, the insertion of any additional
paid or unpaid advertising or promotional content in between the
tweets are not allowed, when such insertion can reasonably interpreted
as being part of the tweets that are displayed in the list.

3) Advertising around displayed tweets are allowed, but revenue from
such advertising must be shared with Twitter.

Is that reasonably accurate?

On May 25, 2:28 am, Ryan Sarver  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  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  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

[Dewald Pretorius]

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  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 Platform blog post

[Dewald Pretorius]

Jeepers. With one blog post Dick has killed the business of more than
a few companies that have been doing what they've doing for many
months, if not spanning more than a year.

I fully understand Dick's rationale, but, phew, why don't you guys
consider grandfathering in businesses that existed before the date of
the change in the rules?

I mean, it's good, it's your rules, and you can change them. But
really, it is very harsh to unceremoniously pull the rug from
underneath companies that were doing nothing wrong up to the point of
the rule change.

Just my 2cents.

On May 24, 1:06 pm, Ryan Sarver  wrote:
> Wanted to make sure everyone saw this post from Dick. Please let us know
> what questions you have. The actual Terms will be posted shortly.
>
> http://blog.twitter.com/2010/05/twitter-platform.html
>
> Best, Ryan

[twitter-dev] Re: Is the "forced follow" really fixed?

[Dewald Pretorius]

Ed,

What I find is people sometimes forget that they've set up an auto-
follow service to work on their account. Gosh, I get people who sign
up today, and the next day they ask for support because they've
forgotten their password.

These things will be easier to debug for your friend once everyone
uses OAuth, because then she can just check her Connections. Until
then, she will just have to think way back and try and remember if she
has ever set up such a service.

On May 21, 2:10 pm, "M. Edward (Ed) Borasky"  wrote:
> I have a friend who claims that she needs to unfollow people that she hasn't
> followed. Is there still a way someone can force you to follow them? I thought
> that had been fixed.
>
> Anybody else seeing this? I don't monitor my following count closely - I
> follow and unfollow people but don't really check to see if there are people I
> haven't followed.
>
> Is it possible that there are some autofollow services out there that have
> "gone rogue?"
> --
> M. Edward (Ed) Boraskyhttp://borasky-research.net/m-edward-ed-borasky/@znmeb
>
> "A mathematician is a device for turning coffee into theorems." ~ Paul Erdős

[twitter-dev] Re: Twitter app on iPhone

[Dewald Pretorius]

I have not yet seen the new Twitter iPhone client, but if this is true
then it's exactly what we developers feared would happen, namely
Twitter competing with developers and using secret API calls to offer
features that external developers cannot offer. It's really not a good
move, folks, because once you open that barn door, the horses just
keep bolting, and you undermine an already shaky trust in the
intentions of Twitter towards developers. I know this was not decided
or done by Ryan's group, but someone in your group should do some
serious advocacy here, because you're the ones who want us to trust
you and continue to work with you in a non-combative environment.

On May 19, 8:17 am, Rich  wrote:
> So Tweetie is now Twitter and has features that no other API client
> can offer.
>
> How about giving us access to features that the new Tweetie has that
> there is no public end point for such as signing up for an account or
> suggested user lists?

[twitter-dev] Re: parsing out entities from tweets (a.k.a. parsing out hashtags is hard!)

[Dewald Pretorius]

Raffi,

This is all good, but can you please make the inclusion in the tweet
payload optional? Meaning, only include it if it is requested by an
additional parameter?

I, and I'm sure a lot of others, are already parsing the tweet text.
This is just going to consume additional bandwidth and not add any
value for us. It will add value for folks who are not already doing
the parsing or don't know how. So, they can just request this
additional payload.

[twitter-dev] Re: Intermittent 401 Errors

[Dewald Pretorius]

Glen,

My system makes thousands of outgoing calls per minute, and a lot of
them are going to non-Twitter destinations. Even if it wouldn't mess
with my app, I'm not sending a TCP dump/log anywhere. There's nothing
inappropriate in there, but calls, destinations, and volume of calls
that my system makes are proprietary business information.

On May 11, 11:34 am, glenn gillen  wrote:
> On May 11, 3:21 pm, Dewald Pretorius  wrote:
>
> > As well (I know it has been discussed elsewhere), I am consistently
> > seeing API response times in excess of 3 seconds per call. It is
> > actually rare to see one that takes less than 2 seconds. This is on
> > connections from Dallas. But, even using twitter.com in the web
> > browser from Canada is also painfully slow.
>
> Dewald,
>
> I can't provide any constructive feedback to your problem, but I was
> wondering if you had any input on this message I posted earlier 
> today:http://groups.google.com/group/twitter-development-talk/msg/27ea7a163...
>
> Also, having had to play the tech support role for a while in a
> previous life, is running tcpdump on a live server for 30-60 seconds
> really going to mess with your app in any noticeable way? The majority
> of the time when people ask for that kind of information it's not to
> satisfy their sadomasochistic desires to trawl through network dumps,
> it's to make their life easier while trying to identify/recreate and
> fix your problem.
>
> --
> Glenn Gillenhttp://glenngillen.com/

[twitter-dev] Re: Intermittent 401 Errors

[Dewald Pretorius]

As well (I know it has been discussed elsewhere), I am consistently
seeing API response times in excess of 3 seconds per call. It is
actually rare to see one that takes less than 2 seconds. This is on
connections from Dallas. But, even using twitter.com in the web
browser from Canada is also painfully slow.

[twitter-dev] Re: Intermittent 401 Errors

[Dewald Pretorius]

In fact, the API seems to be really borked at the moment.

I've been running more tests on friends_timeline.json, and the
following happens:

1) Sometimes the connection is refused.
2) Sometimes I get a 200 OK with an empty JSON array, and seconds
later with the very next call on the same Twitter account I get a 200
OK with a fully populated JSON array.
3) On some accounts I get "401 Invalid / expired token", where the
token on my side has not changed and the connection is present in the
Twitter account's Connections tab.

[twitter-dev] Intermittent 401 Errors

[Dewald Pretorius]

Since late yesterday (May 10), I've been getting intermittent "401
Could not authenticate you" errors.

This is on Twitter accounts and code that have been working for a very
long time. My code has not changed, and there is nothing wrong with
the Twitter accounts either. They are not suspended, or limited, and
the connection for my app is firmly present in the Connections tab.

One one call (I've validated this on mentions.json,
direct_messages.json, and friends_timeline.json) it would work and
give me a 200 with the data. On the very next call I get a 401 Could
not authenticate you. There is no discernable pattern.

Please don't ask me to capture TCP dumps. This is my live app, and I
am not going to mess with it to debug the API.

[twitter-dev] Re: users/show bug with nested user object

[Dewald Pretorius]

Over time I've learned it is a best practice to check the integrity of
a returned Twitter object despite the fact that the HTTP response code
is 200.

[twitter-dev] Blackbird Pie

[Dewald Pretorius]

http://media.twitter.com/blackbird-pie/

Can you guys add a meta data element to a tweet, which will provide a
"blackbird pie" hyperlink for a tweet.

Basically, the code behind the link should generate the code block
that Blackbird Pie currently generates. That way one can include a
Blackbird Pie tweet in an iframe, with the iframe source link coming
from the "blackbird pie" hyperlink in the tweet meta data.

Just a thought.

[twitter-dev] Re: Tons of Connection Refused

[Dewald Pretorius]

John, Sorry, I should have update this thread.

It was the ThePlanet.com outage that affected me.

On May 3, 2:21 am, John Kalucki  wrote:
> Did this happen to start at 10pm PST / 05:00 UTC?
>
>
>
> On Sun, May 2, 2010 at 10:16 PM, Dewald Pretorius  wrote:
> > I'm getting tons of connection refused errors.
>
> > What's going on?
>
> > The API status is till giving a 100% up indicator.

[twitter-dev] Tons of Connection Refused

[Dewald Pretorius]

I'm getting tons of connection refused errors.

What's going on?

The API status is till giving a 100% up indicator.

[twitter-dev] Re: About update limits

[Dewald Pretorius]

I can't think of a use or requirement that would need more than 1,000
tweets per day.

Unless you're promoting teeth whitening affiliate links that
absolutely must be sent at a rate of one tweet every 30 seconds,
because we all know how quickly the teeth of some followers turn
yellow.

On Apr 29, 8:45 pm, Brian Sutorius  wrote:
> To clarify, statuses/update is not affected by rate-limit whitelisting
> as it's a POST call and we don't maintain a separate whitelist for
> boosting the daily tweet limit above 1000. While we do not give out
> the specifics around the "sub-limits," they *are* administered on a
> per-account basis and if you stay around your approximation of 20
> tweets per half-hour you should be fine.
>
> Brian Sutorius
>
> On Apr 29, 6:07 am, Raffi Krikorian  wrote:
>
>
>
> > the numbers are roughly broken up over the day.  and the limit applies to an
> > account.
>
> > and yes - there is a whitelisting for status/updates -- please e-mail
> > a...@twitter to ask for it.
>
> > On Thu, Apr 29, 2010 at 5:26 AM, akaii  wrote:
> > > This is what the FAQ has to say about status update limits:
>
> > > Updates: 1,000 per day. The daily update limit is further broken down
> > > into smaller limits for semi-hourly intervals. Retweets are counted as
> > > updates.
>
> > > I'm a little unclear as to what exactly is meant by "further broken
> > > down into smaller limits for semi-hourly intervals". Is the 1000 per
> > > day limit divided evenly between the 48 half hours each day (around 20
> > > or so tweets per half an hour?).
>
> > > Also, I'm assuming this limit applies to each unique account?
>
> > > Is this limit absolutely fixed? Or is there some equivalent to
> > > "whitelisting" for status/update limits as well?
>
> > > Thanks...
>
> > --
> > Raffi Krikorian
> > Twitter Platform Teamhttp://twitter.com/raffi

[twitter-dev] Re: Invalid / used nonce but only for certain user names?

[Dewald Pretorius]

Cory,

I have had similar issues. When you get that 401 error, you need to
back off for a second or two, recalculate the nonce, and then resubmit
the request.

On Apr 28, 10:52 pm, Cory  wrote:
> Anyone have any ideas about this? I'm really not sure where to go or
> what to check from here, and I need to get this taken care of. Any
> information would be appreciated!

[twitter-dev] Re: Really, You're not going to suspend @julianperretta?

[Dewald Pretorius]

Ducking the artillery shells and verbal mortar rounds in this thread,
I just want to ask:

Did you know @shitmydadsays actually uses status.net, and pushes its
tweets from there into Twitter via the StatusNet-Twitter bridge?

On Apr 28, 11:21 am, Dossy Shiobara  wrote:
> On 4/28/10 10:18 AM, John Meyer wrote:
>
>
>
> > Spam I understand, but are you actually trying to report plagarism on a
> > bloody tweet?  Are you kidding me?  We're you planning on selling that
> > bit of wisdom somewhere? Spinning it off for a book deal?
>
> You mean, like @shitmydadsays?
>
> --
> Dossy Shiobara              | do...@panoptic.com |http://dossy.org/
> Panoptic Computer Network   |http://panoptic.com/
>   "He realized the fastest way to change is to laugh at your own
>     folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: App needs more calls than what Twitter Whitelisted Account offers!

[Dewald Pretorius]

To be quite frank, you are filling a hole.

The functionality you are describing, identifying and getting rid of
spam followers, is Twitter's job and should be part of their core
system.

On Apr 28, 8:41 am, deadlychaos  wrote:
> Hi there,
>
> We are very excited to develop an App on Twitter ecosystem. We are
> developing something which removes all the spam from user's followers
> list and shows him how much exactly non-spam followers he has. But to
> perform such task, we need way more than what Twitter Whitelisted
> account offers (20,000). For an instance, Twitter CEO @EV himself has
> around 1.1 Million Followers. What we do is we have designed a set of
> algorithms which removes all the spam, inactive and such other
> followers and show how many exactly real followers the particular user
> has. But to do this (by rest api) we need to spend 1 call to calculate
> every 100 followers of the user. And once we get those 100 follower we
> need 1 more call to filter out spam followers. Also there are few more
> such tasks we need to perform to filter out the spam which needs more
> calls. So if for instance a user has more than 1 million followers,
> our system will not be able to calculate his overall non-spam
> followers. Also there is a chance when multiple users can try to check
> how many non-spam followers they have at the same time. All I need to
> ask is, how am I able to get more than one IP addresses white-listed
> (white-listing form states that we are able to whitelist more than one
> ip) and if such thing is possible, how can we use both the ip's to
> perform one single task of user having more than 1 million followers.
> Also we were thinking of getting more than one Twitter account white-
> listed associated to our business and then use them one by one when we
> use all the calls from one id. Is this feasible? If both the methods
> (White-listing IP and White-listing Accounts) are not a proper way to
> perform such task, what would you recommend us to do? We have spent
> countless nights getting this algorithms work and we even have tested
> them on small user account having less than 1000 followers and it
> works like charm. We are searching for solution since a month now. I
> hope we will get help here.
>
> Eagerly waiting for reply from Twitter.
> Thanks a lot in advance!

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

[Dewald Pretorius]

In fact, you could set a threshold per consumer key that you can vary.
In other words, you can then allow a higher percentage XAuth (even
100%) to an app that caters largely to a Chinese market. And 0% or 10%
to an app that caters largely to the USA market.

On Apr 26, 9:43 am, Dewald Pretorius  wrote:
> I know it's a compromise. But, it does serve the needs of a very large
> number of users.
>
> Maybe you could monitor the authentication profile of a web app. If it
> uses more XAuth than OAuth, then you know you need to contact the
> owner. Or, you can set an automated percentage threshold, such as
> "XAuth authentications from a particular consumer key cannot exceed
> 25% of all authentications from that key."
>
> On Apr 26, 9:36 am, Raffi Krikorian  wrote:
>
>
>
> > > One solution, which I know won't win the popularity prize, is for
> > > Twitter to relax its XAuth restrictions and allow web apps to use full
> > > OAuth and/or XAuth, depending on what works best for them.
>
> > > In my case, I will still use full OAuth because it's so much better
> > > than dealing with Twitter credential issues. But, I will add a small
> > > link below the Twitter authorize button on my site that says something
> > > like, "Can't get to Twitter.com?" which then leads to a username-
> > > password entry form, and then triggers an XAuth authorization.
>
> > unfortunately, this defeats the purpose of oauth :(
>
> >http://mehack.com/xauth-and-perhaps-the-need-for-socializing-ap
>
> > --
> > Raffi Krikorian
> > Twitter Platform Teamhttp://twitter.com/raffi
>
> > --
> > Subscription 
> > settings:http://groups.google.com/group/twitter-development-talk/subscribe?hl=en

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

[Dewald Pretorius]

I know it's a compromise. But, it does serve the needs of a very large
number of users.

Maybe you could monitor the authentication profile of a web app. If it
uses more XAuth than OAuth, then you know you need to contact the
owner. Or, you can set an automated percentage threshold, such as
"XAuth authentications from a particular consumer key cannot exceed
25% of all authentications from that key."

On Apr 26, 9:36 am, Raffi Krikorian  wrote:
> > One solution, which I know won't win the popularity prize, is for
> > Twitter to relax its XAuth restrictions and allow web apps to use full
> > OAuth and/or XAuth, depending on what works best for them.
>
> > In my case, I will still use full OAuth because it's so much better
> > than dealing with Twitter credential issues. But, I will add a small
> > link below the Twitter authorize button on my site that says something
> > like, "Can't get to Twitter.com?" which then leads to a username-
> > password entry form, and then triggers an XAuth authorization.
>
> unfortunately, this defeats the purpose of oauth :(
>
> http://mehack.com/xauth-and-perhaps-the-need-for-socializing-ap
>
> --
> Raffi Krikorian
> Twitter Platform Teamhttp://twitter.com/raffi
>
> --
> Subscription 
> settings:http://groups.google.com/group/twitter-development-talk/subscribe?hl=en

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

[Dewald Pretorius]

Raffi,

One solution, which I know won't win the popularity prize, is for
Twitter to relax its XAuth restrictions and allow web apps to use full
OAuth and/or XAuth, depending on what works best for them.

In my case, I will still use full OAuth because it's so much better
than dealing with Twitter credential issues. But, I will add a small
link below the Twitter authorize button on my site that says something
like, "Can't get to Twitter.com?" which then leads to a username-
password entry form, and then triggers an XAuth authorization.

On Apr 26, 12:34 am, Raffi Krikorian  wrote:
> before this gets out of hand - i, personally, am very sensitive to these
> issues.  i've been spending some brain power trying to come up with a
> solution.  if people have suggestions, then please feel free to reach out to
> me personally and off list.
>
>
>
>
>
> On Sun, Apr 25, 2010 at 7:54 PM, Ron B  wrote:
> > China's policy didn't just recently change, Twitter's did.  So it is
> > Twitter telling us that we may not be able to support China and other
> > firewall blocked countries any longer.  It is, after all, within
> > Twitter's power to continue to support Basic Auth.  It is their
> > conscious decision not to, despite the significant negative
> > ramifications being brought to their attention.
>
> > In an earlier comment from Twitter: " twitter.com is trying to drive
> > people to understand and discover what's going on in the world."  No
> > one in the world needs to "understand and discover what's going on"
> > more than the people of these communist-block countries that otherwise
> > see only what their governments allow them to see.  It is unfortunate
> > that Twitter plans to turn their back on them.  Then again, what's a
> > billion people here or there?...
>
> > On Apr 25, 9:04 pm, Abraham Williams <4bra...@gmail.com> wrote:
> > > It is not twitter telling you it is China.
>
> > > --
> > > Little androids dreaming of Nexus Ones compiled this text.
>
> > > On Apr 25, 2010 6:53 PM, "Dewald Pretorius"  wrote:
>
> > > Raffi,
>
> > > We really need a resolution for this issue before Basic Auth is
> > > deprecated.
>
> > > It sounds as if Twitter is telling developers of web apps that they
> > > cannot provide service to Chinese users, and other users behind
> > > firewalls that block access to twitter.com. But that can't be right,
> > > can it?
>
> > > On Apr 25, 4:49 am, jaronbarends  wrote:> I
> > moved my web based app from ba...
> > > > This issue has discussed in this group before here:
>
> > >https://groups.google.com/group/twitter-development-talk/browse_threa...
>
> > > > Being a frontend developer, I may have misunderstood the outcome of
> > > > that discussion (I certain...
>
> > > --
> > > Subscription settings:
> >http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
>
> --
> Raffi Krikorian
> Twitter Platform Teamhttp://twitter.com/raffi

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

[Dewald Pretorius]

Raffi,

We really need a resolution for this issue before Basic Auth is
deprecated.

It sounds as if Twitter is telling developers of web apps that they
cannot provide service to Chinese users, and other users behind
firewalls that block access to twitter.com. But that can't be right,
can it?

On Apr 25, 4:49 am, jaronbarends  wrote:
> I moved my web based app from basic auth to oAuth just last week. I
> subsequently got several pleas from Chinese users to put the old
> version back up, as they could no longer use my app, since access to
> Twitter.com is blocked in China.
>
> This issue has discussed in this group before 
> here:https://groups.google.com/group/twitter-development-talk/browse_threa...
>
> Being a frontend developer, I may have misunderstood the outcome of
> that discussion (I certainly hope so). But from Raffi's last comment
> there ("understood, but, right now, not in the plan.  web apps will
> have to use the standard oauth workflow.") I understand that web app
> users in countries like China where twitter is blocked will simply no
> longer be able to use Twitter via the web.
>
> Have I understood this correctly? If not, how can I make sure users in
> blocked countries can still use my web app? If my users can no longer
> use my app, what do you suggest I recommend them?
>
> Jaron
>
> On Apr 24, 5:40 pm, Raffi Krikorian  wrote:
>
>
>
> > hi all.
>
> > you're going to be hearing a lot from me over the next 9 weeks.  our plan is
> > to turn off basic authorization on the API by june 30, 2010 -- developers
> > will have to switch over to OAuth by that time.  between now and then, there
> > will be a *lot* of information coming along with tips on how to use OAuth
> > Echo, xAuth, etc.  we really want to make this transition as easy as we can
> > for everybody.
>
> > as always, please feel free to reach out to this group, or to @twitterapi
> > directly.  if you need help remembering the date -http://bit.ly/twcountdown
> > .
>
> > --
> > Raffi Krikorian
> > Twitter Platform Teamhttp://twitter.com/raffi
>
> > --
> > Subscription 
> > settings:http://groups.google.com/group/twitter-development-talk/subscribe?hl=en

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

[Dewald Pretorius]

Raffi, that is super awesome. Thank you.

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

On Apr 24, 12:40 pm, Raffi Krikorian  wrote:
> hi all.
>
> you're going to be hearing a lot from me over the next 9 weeks.  our plan is
> to turn off basic authorization on the API by june 30, 2010 -- developers
> will have to switch over to OAuth by that time.  between now and then, there
> will be a *lot* of information coming along with tips on how to use OAuth
> Echo, xAuth, etc.  we really want to make this transition as easy as we can
> for everybody.
>
> as always, please feel free to reach out to this group, or to @twitterapi
> directly.  if you need help remembering the date -http://bit.ly/twcountdown
> .
>
> --
> Raffi Krikorian
> Twitter Platform Teamhttp://twitter.com/raffi
>
> --
> Subscription 
> settings:http://groups.google.com/group/twitter-development-talk/subscribe?hl=en

[twitter-dev] Re: My applications were Suspended

[Dewald Pretorius]

Brian,

It is not unreasonable for developers to hope that Twitter does not
suspend applications for "could violate rules" and "possible rule
violations." I trust this was just a slip of the tongue on your part.

We know you must maintain a good-citizen ecosystem.

For that to happen, we really do trust that you suspend applications
for actual rule violations, which you can point to as to how and when
you discovered those actual violations, and *not* for mere suspicion
of rule violations.

On Apr 23, 4:28 pm, Brian Truebe  wrote:
> Yes, the email that is sent out after an application is suspended does
> explain possible rule violations. This email is sent to the account
> that registered the application, so if you've registered an app with
> an auxiliary account not tied to an email address you check regularly
> then an app suspension may come as a rather unfortunate surprise.
>
> While there is no "sandbox," we're very open to discussing any
> concerns an app developer may have while they develop their app. The
> best course of action is to read the rules first while developing.  If
> you're still worried a feature you're developing may result in your
> users being suspended our your entire app being suspended then you can
> always email us at a...@twitter.com and we'll be happy to work with you
> to ensure the longevity of your application.  I hope this helps.
>
> -Brian
>
> On Apr 23, 11:37 am, John Meyer  wrote:
>
>
>
> > On 4/23/2010 10:58 AM, Brian Truebe wrote:
>
> > > My name is Brian Truebe and I am on the API Policy team, when apps are
> > > suspended they are sent a notice as to how to contest the suspension,
> > > however this may have gotten lost in the tubes.  Please email
> > > a...@twitter.com and let us know the app name and we'll see if we can
> > > sort this out.
> > > Sorry for the inconvenience.
>
> > > Regards,
> > > Brian
>
> > One question: does the e-mail have an explanation about why the
> > application was suspended in the first place (you mention how to contest
> > the suspension but nothing about what the suspension is about).  And is
> > there some way to create a "sandbox" for suspended apps where they can
> > re-test to see if they are in compliance with the rules before going out
> > into the real world Twitterverse?
>
> > --
> > Subscription 
> > settings:http://groups.google.com/group/twitter-development-talk/subscribe?hl=en-
> >  Hide quoted text -
>
> - Show quoted text -

[twitter-dev] Re: Early look at Annotations

[Dewald Pretorius]

Raffi,

It's not about people using or not using rogue apps. It's about rogue
apps poisoning the annotation data and ruining it for everybody.

Rogue apps can continue to refresh their consumer keys with new
accounts and OAuth app registrations, as soon as the one currently in
use is suspended.

Meaning, a new class of rogue app will emerge. Ones with the express
purpose of getting their data into the namespaces.

To name one example (with reference to Marcel's examples):

- A rogue app that creates tweets with an affiliate link in the
 namespace.

On Apr 16, 3:31 pm, Raffi Krikorian  wrote:
> > I'd strongly urge you to consider a more structured and controlled
> > environment for annotations.
>
> > Ideally, I think an OAuth app must register a namespace, or subscribe
> > to an existing namespace of another app, before it can create
> > annotations in that namespace. And these registrations and
> > subscriptions must be reviewed and approved before an app can actually
> > contribute to a namespace.
>
> > Being as open and free as you currently have it, it's fertile soil for
> > the poisoning of any namespace by any rogue or not-so-nice app.
>
> > It's better to plan and create the controls ahead of time. You're
> > going to save everyone, including yourselves, a lot of effort and
> > time.
>
> the same could happen right now - if somebody puts a $ before something,
> stock twits may try to parse that as a stock market commodity.  i don't see
> us (for some) enforcing anything on the namespaces, and will let the
> community try to work it out.
>
> if there happens to be a rogue app, then users will stop using it.
>
> --
> Raffi Krikorian
> Twitter Platform Teamhttp://twitter.com/raffi
>
> --
> Subscription 
> settings:http://groups.google.com/group/twitter-development-talk/subscribe?hl=en-
>  Hide quoted text -
>
> - Show quoted text -

[twitter-dev] Re: Early look at Annotations

[Dewald Pretorius]

Marcel,

I'd strongly urge you to consider a more structured and controlled
environment for annotations.

Ideally, I think an OAuth app must register a namespace, or subscribe
to an existing namespace of another app, before it can create
annotations in that namespace. And these registrations and
subscriptions must be reviewed and approved before an app can actually
contribute to a namespace.

Being as open and free as you currently have it, it's fertile soil for
the poisoning of any namespace by any rogue or not-so-nice app.

It's better to plan and create the controls ahead of time. You're
going to save everyone, including yourselves, a lot of effort and
time.

On Apr 16, 2:54 pm, Marcel Molina  wrote:
> Hey everyone. One of the things we talked about at Chirp is the new
> Annotations feature we're working on. In short, it allows you to annotate a
> tweet with structured metadata. We're still working on Annotations, but I
> wanted to share with a wider audience beyond those I was able to talk to in
> person at Chirp about how we're thinking of doing Annotations.
>
> * What is an annotation more exactly exactly?
>
> First off let's be clearer about what an annotation is. An annotation is a
> namespace, key, value triple. A tweet can have one or more annotations.
> Namespaces can have one or more key/value pairs.
>
> * How do I specify what annotations a tweet should have?
>
> Annotations are specified for a tweet when the tweet is created. When
> submitting a POST to /statuses/update, you'll include an "annotations"
> parameter with your annotations. We're thinking we'll provide two mechanisms
> for specifying what a tweet's annotations are:
>
>   1. JSON
>   2. form encoded parameters
>
> * How big can an annotation be and how many annotations can I attach to a
> tweet?
>
> There is no limit on the size of any given namespace, key or value but the
> entire set of all annotations for a given tweet can not exceed some fixed
> byte size. That size isn't set in stone yet. We will be starting small
> (probably 512 bytes) and growing it gradually as we incrementally roll out
> the feature so we can gauge its scalability at various sizes. We'd like to
> (no promises) have it end up around 2K. How you use that 2K is up to you.
> You can attach one honking annotation, or a thousand+ tiny ones. You can
> attach one namespace with hundreds of key/value pairs, or hundreds of
> namespaces with just one key/value pair. We want to keep things as flexible
> and open ended as possible.
>
> * What kind of data can go into an annotation?
>
> We'd like to allow for any arbitrary data to be stored in an annotation.
> Arbitrary Unicode? Sure. MIDI? Go for it. Emoji? Yes please! There might be
> some tricky edge cases though. Skip the rest of this paragraph if you don't
> care about the details of edge cases... For one, since these annotations
> will be serialized to, among other formats, XML, and we'd like to keep the
> XML succinct, the namespace and key components of an annotation triple would
> likely be an XML tag with its value as, well, its value. If that's the case
> then the data of the key must be a valid XML tag. This greatly limits what
> it can contain (not even spaces for example). If allowing all three elements
> of the triple to contain any arbitrary data is more important than a
> succinct XML payload then we'll design a more verbose XML payload. Up to you
> all really. I've included examples of both options below. Make a case for
> another proposal if you have strong opinions.
>
> * What constitutes a valid annotation?
>
> Aside from the size and data type restrictions listed above, another
> requirement is that namespaces and keys be non-empty values. Values, on the
> other hand, may be empty. In this way the namespace/key pair can be treated
> like a flag of sorts. It should be noted: I'd encourage everyone to always
> think of a namespace as a namespace, to think of a key as a key and to think
> of a value as a value. Don't take the fact that a value can be empty to mean
> that you can skip out on the whole namespace think and morph the namespace
> into a key and the key into a value. While open endedness and flexibility is
> a quality of the Annotations feature that I'm most excited about for the
> developer community, this kind of approach seems prone to causing confusion
> by undermining namespaces.
>
> * What namespaces can I write to? What namespaces can I read from?
>
> Anyone can write to or read from any namespace. We aren't planning on
> enforcing any policy that restricts someone else from adding an annotation
> with "your" namespace or seeing annotations only if they are logged in with
> a certain account. In the absence of some really compelling reason to do
> that, we want to err on the side of making this feature as flexible and open
> ended as possible. Namespaces aren't intended as a way for people to claim
> their little slice of the tweet space. Rather they are intended to
> dramatically i

[twitter-dev] Re: Local trends broken (and gone from home page?)

[Dewald Pretorius]

Perhaps Twitter should return more meaning full error messages when
API features are disabled, so that users don't see this:

http://twitpic.com/1g0e3w


On Apr 16, 1:23 pm, Abraham Williams <4bra...@gmail.com> wrote:
> http://status.twitter.com/post/516695583/local-trends-disabled
>
> Abraham
>
>
>
>
>
> On Fri, Apr 16, 2010 at 09:08, tofubeer  wrote:
> > This was reported about 2 days ago:
>
> >http://code.google.com/p/twitter-api/issues/detail?id=1584
>
> >http://twitter.com/trends/current.xmland
> >http://api.twitter.com/1/trends/(any
> > number).xml
>
> > both return:
>
> > 
> >    /trends/current.xml
> >    Sorry, you do not have access to this endpoint.
> > 
>
> > I went to see if I could change the location that I am viewing trends
> > for on the website and I cannot find the functionality (though I
> > haven't tried since after the new home page, so perhaps I am not
> > looking in the right place).  I still see the "world" trends, just no
> > ability to change to the trends for a particular location.
>
> > Has something happened to local trends?
>
> > Thanks,
>
> > ..darcy
> > --
> > D'Arcy Smith
> > CTO, Terratap Technolgies Inc.
>
> > --
> > Subscription settings:
> >http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
>
> --
> Abraham Williams | Developer for hire |http://abrah.am
> PoseurTech Labs | Projects |http://labs.poseurtech.com
> This email is: [ ] shareable [x] ask first [ ] private.- Hide quoted text -
>
> - Show quoted text -

[twitter-dev] @anywhere and JQuery

[Dewald Pretorius]

Does @anywhere check whether JQuery is already available/loaded on the
page?

If not, will it cause any problems / conflicts / bloating to have
JQuery loaded twice?


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

[twitter-dev] Re: Creating or editing applications through dev.twitter.com causes apps to lose "write access"

[Dewald Pretorius]

Ah, okay, that makes sense. It took the first app in the list and
automatically authorized it, and the first app in my list happens to
be a placeholder app.

On Apr 16, 12:22 pm, Taylor Singletary 
wrote:
> If you use the Twurl console, you're using your apps -- transparently behind
> the scenes it issues the Twurl console an access token and makes calls on
> your behalf.
>
> I'll look to get this business with read/write access resolved quickly.
>
> Taylor Singletary
> Developer Advocate, Twitterhttp://twitter.com/episod
>
>
>
>
>
> On Thu, Apr 15, 2010 at 3:06 PM, Dewald Pretorius  wrote:
> > Every single time I go tohttps://twitter.com/appsand click the
> > linked name of my app, I get an over capacity fail whale.
>
> > I also just now noticed that there was an approved app in my
> > Connections tab, which said the app was authorized today at 5:17 AM.
> > And I *most* certainly did not authorize that app today (or ever).
> > It's one of my "placeholder" apps, and I use those consumer keys
> > absolutely nowhere.
>
> > On Apr 15, 5:40 pm, "Mike Davis (mcdavis)"  wrote:
> > > Yeah, I was able to switch my app back via the old page, but just
> > > wanted to bring it to attention.
>
> > > On Apr 15, 4:35 pm, Dewald Pretorius  wrote:
>
> > > > In that case, you might not want to edit your app settings through
> > > > dev. because since early this morning, the old edit URL [1] has been
> > > > throwing a fail whale. You won't be able to restore your r/w setting.
>
> > > > [1]http://twitter.com/oauth_clients/details/
>
> > > > On Apr 15, 5:12 pm, "Mike Davis (mcdavis)"  wrote:
>
> > > > > When creating or editing an app through the new dev.twitter.comsite,
> > > > > the application will lose (or never be permitted) "write access" and
> > > > > will only have "read access".
>
> > > > > The options to choose between "read access" or "read & write access"
> > > > > that's on the old oAuth page are no longer accessible on the new dev
> > > > > page.
>
> > > > > Is this being done away with or was it just left out?- Hide quoted
> > text -
>
> > > - Show quoted text -
>
> --
> Subscription 
> settings:http://groups.google.com/group/twitter-development-talk/subscribe?hl=en-
>  Hide quoted text -
>
> - Show quoted text -

[twitter-dev] Re: User Stream's API usage

[Dewald Pretorius]

John,

I know it is still some ways off into the future, but would you
consider segmenting out the areas of user streams that don't have
privacy implications, to make those parts of the stream available to
services as a higher priority compared with the rest?

For me, social graph changes are the biggest pain point in terms of
processing and delays (and in some cases impracticality) in providing
services to users.

I can imagine that there will be scalability issues, because a service
will have to be able to subscribe to the streams of hundreds of
thousands or more users.

Nonetheless, consideration will be much appreciated.

On Apr 15, 8:32 pm, John Kalucki  wrote:
> Once the conference is over, we'll open the preview up to developers
> everywhere. A few more hours to go...
>
> -John Kaluckihttp://twitter.com/jkalucki
> Infrastructure, Twitter Inc.
>
>
>
> On Thu, Apr 15, 2010 at 3:49 PM, Isaiah Carew  wrote:
>
> > Any chance on getting access to a beta of these from outside chirp?  I had
> > to come home this afternoon and didn't get to play too much while i was
> > there, but would be really interested in playing more.  I understand it's
> > not ready for roll out.  Just looking to start the development process.
>
> > isaiah
> >http://twitter.com/isaiah
>
> > On Apr 14, 2010, at 9:26 PM, John Kalucki wrote:
>
> > I should have encouraged folks to understand the Streaming API first. You
> > can read up on all the details here:
> >http://apiwiki.twitter.com/Streaming-API-Documentation
>
> > But, for a prototype, just dive right in.
>
> > -John
>
> > On Wed, Apr 14, 2010 at 9:15 PM, Mark McBride wrote:
>
> >> Some sample APIs...
>
> >> curl 
> >> -u:http://chirpstream.twitter.com/2b/user.jso
> >> n
>
> >> Will give you a stream of your home timeline, social activity from your
> >> friends, and direct messages.
>
> >> curl -u: 
> >> "http://chirpstream.twitter.com/2b/user.jso
> >> n?track=#chirp"
>
> >> Will give you all of the above, plus any tweets matching #chirp
>
> >> Does that clear it up?  If not, I'm currently near "The Coop".
>
> >>   ---Mark
>
> >>http://twitter.com/mccv
>
> >> On Wed, Apr 14, 2010 at 6:37 PM, Kovas Boguts 
> >> wrote:
>
> >>> Hi,
>
> >>> Is there any description of how to use this? I don't understand how to
> >>> use track with this or what is generally available for hack day. Thanks!
>
> >>> On Apr 14, 2010, at 4:17 PM, John Kalucki  wrote:
>
> >>>  Email me your account name. You are in, but not getting data. Also, is
>  this account following anyone?
>
>  Typos by iPhone.
>
>  On Apr 14, 2010, at 4:11 PM, Jud  wrote:
>
>   I'm in the chrip conference IP address range, but
> >http://chirpstream.twitter.com/2b/user.jsonusage isn't clear.
>
> > - the follow predicate in a POST doesn't work (should it?)
> > - track as a predicate gets accepted, but no data comes through (I get
> > a single '{"friends":[]}', but that's it)
> > - am I supposed to be tracking userids or names or keywords?
>
> > is the resource simply not turned on until later at/on the hackathon's
> > network?
>
> > --
> > To unsubscribe, reply using "remove me" as the subject.- Hide quoted 
> > text -
>
> - Show quoted text -

[twitter-dev] Re: Creating or editing applications through dev.twitter.com causes apps to lose "write access"

[Dewald Pretorius]

Every single time I go to https://twitter.com/apps and click the
linked name of my app, I get an over capacity fail whale.

I also just now noticed that there was an approved app in my
Connections tab, which said the app was authorized today at 5:17 AM.
And I *most* certainly did not authorize that app today (or ever).
It's one of my "placeholder" apps, and I use those consumer keys
absolutely nowhere.

On Apr 15, 5:40 pm, "Mike Davis (mcdavis)"  wrote:
> Yeah, I was able to switch my app back via the old page, but just
> wanted to bring it to attention.
>
> On Apr 15, 4:35 pm, Dewald Pretorius  wrote:
>
>
>
> > In that case, you might not want to edit your app settings through
> > dev. because since early this morning, the old edit URL [1] has been
> > throwing a fail whale. You won't be able to restore your r/w setting.
>
> > [1]http://twitter.com/oauth_clients/details/
>
> > On Apr 15, 5:12 pm, "Mike Davis (mcdavis)"  wrote:
>
> > > When creating or editing an app through the new dev.twitter.com site,
> > > the application will lose (or never be permitted) "write access" and
> > > will only have "read access".
>
> > > The options to choose between "read access" or "read & write access"
> > > that's on the old oAuth page are no longer accessible on the new dev
> > > page.
>
> > > Is this being done away with or was it just left out?- Hide quoted text -
>
> - Show quoted text -

[twitter-dev] Re: Creating or editing applications through dev.twitter.com causes apps to lose "write access"

[Dewald Pretorius]

In that case, you might not want to edit your app settings through
dev. because since early this morning, the old edit URL [1] has been
throwing a fail whale. You won't be able to restore your r/w setting.

[1] http://twitter.com/oauth_clients/details/

On Apr 15, 5:12 pm, "Mike Davis (mcdavis)"  wrote:
> When creating or editing an app through the new dev.twitter.com site,
> the application will lose (or never be permitted) "write access" and
> will only have "read access".
>
> The options to choose between "read access" or "read & write access"
> that's on the old oAuth page are no longer accessible on the new dev
> page.
>
> Is this being done away with or was it just left out?

[twitter-dev] @anywhere hashtag hovercards

[Dewald Pretorius]

How about an @anywhere hovercard for hashtags?

Get those promoted tweets displayed all over the place? ;-)


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