[twitter-dev] Re: In San Francisco for WWDC? Come to Twitter HQ on June 9th 6-8pm for a @twitterapi meetup!
Hey, any chance of ever having one of these meetups in the UK?! On Jun 7, 12:48 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Mac Devs, This time last year we hosted an informal meetup of WWDC attendees. The event turned into a fun evening so we've decided to do it again. We are inviting WWDC attendees and Twitter Platform developers to our office on Wednesday, June 9, at 6PM. There is limited space, so please register athttp://bit.ly/twitterapi-wwdcif you would like to join. During the meetup, we plan to discuss xAuth, OAuth Echo, give an update on annotations, see demos of iPhone, iPad, and Mac apps and hold an open QA. If you would like to apply to demo your Mac-based app, please fill out this form:http://bit.ly/asvBwI. Around 8 o'clock, we will all head out for a few drinks to close out the evening. We hope to see you there. Hope to see you there! Thanks, The @twitterapi Team
[twitter-dev] Retweets not showing up?
I'm looking at home_timeline it doesn't seem like retweets are showing up for me? Also, what type of retweets are supposed to show up in mentions? Users that retweeted a mention of you I assume? Neither of these things seem to be working for me. Anyone else seeing this?
[twitter-dev] issue with XAUTH response
Hi,
We got XAuth approval for outr application.
We are forming the URL and posting to api.twitter.com
We are getting HTTP error 500 - Internal server error
URl detaisl are given below.
Kindly help us to resolve the issue
Signature Base String
---
POSThttps%3A%2F%2Fapi.twitter.com%2Foauth%2Faccess_token
oauth_consumer_key%3Do10LlaYRx9HZAANF75kg%26
oauth_nonce%3DyePdrFfzkCRTrTPem+fCstEA2JM%26
oauth_signature_method%3DHMAC-SHA1%26
oauth_timestamp%3D1276005168%26
oauth_version%3D1.0%26
x_auth_mode%3Dclient_auth%26
x_auth_password%3D%26
x_auth_username%3Dbrewbird
Header Body
-
Content-Type:application/x-www-form-urlencoded
Authorization: OAuth oauth_nonce=v0ZYuHC6UakS6ACTGfC9+7iDe18,
oauth_signature_method=HMAC-SHA1,
oauth_timestamp=1276005185,
oauth_consumer_key=o10LlaYRx9HZAANF75kg,
oauth_signature=RjRxIqWnZOCe9TjNFiyGkuqMOOo=,
oauth_version=1.0
Resposne from server
---
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://
www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
html xmlns=http://www.w3.org/1999/xhtml; lang=en xml:lang=en
head
meta http-equiv=Content-Type content=text/html;
charset=utf-8 /
meta http-equiv=Content-Language content=en-us /
titleTwitter / Error/title
link href=http://s.twimg.com/images/favicon.ico; rel=shortcut
icon type=image/x-icon /
style type=text/css
/* Page
--- */
* { border: 0; padding: 0; margin: 0; }
body{ margin: 10px 0; background:#C0DEED url(http://s.twimg.com/
images/bg-clouds.png) repeat-x; color:#333; font: 12px Lucida Grande,
Arial, sans-serif; text-align:center }
#container { width: 755px; margin: 0 auto; padding: 0px 0; text-
align: left; position: relative; }
#content { width: 100%; margin-top: 8px; float: left; padding-
bottom: 15px; background: transparent url(http://s.twimg.com/
Thanks
P.Boopathi
[twitter-dev] Re: Cannot obtain access token for authenticated user when a callback url is sent
Hi Taylor,
Thanks for the pointers you wrote in the previous post. I had a
recheck in my program flow based on your pointers.
I send the callback url during signing of the request itself(GET
request). I have added its as default parameter in my header all the
time.
Here's how it looks:
{'oauth_version': '1.0', 'oauth_token': 'xxx',
'oauth_nonce': 'qwqwqe4234werwr', 'oauth_timestamp': '1276004627',
'oauth_signature': 'I=', 'oauth_consumer_key':
'xxx', 'oauth_signature_method': 'HMAC-SHA1',
'oauth_callback': 'http://10.1.1.112:8000/register/authenticated/
aswq34ertyu1dfg'}
After this I get this as the response(after authorization from twitter
end),
{'oauth_version': '1.0', 'oauth_token': '1.0 encoding',
'oauth_nonce': '30495529', 'oauth_timestamp': '1276004628',
'oauth_signature': '=', 'oauth_consumer_key':
'xx', 'oauth_signature_method': x', 'oauth_callback':
'http://10.1.1.112:8000/register/authenticated/aswq34ertyu1dfg'}
As you can see in 'oauth_token' key, the value is incorrect it should
have been the oauth token of the authorized user.
Could you still further throw some light as to what exactly wrong is
going on. It'll be of great help if you could give some more pointers
as I'm not at all able to figure it where am I missing the link.
On Jun 7, 7:32 pm, Taylor Singletary taylorsinglet...@twitter.com
wrote:
Hi Avinash,
In OAuth 1.0a, you specify your callback URL on the request token step, and
you specify it just like the other OAuth parameters in that request. If
you're using HTTP-header-based OAuth, that means the callback URL should be
in your signature base string and Authorization header. If you're using
query-string-based OAuth or using the POST body to send OAuth parameters,
then the oauth_callback should be in both the parameters as well as the
signature base string.
By specifying your callback URL in the request token step, you should also
get back a parameter in the response indicating that it was recognized
oauth_callback_confirmed
Taylor Singletary
Developer Advocate, Twitterhttp://twitter.com/episod
On Sat, Jun 5, 2010 at 12:24 AM, avinash avinash...@gmail.com wrote:
Hi,
I'm using the oayth2 python binding from
http://github.com/simplegeo/python-oauth2.
1. I perform a request for obtaining 'Request token' I send the
following parameters:
{'oauth_consumer_key': x,
'oauth_timestamp': x,
'oauth_nonce': ,
'oauth_version': x}
Also I sign in the request with HMAC signature base string
This yields me oauth request token and oauth request secret.
2. Now using this I send the user fro authorization by calling the
url:
http://twitter.com/oauth/authenticate?oauth_token=
3. Once the user is authorized, he/she is redirected to a callback url
that I have specified in my app setting while registration. It is this
callback url that I want to override.
When should this overriding take place?Should I place the parameter
oauth_callback from the very beginning of the request(while requesting
Request Token) or once the user is authorized?
I tried to put the parameter 'oauth_callback' as a default parameter
in my request header. It worked fine till authorization but once once
authorization succeeded I could not obtain correct access token and
access token request for that authorized user. What I get is this:
{oauth_nonce: , oauth_timestamp:x, oauth_token: xxx,
oauth_token_secret: HMAC-1, oauth_verify:xx,}
Note: The oauth_token is incorrect as I know the correctb token for
that user is something else.
But while I do not try to override the oauth_callback url everything
is working smoothly(I obtain the correct oauth token and secret for
that user)
As far as the url is concerned its just my local machine's ip that
I've provided in my callback url(app settings),http://10.1.1.112
;8000/register/authenticated/
and I tried to override it withhttp://10.1.1.112
;8000/register/authenticated/?q=x
Please suggest where am I going wrong?Or are there any steps that I'm
not following?Please highlight them if any.
Avinash
On Jun 4, 6:52 pm, Taylor Singletary taylorsinglet...@twitter.com
wrote:
Could you share some of the steps of your request while setting your
oauth_callback?
* Signature Base String
* Your Authorization header
* Any POST body you are sending
* The exact URL you are executing
What happens when you complete the authorization step? What specifically
does not happen?
Taylor Singletary
Developer Advocate, Twitterhttp://twitter.com/episod
On Fri, Jun 4, 2010 at 6:08 AM, avinash avinash...@gmail.com wrote:
Hi,
I'm working on a web app(interacts with twitter) which uses an oauth
protocol for user authorisation. I had registered my app at twitter
with a specified callback url. But while I make an request I override
it by binding
[twitter-dev] Re: Issue with posting to twitter: http://twitter.com/home?status=doesnotworkifyouarenotloggedin
Any news on this issue ? On 29 mai, 00:12, themattharris thematthar...@twitter.com wrote: Hi Priyanka, Thanks. We're aware of the problem and it is being tracked as ticket 1650 [1] on the twitter-api issues log. 1.http://code.google.com/p/twitter-api/issues/detail?id=1650 Matt On May 27, 8:24 pm, newtothisworld priyankalut...@gmail.com wrote: Hi, It appears that if you are not logged in, and hit the following URL:http://twitter.com/home?status=doesnotworkifyouarenotloggedin, you lose the status you were trying to post. I'm very certain this used to work until a few days ago. Has something changed? Thanks for your help! Priyanka
[twitter-dev] Re: Annotations with data types
+1 I think you make a good point. It's no extra effort to append the data type to the name. If annotations is to become a wild west then assuming everything is a string unless proven otherwise is a little rediculas. It might be better to take it one step further since above you usefloat when really you mean latitude expressed as float. Likewise 0xff is an int but realy I mean color so a heiracrchy of types would make more sense? i.e. seconds since 2000 - long - 318391231231 Ian http://www.twiper.com
Re: [twitter-dev] We need some help please
Hi SlideInCode, If you're asking for login and password on your website to invoke use of the API, you're going to need to do some work to continue having a functional integration after our basic authentication method departs later this month. This kind of frictionless API integration you seem to desire is best accomplished using our @Anywhere platform http://dev.twitter.com/anywhere/where the amount of steps to getting valid user authorization and sending tweets on their behalf is minimized and streamlined in comparison to a robust OAuth 1.0a-based REST integration with callbacks. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Mon, Jun 7, 2010 at 7:01 PM, SlideInCode cont...@wholesale-portal.comwrote: We need some help please... We have a new service that is launching in just a few weeks (June 22nd). We have been developing this script since March 2009, and now with the new oAuth integration we are concerned as to whether we can still integrate twitter into our service for our members. Our entire web site, sales video and training material focuses on the twitter integration we performed, so a solution is our only option, as we do not have the time to edit the promotional videos, website and content. Here is an example of how the existing integration has taken place: http://bit.ly/dt2LRm The user would simply input their username and password to tweet the clients message and follow them. Upon completion, a thank you message is displayed within the SlideIn. The point of our script is to create an unobtrusive and simple experience that users can enjoy the simplicity of. There is no redirection or new pages to view...everything happens within the slidein, and the users do not lose focus of the initial website they are browsing. We are excited to offer real-time validation to our clients so they are assured valid tweets and followers. However, we require assistance and hope that we can still intergrate twitter in the same or similar manner, without visitors having to leave the website. Please do advise if you can help - willing to pay for solution. Thank you. SlideInCode
[twitter-dev] Sign out of Twitter through API
I'm developing an application designed to run on a public computer, where many users will sign in with Twitter to register for our app. I've been looking for a way to sign the user out of Twitter when they exit the application (though a sign out button). Since we cannot destroy the cookies set by twitter.com, all it does right now is destroy our own session and cookies and show a button which links to the Twitter sign out page (in a popup). We would prefer not to use the popup, but instead sign the user out of Twitter automatically when they sign out of our application. This will greatly reduce the likeliness of people forgetting to logout (and thus allowing access to their own account by the next user). We're already using force_login=true to force a new login when someone connects to our application, but then it could already be too late. Is there any way to call a sign out through the API? Account/end_session seems to be what I'm looking for, but I can't get it to work. Another approach would be to scrape twitter.com for the authenticity_token and call the logout from through cURL, but this isn't the nicest way to do things and my first attemps have failed so far.
[twitter-dev] Fetch timeline fo application users
Hello, How can I fetch all messages from users that use my Application? I can fetch messages from all users, that I follow, but how can I do it from application without user? Thanks.
Re: [twitter-dev] Fetch timeline fo application users
There's no super-efficient way to do this at this time. If you're trying to track all the public tweets issued by users of your application, the Streaming API's filter/follow features might serve some of what you're trying to accomplish. http://apiwiki.twitter.com/Streaming-API-Documentation#statuses/filter Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Tue, Jun 8, 2010 at 7:36 AM, o...@emby.ru 816...@gmail.com wrote: Hello, How can I fetch all messages from users that use my Application? I can fetch messages from all users, that I follow, but how can I do it from application without user? Thanks.
[twitter-dev] Rate limits, bad gateway, etc.
I have a Perl script that downloads historical tweets using the user_timeline REST API call. I'm running into 503 - Bad Gateway - Twitter / Over capacity errors when I run it. Questions: 1. When I run into an error, I'm waiting 45 seconds before retrying. Should I wait longer? Is there a shorter recommended wait time after an Over capacity error? Do I need to wait at all? 2. In normal operation, I'm using the returned rate limit header information to pace the request rate so that I never run out of calls. This can generate a call as soon as I've completed processing of the previous data. Should I insert a non-zero wait time here? I've tested explicit wait times as high as 20 seconds here and they don't seem to be reducing the incidence of Over capacity errors.
[twitter-dev] Re: Problem with the API Console
Taylor, Can you take the GET commands out of the form until they work? Will save a lots of people some time. Thanks, Sharad On May 26, 8:51 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Daniel, There are still some bugs here and there with theAPIconsolethat we haven't had a chance to clean up yet. Another alternative you can use to explore theAPIfrom a web-basedconsoleis the greatAPIconsoleApigee provides athttp://app.apigee.com/console Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod On Wed, May 26, 2010 at 4:47 AM, Daniel danybo...@gmail.com wrote: Hello everyone, I'm new to the twitterAPIand found theAPIConlose (http:// dev.twitter.com/console) very handy to try requests and understand what you can do with it, but I'm kind of stuck with the impossibility to set up parameters : 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. That is the default result when you set no parameters at all and the parameters don't show up in the generated request either. Am I missing something ? A basic search on Google and this website, and the reading of the FAQ didn't show up anything interesting. Does anyone else experience this problem ? Thanks.
Re: [twitter-dev] Re: Cannot obtain access token for authenticated user when a callback url is sent
Hi Avinash,
First, it's most appropriate to use a POST on the request token and access
token steps of the OAuth flow (though GET will work fine).
You might be having your issues because you are sending the oauth_token as
part of your request in the request token step. The request token step of
OAuth is essentially a two-legged operation, without a user authorized
element (which the oauth_token and oauth_token_secret comprise). You
shouldn't be sending either a key or value for oauth_token at this stage,
and your composite signing key in this step would simply be your consumer
secret and the ampersand, properly escaped.
You should also limit sending the oauth_callback to ONLY the request_token
step -- its existence at any other step is invalid.
Taylor Singletary
Developer Advocate, Twitter
http://twitter.com/episod
On Tue, Jun 8, 2010 at 6:57 AM, avinash avinash...@gmail.com wrote:
Hi Taylor,
Thanks for the pointers you wrote in the previous post. I had a
recheck in my program flow based on your pointers.
I send the callback url during signing of the request itself(GET
request). I have added its as default parameter in my header all the
time.
Here's how it looks:
{'oauth_version': '1.0', 'oauth_token': 'xxx',
'oauth_nonce': 'qwqwqe4234werwr', 'oauth_timestamp': '1276004627',
'oauth_signature': 'I=', 'oauth_consumer_key':
'xxx', 'oauth_signature_method': 'HMAC-SHA1',
'oauth_callback': 'http://10.1.1.112:8000/register/authenticated/
aswq34ertyu1dfg'}
After this I get this as the response(after authorization from twitter
end),
{'oauth_version': '1.0', 'oauth_token': '1.0 encoding',
'oauth_nonce': '30495529', 'oauth_timestamp': '1276004628',
'oauth_signature': '=', 'oauth_consumer_key':
'xx', 'oauth_signature_method': x', 'oauth_callback':
'http://10.1.1.112:8000/register/authenticated/aswq34ertyu1dfg'}
As you can see in 'oauth_token' key, the value is incorrect it should
have been the oauth token of the authorized user.
Could you still further throw some light as to what exactly wrong is
going on. It'll be of great help if you could give some more pointers
as I'm not at all able to figure it where am I missing the link.
On Jun 7, 7:32 pm, Taylor Singletary taylorsinglet...@twitter.com
wrote:
Hi Avinash,
In OAuth 1.0a, you specify your callback URL on the request token step,
and
you specify it just like the other OAuth parameters in that request. If
you're using HTTP-header-based OAuth, that means the callback URL should
be
in your signature base string and Authorization header. If you're using
query-string-based OAuth or using the POST body to send OAuth parameters,
then the oauth_callback should be in both the parameters as well as the
signature base string.
By specifying your callback URL in the request token step, you should
also
get back a parameter in the response indicating that it was recognized
oauth_callback_confirmed
Taylor Singletary
Developer Advocate, Twitterhttp://twitter.com/episod
On Sat, Jun 5, 2010 at 12:24 AM, avinash avinash...@gmail.com wrote:
Hi,
I'm using the oayth2 python binding from
http://github.com/simplegeo/python-oauth2.
1. I perform a request for obtaining 'Request token' I send the
following parameters:
{'oauth_consumer_key': x,
'oauth_timestamp': x,
'oauth_nonce': ,
'oauth_version': x}
Also I sign in the request with HMAC signature base string
This yields me oauth request token and oauth request secret.
2. Now using this I send the user fro authorization by calling the
url:
http://twitter.com/oauth/authenticate?oauth_token=
3. Once the user is authorized, he/she is redirected to a callback url
that I have specified in my app setting while registration. It is this
callback url that I want to override.
When should this overriding take place?Should I place the parameter
oauth_callback from the very beginning of the request(while requesting
Request Token) or once the user is authorized?
I tried to put the parameter 'oauth_callback' as a default parameter
in my request header. It worked fine till authorization but once once
authorization succeeded I could not obtain correct access token and
access token request for that authorized user. What I get is this:
{oauth_nonce: , oauth_timestamp:x, oauth_token: xxx,
oauth_token_secret: HMAC-1, oauth_verify:xx,}
Note: The oauth_token is incorrect as I know the correctb token for
that user is something else.
But while I do not try to override the oauth_callback url everything
is working smoothly(I obtain the correct oauth token and secret for
that user)
As far as the url is concerned its just my local machine's ip that
I've provided in my callback url(app settings),http://10.1.1.112
;8000/register/authenticated/
and I tried to override it
Re: [twitter-dev] issue with XAUTH response
Hi,
What does your POST body look like in this example? Are you including *only*
the x_auth_* parameters in the POST body? Have you escaped the usernames and
passwords? If there's any escaping that must happen for a username and
password, within the signature base string, you'll have to encode the values
again.
Taylor Singletary
Developer Advocate, Twitter
http://twitter.com/episod
On Tue, Jun 8, 2010 at 7:02 AM, Boopathi 2boopa...@gmail.com wrote:
Hi,
We got XAuth approval for outr application.
We are forming the URL and posting to api.twitter.com
We are getting HTTP error 500 - Internal server error
URl detaisl are given below.
Kindly help us to resolve the issue
Signature Base String
---
POSThttps%3A%2F%2Fapi.twitter.com%2Foauth%2Faccess_token
oauth_consumer_key%3Do10LlaYRx9HZAANF75kg%26
oauth_nonce%3DyePdrFfzkCRTrTPem+fCstEA2JM%26
oauth_signature_method%3DHMAC-SHA1%26
oauth_timestamp%3D1276005168%26
oauth_version%3D1.0%26
x_auth_mode%3Dclient_auth%26
x_auth_password%3D%26
x_auth_username%3Dbrewbird
Header Body
-
Content-Type:application/x-www-form-urlencoded
Authorization: OAuth oauth_nonce=v0ZYuHC6UakS6ACTGfC9+7iDe18,
oauth_signature_method=HMAC-SHA1,
oauth_timestamp=1276005185,
oauth_consumer_key=o10LlaYRx9HZAANF75kg,
oauth_signature=RjRxIqWnZOCe9TjNFiyGkuqMOOo=,
oauth_version=1.0
Resposne from server
---
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://
www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
html xmlns=http://www.w3.org/1999/xhtml; lang=en xml:lang=en
head
meta http-equiv=Content-Type content=text/html;
charset=utf-8 /
meta http-equiv=Content-Language content=en-us /
titleTwitter / Error/title
link href=http://s.twimg.com/images/favicon.ico; rel=shortcut
icon type=image/x-icon /
style type=text/css
/* Page
--- */
* { border: 0; padding: 0; margin: 0; }
body{ margin: 10px 0; background:#C0DEED url(http://s.twimg.com/
images/bg-clouds.png) repeat-x; color:#333; font: 12px Lucida Grande,
Arial, sans-serif; text-align:center }
#container { width: 755px; margin: 0 auto; padding: 0px 0; text-
align: left; position: relative; }
#content { width: 100%; margin-top: 8px; float: left; padding-
bottom: 15px; background: transparent url(http://s.twimg.com/
Thanks
P.Boopathi
Re: [twitter-dev] failed to validate oauth signature and token
Hi EL, Thanks for obscuring your secrets in your post. One issue I see here is that you're providing an oauth_callback in your POST data, but it's not included in your signature base string. If you're using POST-based OAuth (as opposed to query string or HTTP header based OAuth), then your OAuth parameters should be in both locations. If you're using HTTP-based OAuth, then you shouldn't be including any oauth_* parameters in your body at all. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Mon, Jun 7, 2010 at 9:53 AM, EL lee@googlemail.com wrote: Hi, Im trying to implement OAuth using JavaScript, but when I make my request to http://api.twitter.com/oauth/request_token I am getting the above message in the response (failed to validate oauth signature and token). As far as I can tell I'm including all the correct parametes, both in the encoding of the signature base: basestring: (consumer key removed for security) POSThttp%3A%2F%2Ftwitter.com%2Foauth%2Frequest_token%26oauth_callback %3Doob%26oauth_consumer_key %3D112%26oauth_nonce %3DO3cHsSXrfnzT%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp %3D1275928008%26oauth_version%3D1.0 consumer secret: (removed for security) 112 Signature: R3eHMuQ04F37+xPJSIsoo0aMzc8 Post Data: (consumer key removed for security) oauth_callback=ooboauth_consumer_key=112oauth_signature_method=HMAC- SHA1oauth_signature=pjDh8jkp89ThBtzz +B9dQmxQfcgoauth_timestamp=1275928413oauth_nonce=qyq3Jhn8rtTZoauth_ve +rsion=1.0 And I've checked that the clock is correct on my device as that's the only real result I can find for this problem :( The nonce is unique and generated every time it runs... Unfortunately I don't know where to look now. I can't spot anything obvious. Any suggestions? many thanks
Re: [twitter-dev] Re: Authorization Question
Hi Michael, Judging by the output Curl is giving you here, it doesn't look like the header is being set correctly on this step. The header that you're presenting should also be comma separated on each discreet element. The header also should not include your POST parameters (like status in this example). In my experience, most people who have issues with OAuth generation in Javascript have issues because the HMAC-SHA1 library they selected (or implemeneted) isn't doing something correctly. Also, you should be using the api subdomain on these requests: api.twitter.com A more proper curl request might look like, assuming the signature was re-generated using the proper hostname and all elements were correct: curl -k -v -X POST -H 'Authorization: OAuth realm=,oauth_consumer_key=yJDLH7BDdVi1OKIINSV7Q, oauth_token=142715285-yi2ch324S3zfyKyJby6WDUZOhCsiQuKNUtc3nAGe,oauth_nonce=1275928907blah,oauth_timestamp=1275928907,oauth_signature_method=HMAC-SHA1,oauth_version=1.0,oauth_signature=Kf1epCD5j7nWg9dLgtkT5OJXoQQ%3D' -d status=Hello https://api.twitter.com/statuses/update.json Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Mon, Jun 7, 2010 at 10:04 AM, Michael Cameron darx...@gmail.com wrote: Thanks Taylor, One last question. i am trying to debug on why i can not send messages with twitter, now i am trying to get any response from twitter that works. and can not seem to get it to work. I am trying cURL to get a response but i always get Could not authenticate you. i am using http://www.jaanuskase.com/en/2010/01/understanding_the_guts_of_twit.html website to figure out how, and the http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/ to create my request examples, I want to ensure i have something working to debug my javascript code. so in essence i can not get this to work: C:\curl -k -v -X POST -H 'Authorization: OAuth realm=oauth_consumer_key=yJDLH7BDdVi1OKIINSV7Qoauth_token=142715285- yi2ch324S3zfyKyJby6WDUZOhCsiQuKNUtc3nAGeoauth_nonce=1275928907blahoauth_timestamp=1275928907oauth_signature_method=HMAC- SHA1oauth_version=1.0oauth_signature=Kf1epCD5j7nW g9dLgtkT5OJXoQQ%3D,status=Hello' -d status=Hello https://twitter.com/statuses/update.json I recieve: * Could not resolve host: OAuth; Host not found * Closing connection #0 curl: (6) Could not resolve host: OAuth; Host not found * Could not resolve host: realm=oauth_consumer_key=yJDLH7BDdVi1O data record of requested type * Closing connection #0 curl: (6) Could not resolve host: realm=oauth_consumer_key=yJDLH * About to connect() to twitter.com port 443 (#0) * Trying 168.143.171.180... connected * Connected to twitter.com (168.143.171.180) port 443 (#0) * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS handshake, Server finished (14): * SSLv3, TLS handshake, Client key exchange (16): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSL connection using AES256-SHA * Server certificate: *subject: 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.6 *start date: 2010-05-11 00:00:00 GMT *expire date: 2012-05-10 23:59:59 GMT *common name: twitter.com (matched) *issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Netwo *SSL certificate verify result: unable to get local issu POST /statuses/update.json HTTP/1.1 User-Agent: curl/7.20.1 (i386-pc-win32) libcurl/7.20.1 OpenSSL Host: twitter.com Accept: */* Content-Length: 12 Content-Type: application/x-www-form-urlencoded HTTP/1.1 401 Unauthorized Date: Mon, 07 Jun 2010 16:57:58 GMT Server: hi Status: 401 Unauthorized WWW-Authenticate: Basic realm=Twitter API X-Runtime: 0.00208 Content-Type: application/json; charset=utf-8 Content-Length: 73 Cache-Control: no-cache, max-age=300 Set-Cookie: k=209.234.229.21.1275929878800654; path=/; expires Set-Cookie: guest_id=127592987880763413; path=/; expires=Wed, Set-Cookie: _twitter_sess=BAh7CDoPY3JlYXRlZF9hdGwrCBjhWBMpAToH Expires: Mon, 07 Jun 2010 17:02:58 GMT Vary: Accept-Encoding Connection: close On Jun 7, 9:14 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Michael, The OAuth authorize step only needs to happen once before you receive access tokens that allow you to act on a member's behalf. Once you've obtained an access token, you can use it to make direct message requests for the user. After completing the authorize and access token steps, store the access token for the user so you can persist it across requests. Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod On Mon, Jun 7, 2010 at 8:10 AM, Michael Cameron darx...@gmail.com wrote: I was reading a twitter app book, and mentioned something about when you
[twitter-dev] Re: Incorrect Signature for oAuth
Thanks to all your replies helped I can now perform status updates via oAuth. I'm rather irritated that Uri.EscapeDataString doesn't escape all illegal characters. It just fails now if a status update contains exclamation marks, asterisk, dollar signs, single quotes and probably a few more. I'll solve that in the morning. Thanks again. Rhys On Jun 8, 1:57 am, StephenBnz stephenbro...@gmail.com wrote: Hi Rhys, - you're right status should be at the end of the base string. Even though it's sent as a POST, it still has to go in alpha order in the base string. - Also be careful of the leading %3F you've got after the update.xml - should just be (method)(baseURL+service)(list of params separated by %26) - Once you've signed with this string, your message will look like: (pseudo code not actual message) POST HTTP 1.1 /statuses/update.xml Host: api.twitter.com:443 Authorization: (list of params as normal, including oauth_signature but NOT including status) Content-type: application/x-www-form-urlencoded Body: status=test Also note that if you have non-alpha characters in the status string (eg. space, etc) you must URL encode them BEFORE compiling the base signature string, and also ensure they remain URL encoded in the POST body. Hope this helps Stephen On Jun 8, 7:36 am,rhysmeistertherhysmeis...@hotmail.com wrote: Hi, thanks to you both. I've removed the source parameter. There is something wrong with my signature base indeed. Here's what I am sending for a status update... POSThttp%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses%2Fupdate.xml%3Fstatus %3Dtest%26oauth_consumer_key%3Dxx%26oauth_nonce %3DE9X6lVKiDkQ1n%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp %3D1275946125%26oauth_token%3Dxx %26oauth_version%3D1.0 As far as I can gather from this linkhttp://dev.twitter.com/pages/auth#auth-request, I need to remove query parameter from the url and order them in the string. So in this case status would appear at the end. I can't find it now, but some poster in a group said to put the status paramter in the url rather than the post body. I think I must have been ordering the signature base incorrectly previous to this. Rhys On Jun 7, 3:09 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: To help you debug, it would be useful to see the signature base string that was generated for the request. Possible things going wrong: the signature base string isn't mentioning that this is a POST, or your OAuth-based parameters are leaking into your POST body.. As Hwee-Boon said, you also needn't include the source parameter, as it will be ignored. Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod On Sun, Jun 6, 2010 at 10:07 AM, Hwee-Boon Yar hweeb...@gmail.com wrote: Since it's GET works and POST, no. 1 reason is to make sure the base URI in the base signature string is constructed correctly. In your example, you don't need source= since it's OAuth. -- Hwee-Boon On Jun 6, 8:56 pm,rhysmeistertherhysmeis...@hotmail.com wrote: Hi All, I am having problems identifying what is wrong with converting my app to use oAuth. All my GET requests work fine but my POST requests all fail with an incorrect signature error. I am adding the oauth parameters to the authorisation header of my request. My authorisation header is build like below for GET requests (this works); OAuth oauth_timestamp=1234567890,oauth_nonce=xx,oauth_version=1.0,oauth _signature_method=HMAC- SHA1,oauth_consumer_key=xx,oauth_token=xx,oauth_signature=xxx xxx My POST requests (these don't work); OAuth oauth_timestamp=1234567890,oauth_nonce=xx,oauth_version=1.0,oauth _signature_method=HMAC- SHA1,oauth_consumer_key=xx,oauth_token=xx,oauth_signature=xxx xxx I get the below error returned... pre ?xml version=1.0 encoding=UTF-8? hash request/1/statuses/update.xml?source=xx/request errorIncorrect signature/error /hash Would anyone be able to provide any pointers here? Cheers, Rhys
[twitter-dev] post 500 error with Xauth
We are forming the URL and posting to api.twitter.com We are getting
HTTP error 500 - Internal server error URl detaisl are given below.
Kindly help us to resolve the issue
Signature Base String
---
POSThttps%3A%2F%2Fapi.twitter.com%2Foauth%2Faccess_token
oauth_consumer_key%3Do10LlaYRx9HZAANF75kg%26
oauth_nonce%3DyePdrFfzkCRTrTPem+fCstEA2JM%26
oauth_signature_method%3DHMAC-SHA1%26
oauth_timestamp%3D1276005168%26
oauth_version%3D1.0%26
x_auth_mode%3Dclient_auth%26
x_auth_password%3D%26
x_auth_username%3Dbrewbird
Header Body
-
Content-Type:application/x-www-form-urlencoded
Authorization: OAuth oauth_nonce=v0ZYuHC6UakS6ACTGfC9+7iDe18,
oauth_signature_method=HMAC-SHA1,
oauth_timestamp=1276005185,
oauth_consumer_key=o10LlaYRx9HZAANF75kg,
oauth_signature=RjRxIqWnZOCe9TjNFiyGkuqMOOo=,
oauth_version=1.0
Resposne from server
---
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http:// www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;; lang=en xml:lang=en
head
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
meta http-equiv=Content-Language content=en-us /
titleTwitter / Error/title
link href=http://s.twimg.com/images/favicon.ico;; rel=shortcut
icon type=image/x-icon /
style type=text/css
/* Page
--- */
* { border: 0; padding: 0; margin: 0; }
body{ margin: 10px 0; background:#C0DEED url(http://s.twimg.com/
images/bg-clouds.png) repeat-x; color:#333; font: 12px Lucida Grande,
Arial, sans-serif; text-align:center }
#container { width: 755px; margin: 0 auto; padding: 0px 0; text-
align: left; position: relative; }
#content { width: 100%; margin-top: 8px; float: left; padding-
bottom: 15px; background: transparent url(http://s.twimg.com/
Re: [twitter-dev] post 500 error with Xauth
Hi Brewbird,
What does your POST body look like in relation to this request? Since the
x_auth_* parameters are not OAuth parameters, you should be sending them in
your POST body (and no other parameters in this area).
Your POST body should look something like (order does not matter in the POST
body, but encoding does):
x_auth_mode=client_authx_auth_password=x_auth_username=brewbird
Taylor Singletary
Developer Advocate, Twitter
http://twitter.com/episod
On Tue, Jun 8, 2010 at 1:51 PM, Brewbird ja...@uievolution.com wrote:
We are forming the URL and posting to api.twitter.com We are getting
HTTP error 500 - Internal server error URl detaisl are given below.
Kindly help us to resolve the issue
Signature Base String
---
POSThttps%3A%2F%2Fapi.twitter.com%2Foauth%2Faccess_token
oauth_consumer_key%3Do10LlaYRx9HZAANF75kg%26
oauth_nonce%3DyePdrFfzkCRTrTPem+fCstEA2JM%26
oauth_signature_method%3DHMAC-SHA1%26
oauth_timestamp%3D1276005168%26
oauth_version%3D1.0%26
x_auth_mode%3Dclient_auth%26
x_auth_password%3D%26
x_auth_username%3Dbrewbird
Header Body
-
Content-Type:application/x-www-form-urlencoded
Authorization: OAuth oauth_nonce=v0ZYuHC6UakS6ACTGfC9+7iDe18,
oauth_signature_method=HMAC-SHA1,
oauth_timestamp=1276005185,
oauth_consumer_key=o10LlaYRx9HZAANF75kg,
oauth_signature=RjRxIqWnZOCe9TjNFiyGkuqMOOo=,
oauth_version=1.0
Resposne from server
---
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http:// www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;; lang=en xml:lang=en
head
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
meta http-equiv=Content-Language content=en-us /
titleTwitter / Error/title
link href=http://s.twimg.com/images/favicon.ico;; rel=shortcut
icon type=image/x-icon /
style type=text/css
/* Page
--- */
* { border: 0; padding: 0; margin: 0; }
body{ margin: 10px 0; background:#C0DEED url(http://s.twimg.com/
images/bg-clouds.png) repeat-x; color:#333; font: 12px Lucida Grande,
Arial, sans-serif; text-align:center }
#container { width: 755px; margin: 0 auto; padding: 0px 0; text-
align: left; position: relative; }
#content { width: 100%; margin-top: 8px; float: left; padding-
bottom: 15px; background: transparent url(http://s.twimg.com/
[twitter-dev] Search API lang temporary error
I'm seeing a temporary error adjusting the since_id on every search query if I specify lang=en and it wipes out many valid results. I can tell my backend script to filter out the other languages, but I'm seeing as many as half a page of results be foreign posts, so that's a lot of wasted bandwidth and processing to work around this bug. Is this issue going to be fixed soon, or should I just implement the workaround as a permanent solution and forget about using the lang parameter? One interesting item to note - if using the lang parameter the next_page URL is also bugged. Example: Initial query: search.twitter.com/search.json? lang=enpage=1q=testresult_type=recentrpp=20 next_page:?page=2max_id=15735108387rpp=20〈=enq=test Note the odd unicode bracket thing where it should say lang=en instead.
[twitter-dev] Lists Social Graph
Getting user ids of all the members of a list is crucial for a feature of my Twitter app, and paging through 20 ids at a time from each list isn't feasible. (Most of the data would be extraneous, I just want the ids.) I see a suggestion was made back in Nov 09 to implement a function like the social graph, which just gives ids - what is the status on this feature? Will we be seeing it in the near future?
[twitter-dev] First Tweet at Hashtag
Hello, I wanted to know if there is any way of knowing who was the firstI use a hashtag? I need an analysis I'm doing twitter please can you send me this information?
[twitter-dev] link wrapping on the API
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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 out
http://dev.twitter.com!;
a returned (and truncated) status object may look like:
{
text : you have to check out http://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 the
http://t.co/s9gfk2d4 in the text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
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 timescale of weeks (to potentially a month or two), we'll roll
this out to everybody.
of course, if there are any questions, just feel free to direct them to
@twitterapi!
--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi
Re: [twitter-dev] First Tweet at Hashtag
Quoting jretamal jreta...@gmail.com: Hello, I wanted to know if there is any way of knowing who was the firstI use a hashtag? I need an analysis I'm doing twitter please can you send me this information? Depending on how long ago the hashtag was created, you might be able to determine this with a Twitter search. But the easiest way is probably to go to http://twapperkeeper.com and create an archive. If there's already an archive for the hashtag, you're done, assuming the archive was created before the first tweet disappeared from Twitter's cache. Otherwise, create a new one and wait for the Twapperkeeper historical search to search back in time.
[twitter-dev] EEC Group - analysis experts
Hello everyone here! My name is Mike Stachowiak and I work with Twitter API since June 2009. We did analytical platform for LEWIS PR using our own methodology, algorithms. I look forward for any business proposal and comment. Thanks, Mike
[twitter-dev] Re: Lists Social Graph
I thnk you have to go through paging and this is only way you can handle - we do it like this M On Jun 8, 11:43 pm, Unfair imunf...@yahoo.com wrote: Getting user ids of all the members of a list is crucial for a feature of my Twitter app, and paging through 20 ids at a time from each list isn't feasible. (Most of the data would be extraneous, I just want the ids.) I see a suggestion was made back in Nov 09 to implement a function like the social graph, which just gives ids - what is the status on this feature? Will we be seeing it in the near future?
[twitter-dev] Re: link wrapping on the API
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 ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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/s9gfk2d4in the text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
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 timescale of weeks (to potentially a month or two), we'll roll
this out to everybody.
of course, if
[twitter-dev] Re: [twitter-api-announce] link wrapping on the API
Hi Raffi,
Interesting... A couple of quick questions:
*1)* Will the redirect from t.co - domain.com be a 301 Moved Permanently or
a 302 Found response?
*2)* Will the t.co URL redirect point to the URL in the original tweet, or
will it point to the ultimate resolved URL?
I.e., if I post Check out my site at http://bit.ly/abcd; where
bit.ly/abcdredirects to
domain.com, and the resultant tweet becomes Check out my site at
http://t.co/abcd;, will the t.co URL redirect like this:
a) t.co/abcd - domain.com
Or like this:
b) t.co/abcd - bit.ly/abcd - domain.com
*3)* In the above scenario, will the 'display_url' contain '
http://bit.ly/abcd' or 'http://domain.com'?
*4)* Why redirect all URLs, btw? Why not just redirect the malicious ones?
Thanks!
-DeWitt
On Tue, Jun 8, 2010 at 3:57 PM, Raffi Krikorian ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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 out
http://dev.twitter.com!;
a returned (and truncated) status object may look like:
{
text : you have to check out http://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 the
http://t.co/s9gfk2d4 in the text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
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
[twitter-dev] Re: link wrapping on the API
How will this affect links for third party services that clients
handle natively, such as Twitpic (and obviously TwitLonger, which
already has shorter dedicated short urls for its posts)?
I'll also be interested to see how this goes down with the privacy
types who will now be paranoid that Twitter is tracking the sites
they're going to, even if they are going through a third party client.
If I'm clicking a link on a desktop client, should Twitter really be
getting that information?
What about links through bit.ly etc? Will I still be able to see the
analytics that they provide for my links? If so, does that mean there
will be at least two levels of redirection from the ultimate
destination?
On Jun 8, 11:57 pm, Raffi Krikorian ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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/s9gfk2d4in the text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
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
[twitter-dev] Re: [twitter-api-announce] link wrapping on the API
Hi Raffi, On 9/06/10 8:57 AM, Raffi Krikorian wrote: url : http://t.co/s9gfk2d4;, display_url : http://dev.twitter.com;, indices : [23, 43] Any chance of getting the title of the resolved URL added in here too if available? Then we could display a link like : a title=Twitter Dev href=http://t.co/s9gfk2d4; http://dev.twitter.com /a or : a title=http://dev.twitter.com; href=http://t.co/s9gfk2d4; Twitter Dev /a This would give even more context to users, without having to follow the redirect path, load and parse the page to extract it as well. Thanks, JB.
[twitter-dev] Re: link wrapping on the API
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 dpr...@gmail.com 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 ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
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
Re: [twitter-dev] Re: [twitter-api-announce] link wrapping on the API
*1)* Will the redirect from t.co - domain.com be a 301 Moved Permanently
or a 302 Found response?
301!
*2)* Will the t.co URL redirect point to the URL in the original tweet, or
will it point to the ultimate resolved URL?
I.e., if I post Check out my site at http://bit.ly/abcd; where
bit.ly/abcd redirects to domain.com, and the resultant tweet becomes
Check out my site at http://t.co/abcd;, will the t.co URL redirect like
this:
a) t.co/abcd - domain.com
Or like this:
b) t.co/abcd - bit.ly/abcd - domain.com
we're not modifying or tampering with URLs - if you send us a bit.ly link,
we will wrap that bit.ly link. analytics will still work, etc.
*3)* In the above scenario, will the 'display_url' contain '
http://bit.ly/abcd' or 'http://domain.com'?
bit.ly!
*4)* Why redirect all URLs, btw? Why not just redirect the malicious
ones?
in the case of malicious URLs, you sometimes don't know it at the time of
tweet creation. or the URL may eventually become malicious. this allows us
to do shutdown after tweet creation.
Thanks!
that's what i'm here for :P
-DeWitt
On Tue, Jun 8, 2010 at 3:57 PM, Raffi Krikorian ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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 out
http://dev.twitter.com!;
a returned (and truncated) status object may look like:
{
text : you have to check out http://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 the http://t.co/s9gfk2d4 in the text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
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.
Re: [twitter-dev] Re: link wrapping on the API
How will this affect links for third party services that clients
handle natively, such as Twitpic (and obviously TwitLonger, which
already has shorter dedicated short urls for its posts)?
that's why we are providing all the data back out in the API. while the
tweet itself may have t.co, we do include, in the entities, the original
URL. our hope, honestly, is that final users never have to see t.co -- we
want to provide enough data back to developers so they can create URLs that
look like
a href=http://t.co/blahblah;http://mycoolsite.com/a
all those URLs should still show through.
What about links through bit.ly etc? Will I still be able to see the
analytics that they provide for my links? If so, does that mean there
will be at least two levels of redirection from the ultimate
destination?
yes - we won't be touching the original URL. all analytics that users want
to see on bit.ly will still be there. this is what we do on URLs in DMs
right now.
On Jun 8, 11:57 pm, Raffi Krikorian ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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/s9gfk2d4in the text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
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
Re: [twitter-dev] Re: [twitter-api-announce] link wrapping on the API
that would be an awesome service! On Tue, Jun 8, 2010 at 4:50 PM, John Barratt djo...@gmail.com wrote: Hi Raffi, On 9/06/10 8:57 AM, Raffi Krikorian wrote: url : http://t.co/s9gfk2d4;, display_url : http://dev.twitter.com;, indices : [23, 43] Any chance of getting the title of the resolved URL added in here too if available? Then we could display a link like : a title=Twitter Dev href=http://t.co/s9gfk2d4; http://dev.twitter.com /a or : a title=http://dev.twitter.com; href=http://t.co/s9gfk2d4; Twitter Dev /a This would give even more context to users, without having to follow the redirect path, load and parse the page to extract it as well. Thanks, JB. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: link wrapping on the API
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 dpr...@gmail.com 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 dpr...@gmail.com 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 ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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 : {
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
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
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
[twitter-dev] Re: link wrapping on the API
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 ra...@twitter.com 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 dpr...@gmail.com 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 dpr...@gmail.com 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 ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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 : {
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/s9gfk2d4inthetext with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
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
Re: [twitter-dev] Re: link wrapping on the API
Will we be able to get matches on the original URL through the streaming
API?
For example, I'm tracking act so I can match tweets that link to '
http://act.ly'. Will I still be able to do that?
Jim Gilliam
http://act.ly/
http://twitter.com/jgilliam
On Tue, Jun 8, 2010 at 4:33 PM, Dewald Pretorius dpr...@gmail.com 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 ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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/s9gfk2d4in the text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
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
[twitter-dev] Favorites/:id/create.json returns not found
Hi all,
I am having trouble with setting favorites through the oAuth API
(with xAuth). Must other api's work (exception being blocks/exists, see
previous emails).
Here is an example request:
location: https://api.twitter.com/1/favorites/15738870223/create.json
authorizationHeader: OAuth oauth_consumer_key=snip,
oauth_nonce=snip, oauth_signature=snip,
oauth_signature_method=HMAC-SHA1, oauth_timestamp=1276041800,
oauth_token=snip, oauth_version=1.0,
postData: id=15738870223
responseData:
{request:/1/favorites/15738870223/create.json,error:Not found}
Now on the web, this is fine:
http://twitter.com/twitterapi/status/15738870223
I tried removing the id as post data, but then I got an invalid
signature error. Any ideas?
Thanks,
Jim Cortez
Re: [twitter-dev] Re: [twitter-api-announce] link wrapping on the API
Awesome, thanks for the quick response!
Those are the right answers, too. : )
Though there's an inconsistency with returning 301's and also requiring
every click to go through the t.co link (as required by the ToS). A 301
means that the redirect is cacheable by any intermediary (because it is
permanent and will never change).
The 301 also implies that you actually *can* replace only the malicious
links, (not every link), because clients will already have resolved and
cached the 301 redirects (which again, can never change), so you won't be
able to change the redirect down the road anyway.
So, I think you might actually have meant to use 302's, not 301's, if
redirecting every click is the goal.
But then again, 301's really are the (philosophically? morally?) right
answer, so maybe I *don't* want you to fix that. : )
Or better still, resolving *all* URLs upfront and returning the full URL
inline, making tweets longer than 140 characters, and stopping this whole
URL shortening nonsense to begin with. (But you knew I'd say that...!)
-DeWitt
On Tue, Jun 8, 2010 at 4:54 PM, Raffi Krikorian ra...@twitter.com wrote:
*1)* Will the redirect from t.co - domain.com be a 301 Moved Permanently
or a 302 Found response?
301!
*2)* Will the t.co URL redirect point to the URL in the original tweet,
or will it point to the ultimate resolved URL?
I.e., if I post Check out my site at http://bit.ly/abcd; where
bit.ly/abcd redirects to domain.com, and the resultant tweet becomes
Check out my site at http://t.co/abcd;, will the t.co URL redirect like
this:
a) t.co/abcd - domain.com
Or like this:
b) t.co/abcd - bit.ly/abcd - domain.com
we're not modifying or tampering with URLs - if you send us a bit.ly link,
we will wrap that bit.ly link. analytics will still work, etc.
*3)* In the above scenario, will the 'display_url' contain '
http://bit.ly/abcd' or 'http://domain.com'?
bit.ly!
*4)* Why redirect all URLs, btw? Why not just redirect the malicious
ones?
in the case of malicious URLs, you sometimes don't know it at the time of
tweet creation. or the URL may eventually become malicious. this allows us
to do shutdown after tweet creation.
Thanks!
that's what i'm here for :P
-DeWitt
On Tue, Jun 8, 2010 at 3:57 PM, Raffi Krikorian ra...@twitter.comwrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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 out
http://dev.twitter.com!;
a returned (and truncated) status object may look like:
{
text : you have to check out http://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
Re: [twitter-dev] Favorites/:id/create.json returns not found
Hi Jim,
Change the URL to
https://api.twitter.com/1/favorites/create/15738870223.json and it should
work.
On Tue, Jun 8, 2010 at 5:04 PM, Jim Cortez j...@jimcortez.com wrote:
Hi all,
I am having trouble with setting favorites through the oAuth API (with
xAuth). Must other api's work (exception being blocks/exists, see previous
emails).
Here is an example request:
location: https://api.twitter.com/1/favorites/15738870223/create.json
authorizationHeader: OAuth oauth_consumer_key=snip,
oauth_nonce=snip, oauth_signature=snip,
oauth_signature_method=HMAC-SHA1, oauth_timestamp=1276041800,
oauth_token=snip, oauth_version=1.0,
postData: id=15738870223
responseData:
{request:/1/favorites/15738870223/create.json,error:Not found}
Now on the web, this is fine:
http://twitter.com/twitterapi/status/15738870223
I tried removing the id as post data, but then I got an invalid signature
error. Any ideas?
Thanks,
Jim Cortez
--
Dana Contreras
Twitter Platform Team
http://twitter.com/DanaDanger
[twitter-dev] Re: [twitter-api-announce] link wrapping on the API
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.
Re: [twitter-dev] Re: [twitter-api-announce] link wrapping on the API
Hi Raffi, On 9/06/10 9:57 AM, Raffi Krikorian wrote: that would be an awesome service! Currently we use one our own services (http://metauri.com/) to do this for http://trendsmap.com/. In addition to the title, it also gives the content type, which can be useful in determining how, or if to use the link in your display. I was just wondering if Twitter were going to possibly supply this extra data, as it would remove a time resource intensive step in the tweet analysis process :). Another question, will you wrap links that have no protocol in tweets, eg : Hey check out www.mysite.com/evil_page and : Hey check out mysite.com/evil_page I imagine many clients will currently link these out as urls and link them up automatically? Thanks again, JB. On Tue, Jun 8, 2010 at 4:50 PM, John Barratt djo...@gmail.com mailto:djo...@gmail.com wrote: Hi Raffi, On 9/06/10 8:57 AM, Raffi Krikorian wrote: url : http://t.co/s9gfk2d4;, display_url : http://dev.twitter.com;, indices : [23, 43] Any chance of getting the title of the resolved URL added in here too if available? Then we could display a link like : a title=Twitter Dev href=http://t.co/s9gfk2d4; http://dev.twitter.com /a or : a title=http://dev.twitter.com; href=http://t.co/s9gfk2d4; Twitter Dev /a This would give even more context to users, without having to follow the redirect path, load and parse the page to extract it as well. Thanks, JB. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
RE: [twitter-dev] Re: link wrapping on the API
If you do this, you will literally be forcing app developers to waste users time and money, especially over metered GRPS/3G connections. If the user can see the full URL, then why do they need to be protected any more than they are when they use any other service? If anything, you should be cutting through any and all redirects (shorteners) so that the application can show the final URL to the user and avoid multiple useless, latency-inducing redirects that reduce reliability and increase costs for end-users and network operators. Cutting through all the redirects would improve security AND improve on the users' privacy, instead of hurting it. And, what about the user's right to privacy? You're basically forcing every Twitter app to become spyware. Who wants to create spyware? No developers with a conscience-and I'm sure that includes you 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, 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 the http://t.co/s9gfk2d4in the text with the equivalent of a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a 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.
[twitter-dev] Re: link wrapping on the API
+1 on this, I'd like to know the answer as well.
Damon/@dacort
On Jun 8, 4:43 pm, Jim Gilliam j...@gilliam.com wrote:
Will we be able to get matches on the original URL through the streaming
API?
For example, I'm tracking act so I can match tweets that link to
'http://act.ly'. Will I still be able to do that?
Jim Gilliamhttp://act.ly/http://twitter.com/jgilliam
On Tue, Jun 8, 2010 at 4:33 PM, Dewald Pretorius dpr...@gmail.com 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 ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
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,
[twitter-dev] Re: link wrapping on the API
I don't see how this feature could impact user privacy more than what it is right now. Today Twitter stores all links for all users and they can spy on them and the t.co shortner is not changing that :) My question is, will developers have access to analytics from t.co through API? Thanks
[twitter-dev] Re: link wrapping on the API
What's the algorithm for the display url? Ideally it will be a
predictable length, to aid predictability in tweet display code.
If the motive is really to protect us from malicious URLs, what about
giving a service we can call to route links through your protective
redirect servers? Then we can give users the option to be protected by
your malicious detection algorithms if they want.
If you want to click track every URL for whatever reason, ask client
developers to hit a ping URL if the user clicks? I'm not sure
otherwise how you will tell in a software client if it's the user
requesting the t.co URL or the software.
On Jun 9, 6:57 am, Raffi Krikorian ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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/s9gfk2d4in the text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
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
RE: [twitter-dev] Re: link wrapping on the API
Sami wrote: I don't see how this feature could impact user privacy more than what it is right now. Today Twitter stores all links for all users and they can spy on them and the t.co shortner is not changing that :) Right now, Twitter can see all the links that users *post*, but they don't see which links users *click*. In order to implement this feature, Twitter has already built the framework that does all the hard work that applications need to protect users' privacy against (link-shortener) click-tracking. Twitter will be withholding that final URL from applications, preventing us (through the ToS) from implementing our own anti-click-tracking privacy measures. If, instead, they gave the final URL to the application and let the application use that URL, then applications could implement anti-click-tracking privacy measures with an even greater degree of privacy than they could by using a third-party service. In other words, instead of Twitter using their existing link-unshortening technology to let applications tell *fewer* companies what links your users are clicking on, they are using it to force applications to tell *more* companies what your 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_
Re: [twitter-dev] Re: link wrapping on the API
our hope is to eventually provide this analytics. On Tue, Jun 8, 2010 at 7:14 PM, Sami sami.ben.romdh...@gmail.com wrote: I don't see how this feature could impact user privacy more than what it is right now. Today Twitter stores all links for all users and they can spy on them and the t.co shortner is not changing that :) My question is, will developers have access to analytics from t.co through API? Thanks -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: link wrapping on the API
Raffi wrote: 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. I guess this change will make frontend text handling more difficult. Counting characters in a text box must figure out what is a URL. I hope Twitter will publish JavaScript library for realtime character counts. I also want APIs to make shortened URL. Andy Matsubara
Re: [twitter-dev] Re: link wrapping on the API
What's the algorithm for the display url? Ideally it will be a
predictable length, to aid predictability in tweet display code.
i'm not sure why the display_url would be of predictable length? the
display_url is -exactly- the URL that the user has sent into the system.
so, that may be of varying length.
If the motive is really to protect us from malicious URLs, what about
giving a service we can call to route links through your protective
redirect servers? Then we can give users the option to be protected by
your malicious detection algorithms if they want.
If you want to click track every URL for whatever reason, ask client
developers to hit a ping URL if the user clicks? I'm not sure
otherwise how you will tell in a software client if it's the user
requesting the t.co URL or the software.
i guess i'm confused on this as well? isn't that what t.co does?
On Jun 9, 6:57 am, Raffi Krikorian ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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/s9gfk2d4in the text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
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
Re: [twitter-dev] Re: link wrapping on the API
Right now, Twitter can see all the links that users *post*, but they don't see which links users *click*. In order to implement this feature, Twitter has already built the framework that does all the hard work that applications need to protect users' privacy against (link-shortener) click-tracking. Twitter will be withholding that final URL from applications, preventing us (through the ToS) from implementing our own anti-click-tracking privacy measures. If, instead, they gave the final URL to the application and let the application use that URL, then applications could implement anti-click-tracking privacy measures with an even greater degree of privacy than they could by using a third-party service. hey brian - just wanted to point out - the Twitter will be withholding that final URL from applications is NOT true at all. we are providing, as part of the entities the original URL back to the developers. stated another way - we are giving all the data back and we are not withholding the data. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: link wrapping on the API
yeah - its definitely case that counting characters will become a bit more subtle. i hope that we can provide a really good and easy way to help you all out. at the very least we are going to update documentation, but i know we can do better than that. On Tue, Jun 8, 2010 at 8:17 PM, Andy Matsubara andymatsub...@gmail.comwrote: Raffi wrote: 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. I guess this change will make frontend text handling more difficult. Counting characters in a text box must figure out what is a URL. I hope Twitter will publish JavaScript library for realtime character counts. I also want APIs to make shortened URL. Andy Matsubara -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
RE: [twitter-dev] Re: link wrapping on the API
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 3048 might be wrapped as http://t.co/DRo0trj for display on SMS, but it could be displayed to web or application users as amazon.com/Delivering-. Will the application be doing the truncation from the full URL to the truncated one (amazon.com/Delivering-), or will the API? And, if the application really will get the full destination URL, then it is even more ridiculous to prevent them (through the ToS) from using it to improve the user's privacy, don't you think? Regards, Brian Right now, Twitter can see all the links that users *post*, but they don't see which links users *click*. In order to implement this feature, Twitter has already built the framework that does all the hard work that applications need to protect users' privacy against (link-shortener) click-tracking. Twitter will be withholding that final URL from applications, preventing us (through the ToS) from implementing our own anti-click-tracking privacy measures. If, instead, they gave the final URL to the application and let the application use that URL, then applications could implement anti-click-tracking privacy measures with an even greater degree of privacy than they could by using a third-party service. hey brian - just wanted to point out - the Twitter will be withholding that final URL from applications is NOT true at all. we are providing, as part of the entities the original URL back to the developers. stated another way - we are giving all the data back and we are not withholding the data. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] Re: link wrapping on the API
Are all links going to be wrapped or only long links? If it's the
latter, what's the definition?
1. This affects how we count characters before sending and has quite a
potential to go wrong, since we'll now need to know exactly which
links are going to be wrapped in a tweet.
2. It's also going to be tricky for apps that currently show a live
character count (like SimplyTweet and many other iPhone Twitter apps
and possibly web sites) as users type.
--
Hwee-Boon
On Jun 9, 6:57 am, Raffi Krikorian ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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/s9gfk2d4in the text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
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 timescale of weeks (to potentially a month or two), we'll roll
this out to everybody.
of course, if there
[twitter-dev] Re: link wrapping on the API
OK, it's a little confusing naming for display URL, as that implies
that is what clients should show directly to the users, as most of the
time I would imagine that field should be cut for brevity.
The difference between having a ping service that can help twitter
track clicks and a redirect service that can help twitter protect
users, and having twitter simply force-edit everyone's tweet texts, is
that instead of providing a new service that developers and users can
opt to use, you are providing a service that everyone _must_ use or
add code to work around.
You could have simply provided an extension to posting new tweets that
identified the real urls of shortened urls, that would have protected
short url providers who invested in your platform and allowed
developers to add the improvement on their own time frames.
I like the general idea of embedding real links in the twitter
metadata even if it adds to an already bloated tweet data payload, but
Twitter isn't respecting its ecosystem here by forcing complexity on
all developers and giving a time frame of weeks to change established
code developed over years.
On Jun 9, 11:18 am, Raffi Krikorian ra...@twitter.com wrote:
What's the algorithm for the display url? Ideally it will be a
predictable length, to aid predictability in tweet display code.
i'm not sure why the display_url would be of predictable length? the
display_url is -exactly- the URL that the user has sent into the system.
so, that may be of varying length.
If the motive is really to protect us from malicious URLs, what about
giving a service we can call to route links through your protective
redirect servers? Then we can give users the option to be protected by
your malicious detection algorithms if they want.
If you want to click track every URL for whatever reason, ask client
developers to hit a ping URL if the user clicks? I'm not sure
otherwise how you will tell in a software client if it's the user
requesting the t.co URL or the software.
i guess i'm confused on this as well? isn't that what t.co does?
On Jun 9, 6:57 am, Raffi Krikorian ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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
Re: [twitter-dev] Re: link wrapping on the API
All links will be wrapped. It's not about length.
On Tue, Jun 8, 2010 at 9:06 PM, Alex B alex.boswo...@gmail.com wrote:
OK, it's a little confusing naming for display URL, as that implies
that is what clients should show directly to the users, as most of the
time I would imagine that field should be cut for brevity.
The difference between having a ping service that can help twitter
track clicks and a redirect service that can help twitter protect
users, and having twitter simply force-edit everyone's tweet texts, is
that instead of providing a new service that developers and users can
opt to use, you are providing a service that everyone _must_ use or
add code to work around.
You could have simply provided an extension to posting new tweets that
identified the real urls of shortened urls, that would have protected
short url providers who invested in your platform and allowed
developers to add the improvement on their own time frames.
I like the general idea of embedding real links in the twitter
metadata even if it adds to an already bloated tweet data payload, but
Twitter isn't respecting its ecosystem here by forcing complexity on
all developers and giving a time frame of weeks to change established
code developed over years.
On Jun 9, 11:18 am, Raffi Krikorian ra...@twitter.com wrote:
What's the algorithm for the display url? Ideally it will be a
predictable length, to aid predictability in tweet display code.
i'm not sure why the display_url would be of predictable length? the
display_url is -exactly- the URL that the user has sent into the system.
so, that may be of varying length.
If the motive is really to protect us from malicious URLs, what about
giving a service we can call to route links through your protective
redirect servers? Then we can give users the option to be protected by
your malicious detection algorithms if they want.
If you want to click track every URL for whatever reason, ask client
developers to hit a ping URL if the user clicks? I'm not sure
otherwise how you will tell in a software client if it's the user
requesting the t.co URL or the software.
i guess i'm confused on this as well? isn't that what t.co does?
On Jun 9, 6:57 am, Raffi Krikorian ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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
Re: [twitter-dev] Re: link wrapping on the API
Existing url shortners will continue to work just fine. We're not
going to resolve them to their final link and remove them from the
chain.
By redirecting all links, we can protect all users and the entire
ecosystem much faster. The adoption via opt-in would be slower, and
might never reach critical mass.
Apps that don't update will continue to work, they will just display
something different than they do now.
On Tue, Jun 8, 2010 at 9:06 PM, Alex B alex.boswo...@gmail.com wrote:
OK, it's a little confusing naming for display URL, as that implies
that is what clients should show directly to the users, as most of the
time I would imagine that field should be cut for brevity.
The difference between having a ping service that can help twitter
track clicks and a redirect service that can help twitter protect
users, and having twitter simply force-edit everyone's tweet texts, is
that instead of providing a new service that developers and users can
opt to use, you are providing a service that everyone _must_ use or
add code to work around.
You could have simply provided an extension to posting new tweets that
identified the real urls of shortened urls, that would have protected
short url providers who invested in your platform and allowed
developers to add the improvement on their own time frames.
I like the general idea of embedding real links in the twitter
metadata even if it adds to an already bloated tweet data payload, but
Twitter isn't respecting its ecosystem here by forcing complexity on
all developers and giving a time frame of weeks to change established
code developed over years.
On Jun 9, 11:18 am, Raffi Krikorian ra...@twitter.com wrote:
What's the algorithm for the display url? Ideally it will be a
predictable length, to aid predictability in tweet display code.
i'm not sure why the display_url would be of predictable length? the
display_url is -exactly- the URL that the user has sent into the system.
so, that may be of varying length.
If the motive is really to protect us from malicious URLs, what about
giving a service we can call to route links through your protective
redirect servers? Then we can give users the option to be protected by
your malicious detection algorithms if they want.
If you want to click track every URL for whatever reason, ask client
developers to hit a ping URL if the user clicks? I'm not sure
otherwise how you will tell in a software client if it's the user
requesting the t.co URL or the software.
i guess i'm confused on this as well? isn't that what t.co does?
On Jun 9, 6:57 am, Raffi Krikorian ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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 : {
[twitter-dev] Re: link wrapping on the API
But if apps don't update and user sends a tweet which is just below 140 characters say, 139, and which contain a link(s) shorter than 19 (or is it 20) characters will mysteriously fail. The user will wonder why the app doesn't let them send the tweet when their app clearly says it's still within 140 characters, because Twitter is now counting the longer 19/20 character t.co link. Is this considered a rare scenario? -- Hwee-Boon On Jun 9, 12:18 pm, John Kalucki j...@twitter.com wrote: Apps that don't update will continue to work, they will just display something different than they do now.
Re: [twitter-dev] Re: link wrapping on the API
On Tue, 8 Jun 2010 22:19:04 -0700 (PDT) Hwee-Boon Yar hweeb...@gmail.com wrote: But if apps don't update and user sends a tweet which is just below 140 characters say, 139, and which contain a link(s) shorter than 19 (or is it 20) characters will mysteriously fail. The user will wonder why the app doesn't let them send the tweet when their app clearly says it's still within 140 characters, because Twitter is now counting the longer 19/20 character t.co link. Is this considered a rare scenario? The right way to do this for twitter would be to count the characters submitted to the API, before twitter changes the content. That way, the API acceptance of a well formed post is predictable. Otherwise it's not, since an application really doesn't know what twitter will do with the content. -- Hwee-Boon On Jun 9, 12:18 pm, John Kalucki j...@twitter.com wrote: Apps that don't update will continue to work, they will just display something different than they do now. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] link wrapping on the API
- Privacy of click history. Your changes are such a big compromise of
privacy that I might stop using Twitter altogether and not just stop making
applications for it. (To get a feel of how seriously I take privacy of
click-history, see an old blog
posthttp://blog.tdash.org/our-new-feature-click-historyof mine).
- By changing the TOS your are acting like FaceBook. In fact, it is even
worse, because you are not just changing the default settings, you are
saying that this is the only way to go.
- The concept of a URL *shortener* that *expands* links that are too *
short* is so wrong I can't begin to describe it. It complicates the
application logic at best, and leaves the user utterly bewildered at worst.
On Wed, Jun 9, 2010 at 4:27 AM, Raffi Krikorian ra...@twitter.com wrote:
hi all.
twitter has been wrapping links in e-mailed DMs for a couple months
nowhttp://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 out
http://dev.twitter.com!;
a returned (and truncated) status object may look like:
{
text : you have to check out http://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 the
http://t.co/s9gfk2d4 in the text with the equivalent of
a href=http://t.co/s9gfk2d4;http://dev.twitter.com/a
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
