We've built http://twlisted.com and the app is up and working and the
database is in very good shape, but we've been sidetracked onto other
(paying) projects and don't have the bandwidth to give this the
attention that it needs.
This is a machine driven directory of Twitter lists. Sort of like
I'm working on an iPhone app using xAuth (which is great!). I'm
exchanging user credentials for an access token, storing it and using
the token to make subsequent calls to the API's just fine. I'm having
trouble however with the account update_profile_image API (http://
Dear Developers,
I'm sure we’re a lot - in this group - to have our ticket for Chirp,
and I wanted to launch a thread so we could know each other a little
better, before the conference starts.
The conference looks very promising on a technical side: we’re going
to learn from the expert, practice
There is no API endpoint that I know of and don't think one should exist.
Users should not trust
thirdparties to self-revoke access to their accounts. Users should know how
to do it from twitter.com
via the connections page. It might be nice if we could generate a redirect
link to a page on
Hi Arnaud All
I'm also making the trip across the Atlantic with a group of Brits
under the heading of the Developer Mission:
http://developermission.com
Please get in touch with me off list if any of you are also travelling
a long way to get to San Francisco. We have a bunch of activities
A scenario for justifying invalidateToken:
- User visits AwesomeApp and wants to connect his Twitter account
- AwesomeApp redirects to Twitter's OAuth flow
- User fails to notice that someone else, UserX, is already logged in to
Twitter in the current browser and clicks through
-
Thank you for the feedback. It's great to hear about the variety of use
cases people have for the API, and in particular all the different ways
people are using IDs. To alleviate some of the concerns raised in this
thread we thought it would be useful to give more details about how we plan
to
On Thu, Apr 1, 2010 at 10:47 AM, Dewald Pretorius dpr...@gmail.com wrote:
Mark,
It's extremely important where you have two bots that reply to each
others' tweets. With incorrectly sorted tweets, you get conversations
that look completely unnatural.
I'd love to see an example of two bots
On Thu, Apr 8, 2010 at 5:39 PM, Nick Arnett nick.arn...@gmail.com wrote:
I'd love to see an example of two bots replying to each other and looking
entirely natural!
We all knew this sort of thing was going on, removing the pesky humans from
the loop, but I always thought it was
What does “within the caveats given above” mean? Either since_id will work or
it won’t. It seems to me that if IDs are only in a “rough” order, since_id
won’t work—in particular, there is a possibility that paging through tweets
using since_id will completely skip over some tweets.
My
This was my initial concern with the randomly generated ids that I
brought up, though I think Brian described it better than I.
It simply seems very likely that when using since_id to populate newer
tweets for the user, that some tweets will never be seen, because the
since_id of the last message
It's a possibility, but by no means a probability. Note that you can
mitigate this by using the newest tweet that is outside your danger zone.
For example in a sequence of tweets t1, t2 ... ti ... tn with creation
times c1, c2 ... ci ... cn and a comfort threshold e you could use since_id
from
This should be fixed now. Tweets tagged with a place should be correctly
dispatched to geohose clients.
---Mark
http://twitter.com/mccv
On Fri, Apr 2, 2010 at 10:51 PM, M. Edward (Ed) Borasky
zn...@comcast.netwrote:
On 04/02/2010 09:37 PM, Mark McBride wrote:
You can file an issue, but
Ahh, yes, your workaround is a little better than mine, but it is
still a work around and requires changes to how since_id is currently
used by what I have assume is most applications. I understand the need
for change and am willing to work around it, I can imagine the
scalability issues of trying
On 04/08/2010 04:38 PM, Mark McBride wrote:
This should be fixed now. Tweets tagged with a place should be correctly
dispatched to geohose clients.
---Mark
http://twitter.com/mccv
Thanks!! Now all I need is for twitter.com to stop saying, Unable to
locate you - Try Again ;-) Probably a
I've done exactly what the docs say to do for xAuth (http://
apiwiki.twitter.com/Twitter-REST-API-Method%3A-oauth-access_token-for-
xAuth). Yet I keep getting Failed to validate oauth signature and
token. The only thing the docs doesn't note is the secret key that is
used to sign. Am I suppose to
Mark, thank you for taking the time to respond.
What is the smallest “comfort threshold” that will guarantee that we will see
all the tweets, with none skipped over and the fewest tweets returned multiple
times?
Let’s say the comfort threshold was 2 seconds. It seems to me like there
Hi,
I'm trying to a pull in a user's profile picture and use it as their
profile picture on my site. Am I allowed to store the URL in my
database (until the user deletes the account/removes the image)? Or
are there terms in the Twitter API which suggests that I'm not allowed
to store information
On Apr 9, 2:24 am, John munz...@gmail.com wrote:
The only thing the docs doesn't note is the secret key that is
used to sign. Am I suppose to use the consumer secret or do I need to
get a token secret as well then combine them like in oauth requests?
You need to use the consumer secret at
I've done exactly what the docs say to do for xAuth (http://
apiwiki.twitter.com/Twitter-REST-API-Method%3A-oauth-access_token-for-
xAuth). Yet I keep getting Failed to validate oauth signature and
token. The only thing the docs doesn't note is the secret key that is
used to sign. Am I
20 matches
Mail list logo
