--
Twitter API documentation and resources: http://apiwiki.twitter.com
API updates via Twitter: http://twitter.com/twitterapi
Change your membership to this group: http://groups.google.com/group/twitter-api-announce?hl=en
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.
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/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.comOr like this:
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!
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)?
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 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.
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_____
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_____
Andy Matsubara
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.
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.
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/0446563048 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