Dewald Pretorius wrote:
> StatusNet, blog, etc.). If the privacy argument carried any water, then
bit.ly
> would be a far greater privacy threat than Twitter.
I agree, and that's why I (and others) were working on solutions to get
around bit.ly and other link shorteners. And, Twitter has already d
I was basing my statement on the blog post, which indicated that at least
some "display URLs" will be truncated:
http://blog.twitter.com/2010/06/links-and-twitter-length-shouldnt.html
"A really long link such as
http://www.amazon.com/Delivering-Happiness-Profits-Passion-Purpose/dp/044656
30
ur users are clicking on.
Only advertisers could build a privacy-improving technology and using it for
the exact opposite purpose. :(
http://mashable.com/2010/06/03/alex-payne-twitter-interview/
Regards,
Brian Smith
@BRIAN_
ou guys at Twitter. Please ask
whoever's making these horrible decisions lately to reconsider at least this
one.
Sincerely,
Brian Smith
@BRIAN_
> 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,
How are characters indexed in the indices values of entities? My guess would be
that they are indexed as Unicode code points--not bytes—and that the indexes
refer to the text before entity expansion (“&” -> “&”) is done. Is that
correct?
Like I mentioned in the previous thread, it would be v
Daniel wrote:
> Hello everyone,
> For example, I try to retrive the last tweets of a particular user I
choose "GET"
> "statuses/user_timeline" with "json" protocol and in the parameters and
values
> fields I set "id" and "radiohead" as the user screen name.
>
> The result I get is my own timeline.
This is known and expected behavior. There have been other threads about it
in the last couple of weeks. If you get a 401 response, you should compare
the Date header of Twitter's response to the current system time. If it is
significantly off then you should warn the user so they can fix it and/or
Uniqlo created a (web?) app that allows people to enter a contest or get a
discount by tweeting a message from their account; see [1]. (It also seems
like they’re not using OAuth as the tweets are “via API,” but that’s not
why I’m writing.) So many people are entering the contest that “UNIQLO
LUCKY
27;m cautiously optimistic.
/B
On Mon, May 24, 2010 at 12:43 AM, Brian Smith wrote:
I noticed about a week ago that my application stopped working. Now I have
tested it and it appears that api.twitter.com is now blocking DHE cipher
suites such as TLS_DHE_RSA_WITH_AES_128_CBC_SHA, whereas p
I noticed about a week ago that my application stopped working. Now I have
tested it and it appears that api.twitter.com is now blocking DHE cipher
suites such as TLS_DHE_RSA_WITH_AES_128_CBC_SHA, whereas previously these
DHE cipher suites were working perfectly. The DHE cipher suites have a
distin
Mr Blog wrote:
> For example, the current 'tweet' code binary is 18K bytes. If you can add
oAuth
> in 100K bytes or less, that might work, but that one function would then
still be
> bigger than the entire rest of the application. In fact, the entire file
system ROM
> image, with all the binaries
Glenn Gillen wrote:
> Without looking at how twitter.com would currently handle that example, I
> would have expected the url to be "http://dev.twitter.com/ #hot" and for
the
> tweet to contain no hashtag. If the hashtag always takes precedence I'd
have no
> way to link to the following without usi
Raffi,
I have noticed that the API sometimes returns user ID's that are out of sync
with username. I think one case is where a Alice retweets Bob's tweet, and
then Bob changes his name to Charlie. When I try to reply to it, it doesn't
show up as "in reply to" to original tweet because the reply
Alexro wrote:
> not to ignore privacy issues but just to simplify the situation a bit ...
> What currently protects a user from a malicious (desktop) application
stealing all
> kinds of user data via submitting tweets through it's proxy? And even by
> submitting such information directly to it's we
Right now the web UI exposes every piece of metadata in a tweet to
end-users. That is, an end-user can use twitter.com to check the complete
contents of tweet sent by an application. I didn't see anything in the
proposals regarding the annotation feature that says that users will be able
to see all
If an app is trusted enough to have xAuth access, it should have the ability
to do things like accept and reject followers for protected accounts via the
API. An malicious xAuth application would already have full access to the
user's account so it could already accept/reject followers through othe
Ryan Sarver wrote:
> [...] However when we dug
> in a little bit we realized that it was causing massive confusion among
user's who
> had an iPhone and were looking to use Twitter for the first time. They
would
> head to the App Store, search for Twitter and would see results that
included a
> lot
ohn Kalucki
http://twitter.com/jkalucki
Infrastructure, Twitter Inc.
On Fri, Apr 9, 2010 at 12:20 PM, Brian Smith wrote:
John,
Thank you. That was one of the most informative emails on the Twitter API I
have seen on the list.
Basically, even now, an application should not use an ID of a tweet
John,
Thank you. That was one of the most informative emails on the Twitter API I
have seen on the list.
Basically, even now, an application should not use an ID of a tweet for
since_id if the tweet is less than 10 seconds old, ignoring service
abnormalities. Probably a larger threshold (30
#x27;t break)
--Naveen Ayyagari
@knight9
@SocialScope
On Apr 8, 7:01 pm, "Brian Smith" wrote:
> 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 part
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 conce
Any app that pages through timelines uses since_id or max_id depends
responses being ordered by tweet ID. What will be the replacement for
since_id and max_id?
Taylor Singletary wrote:
We are planning to replace our current sequential tweet ID generation
routine with a simple, more scalable
It is neat (mostly for the original tweeter) to know how popular a tweet is
globally, but when reading your timeline it is much more useful to know
which of the people you follow have retweeted something. Such a
friend-centric view of rewteets and/or favoriates is what would make the
retweet functi
> Also - if the embedded user object is supposed to be constant across all
the
> returned tweets, could it be "factored out" of the tweet array and only
> transmitted once? You could send back the *whole* user object once and
then
> pages of arrays of tweets. You'd need to give the API call a new n
Marc Mims wrote:
I've never found since_id reliable. If I read the home timeline and
save the most recent since_id, I often discover that new (i.e., statuses
I've never seen) get posted out of sequence---they have lower IDs than
the most recent since_id I saved.
Do you have some example of
Zero wrote:
1. Assume we are at since_id = 1000. This was the last (highest)
message id we had previously seen, which we have saved.
2. There is a sudden spiked and 2000 tweets come in.
3. We now try to query with since_id=1000, count=200 (the max).
Unfortunately, we have missed
1800 tweets
Hi Taylor,
I tried %20 along with a lot of other things and was the only
thing that worked in all places -- the web, Twitter clients, and SMS
messages to cell phones. Other than this problem, it has worked great
for nine months. If Twitter has made changes such that %20 will now
work where
srikanth reddy wrote:
The problem is with the original retweet status id only. we always
give original status id for status/retweet method not your friends
retweeted status id.After retweeting this original status how do you
prevent the user from retweeting this original status again.
As far as
Jaanus wrote:
Is there a reason why the OAuth URL in the api wiki could not be HTTPS
by default? Why would you want to recommend HTTP over HTTPS? (I know
that OAuth was designed to be safe over HTTP, immune against man-in-
the-middle and all, but HTTPS just gives me a warm and fuzzy feel. ;)
I
Ryan Sarver wrote:
This is an announcement that we will be deprecating the
*/statuses/public_timeline* resource as of April 5th (4/5/10). Please
let us know if there are any major concerns.
Just to be perfectly clear: is it being deprecated or disabled on that date?
Thanks,
Brian
srikanth reddy wrote:
@Abraham
One thing you cant do with the API is
Preventing users from retweeting their friends retweet which has
already been retweeted by the user .
Never retweet a retweet. If the user selects a retweet and tries to
retweet it, your app should find the original tweet's st
Dewald Pretorius wrote:
Raffi,
There appears to be ground for confusion here. I'm sure some folks are
still sending some API calls to twitter.com.
Could you please put up a page that explains which calls *must* go to
api.twitter.com, and after tomorrow won't work on twitter.com? And
vice versa,
Raffi Krikorian wrote:
i think this experiment in engaging the community around designing
this security/identity workflow has been definitely a success, and i
feel we're rapidly converging on a solution for identity verification
delegation. in parallel, we're going to start the process to enga
yegle wrote:
Basically, a API proxy script works as a middleman between twitter and
twitter client, little like man-in-the-middle attack.It's possible to
do this if the authentication is made in HTTP basic auth.But there is
no way to do the same thing with OAuth. The base string of an OAuth
reque
Raffi Krikorian wrote:
in general, i really like this mechanism. from just a usability
standpoint, however, it means that the consumer has to make a few
calls simply to perform one action -- they have to call Twitter and
then the service provider. on top of that, a real world example would
h
Raffi Krikorian wrote:
The term most frequently used for “delegator” is “relying party.”
What you call the service provider is most frequently called the
“identity provider.” What you call the consumer is usually called
the “subject.” See OpenID, InfoCard, and other similar
The term most frequently used for "delegator" is "relying party." What you
call the service provider is most frequently called the "identity provider."
What you call the consumer is usually called the "subject." See OpenID,
InfoCard, and other similar specifications for example usage of these terms
In the example, would the user have to grant TwitPic access to his account?
I would like to be able to assure TwitPic about the user's identity without
the user having to grant TwitPic any read or read/write access to his
account.
Why does the delegator need to send the service provider x_reque
You do support TLS session resumption already though. Session resumption is
where one HTTPS connection reuses the same handshake as a previous HTTPS
connection.
% openssl s_client -connect api.twitter.com:443 --reconnect
.
Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
.
Session-ID: C076
1. The page needs to display correctly (laid out nicely, with the
entire form "above the fold") on a 2.4" QVGA (240x320 and 320x240) screen
when images, Javascript, and flash are all disabled.
2. Replace the manual PIN entry requirement with something else. The
OAuth 1.0a designers grea
PJB wrote:
> > On Oct 21, 8:01 pm, Dewald Pretorius wrote:
> > > On Wednesday afternoon/evening the 502s and connection refuses have
> > > been coming thick and fast, much worse than earlier in the week.
> >
> > > When can we expect to see an improvement instead of a worsening of
> > > the API's
Usually non-GET requests are not counted toward the rate limit.
I agree that an “add in bulk” command would be better than having to
individually issue multiple “add user to lists” calls.
Rod Begbie wrote:
3) Does each "add user to list" call count towards the API Limit? If so, are
th
(of course, one masquerading as a legitimate client) that would store it and
use it than someone stealing your device. Moreover, many less-than-savvy users
tend to use the same password for many accounts, including accounts containing
very sensitive information.
On Mon, Oct 12, 2009 at 20:36,
Letting a mobile/desktop app grab an OAuth token using the user’s
username/password is still helpful because then they can store the token
instead of the username/password, which is a big deal when there’s no really
secure way to store it. Also, if your mobile phone/laptop gets stolen, you can
Ryan Sarver wrote:
> 1. What can be improved about the web workflow?
* On many mobile platforms--even some of the newest ones--copy & paste is
unavailable, and/or users simply do not know how to do it.
* A 7-digit PIN is too long for most users to remember long enough to switch
apps and type it
Duane Roelands wrote:
> I read it, and I was horrified. So, I logged into IRC and found two
> members of the OneForty development team. I asked them to remove my
> application from the directory.
>
> They refused.
>
> OneForty is not a developer-friendly platform.
That is unfortunate. If they
John Kalucki wrote:
> No. If we are to offer real-time social graph changes, they'll be via
> the Streaming API. In the mean time, there is no low-latency high-
> throughput way to determine changes to the social graph. Attempts to
> simulate this at large scale via repeated polling are likely to
John,
Based on your description, it looks like you are on the verge of being able
to offer a very useful capability: the ability to query the follows AND
unfollows since the last time you checked. That would be a great addition to
the API.
For example, I'd really like to be able to page through
Marcel Molina wrote:
> The above payloads don't contain a "retweet_count" element yet and
> they probably will. Other than that we don't suspect any more major
> changes as we approach a full public launch. As always, though, we're
> open and solicitous of everyone's feedback.
This is a great imp
Dossy Shiobara wrote:
> It would be nice if Twitter made "authentication only" as an option for
> OAuth.
Twitter already has this. It is called "Sign in with Twitter."
- Brian
Marcel Molina wrote:
> To give you some ideas of how you can use the API to display retweets,
> here is a recent mock up of one of the potential UIs for the retweets
> timeline on twitter.com:
> http://a1.twimg.com/example-retweet-ui-18-sep-09.png
In this example, how did you retrieve the number
Mageuzi wrote:
> I'm sorry for posting a follow up so soon, but I spent another few
> hours trying to debug this again last night, and still without
> success. It seems to be encoding the characters properly (%65E5%672C
> %72AC in this case), and so I assume it is generating the signature
> prope
Guytom wrote:
> One thing we don't understand and maybe causing the problem is what
> should we do with the oauth_token_secret?
http://oauth.net/core/1.0a#anchor15
"... the key is the concatenated values ... of the Consumer Secret and Token
Secret, separated by an '&' character (ASCII code 38) .
Paul Kinlan wrote:
> The issue with favorites is that are personal to a user
> and a tweet so are not visible in the UI to everyone
> else (which is something that the RT seems to be trying
> to solve), and also track re-tweets as they are two
> different things.
>
> You can get a users favorites
Paul Kinlan wrote:
> Favorites are open to be read, it is just that not many
> people use it and I can't actually find who favorited my
> tweets - (probably no one in my case ;) - if I had that
> information I could do a lot of things (with out
> resorting to the RT stream).
I tried it and you ar
jim.renkel wrote:
> 7. If retweets and status updates are numbered from the same sequence
> of IDs, then presumably statuses/destroy can be used to delete a
> retweet. If retweets and status updates have separate ID sequences,
> then I don't see any way to delete a retweet. I think the ability to
@janole wrote:
> Will it be possible to "comment" on the retweeted tweet? If not,
> people might just continue to use the current "RT ..." convention.
>
> Retweeting can be a way of acknowledging a tweet or disapproving a
> tweet etc.
>
> If you search for "RT" in search.twitter.com you'll see
The OAuth UI doesn't work acceptably on the mobile phones I am targeting.
So, I am thinking about embedding a custom browser into my application, so I
can render the OAuth web pages appropriately for the phone. I do not see
anything in the ToS that forbids building a custom browser to use for the
O
Infopete wrote:
>
> It looks like I get get this much in
> http://www.infonote.com/tw?1234567890123
> before it gets converted to bit.ly
Try removing the "?". Some people have already researched the circumstances
under which URLs get shortened vs. left alone. IIRC, one requirement is that
all ch
59 matches
Mail list logo
