[twitter-dev] t.co?
When exactly do links get wrapped in t.co URLs? In the stream of people I follow, I've noticed more links getting wrapped this way recently, but it's not every single link. Will there be a time when every single link is wrapped with t.co? -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
Re: [twitter-dev] t.co?
Anyone answering 'no' to this question is a fool: Twitter wants full control, t.co is a necessary part of it. Also, all official Twitter clients wrap t.co URLs, and afaik that's it. Of course, Tweet Button and web intents go in this category as well. Tom On 6/5/11 6:27 PM, SM wrote: When exactly do links get wrapped in t.co URLs? In the stream of people I follow, I've noticed more links getting wrapped this way recently, but it's not every single link. Will there be a time when every single link is wrapped with t.co? -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
[twitter-dev] t.co user agent string
Hi, I've been trying to find out what the user agent string is for the t.co bot that pings urls posted to Twitter. I've had a look through the logs of some newly posted links but I can't pick out which one is Twitter's bot. There were a couple of mentions of Gnip, Google, Voyager etc... Thanks, Ben -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] t.co Posting Questions
On Dec 18, 2010, at 5:17 PM, David E. Wheeler wrote: Currently the API does not shorten the links for you yet. In the future Twitter may implement this, but currently you will have to shorten the links yourself, via (for example) bit.ly. That's what I thought. Thanks for the confirmation. It appears that Twitter 2 for the Mac somehow does what I was describing. Try typing or pasting a URL into it; it stops counting characters once it recognizes it as a URL. You can also send tweets that are over 140 characters due to a long URL; it does the shortening using t.co. How does it do it? Is there an API for that? I'm doing the same thing in my app, but using s.coop. would be nice just to be able to send stuff to the API an let it do the shortening. I don't suppose that's how it works… Any ideas? Best, David -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] t.co Posting Questions
I would not recommend using it yet but Twitter for Mac is using the endpoint /urls/shorten.json?url=http://example.com http://t.co/6wD3idD Abraham - Abraham Williams | Hacker Advocate | abrah.am @abraham https://twitter.com/abraham | github.com/abraham | blog.abrah.am This email is: [ ] shareable [x] ask first [ ] private. On Wed, Jan 12, 2011 at 10:58, David E. Wheeler da...@kineticode.comwrote: On Dec 18, 2010, at 5:17 PM, David E. Wheeler wrote: Currently the API does not shorten the links for you yet. In the future Twitter may implement this, but currently you will have to shorten the links yourself, via (for example) bit.ly. That's what I thought. Thanks for the confirmation. It appears that Twitter 2 for the Mac somehow does what I was describing. Try typing or pasting a URL into it; it stops counting characters once it recognizes it as a URL. You can also send tweets that are over 140 characters due to a long URL; it does the shortening using t.co. How does it do it? Is there an API for that? I'm doing the same thing in my app, but using s.coop. would be nice just to be able to send stuff to the API an let it do the shortening. I don't suppose that's how it works… Any ideas? Best, David -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] t.co Posting Questions
On Jan 12, 2011, at 11:41 AM, Abraham Williams wrote: I would not recommend using it yet but Twitter for Mac is using the endpoint /urls/shorten.json?url=http://example.com http://t.co/6wD3idD Ah, that's pretty nice. Pity the API doesn't do it magically for you, but this will be a good compromise. I wonder if there is or will be a parameter that causes the short link to simply be returned as the content, like many of the shortening services offer (not goo.gl, alas). It's nice not to have to parse anything if all you need is a link. I look forward to seeing this documented/announced at some point…thank for the pointer, Abraham. Best, David -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] t.co reverse
Hi guys ! Thanks to new Mac OS Twitter client a lot of URL in tweets are now convert to t.co witch is include in API response for user/ timeline ... Is there any way to reverse t.co simply like we can do with bit.ly API ? Thanks @Amaury -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] t.co reverse
Hi Amaury,
There currently isn't a distinct API available to de-reference t.co URLs (or
directly produce them). However, most REST API timeline and status-bearing
methods support the include_entities=true parameter which will include an
additional set of fields, including unrolled t.co URLs. You can read more
about entities here: http://dev.twitter.com/pages/tweet_entities
For example with this request:
GET
http://api.twitter.com/1/statuses/show.json?id=23150950055153664include_entities=true
The tweet text was:
text: Emergent Behavior in Twitter Culture http://t.co/bcUPYxi via
@adage,
And the entities node shows the de-referenced URL in
entities/urls[0]/expanded_url:
entities: {
places: [],
urls: [
{
expanded_url: http://adage.com/u/rby1pa;,
url: http://t.co/bcUPYxi;,
indices: [
37,
56
],
display_url: adage.com/u/rby1pa
}
],
hashtags: [],
user_mentions: [
{
name: Ad Age,
id_str: 12480582,
id: 12480582,
indices: [
61,
67
],
screen_name: adage
}
]
}
Thanks,
Taylor
On Fri, Jan 7, 2011 at 6:59 AM, Amaury amaury.lespling...@gmail.com wrote:
Hi guys !
Thanks to new Mac OS Twitter client a lot of URL in tweets are now
convert to t.co witch is include in API response for user/
timeline ...
Is there any way to reverse t.co simply like we can do with bit.ly
API ?
Thanks
@Amaury
--
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker:
http://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
http://groups.google.com/group/twitter-development-talk
--
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] t.co Posting Questions
On Dec 18, 2010, at 5:01 AM, Tom van der Woerdt wrote: Currently the API does not shorten the links for you yet. In the future Twitter may implement this, but currently you will have to shorten the links yourself, via (for example) bit.ly. That's what I thought. Thanks for the confirmation. Best, David -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] t.co Posting Questions
As for bit.ly, there is an API for bit.ly which aids you in using URL-shortening until t.co is finished.. -- Emil sakjur Tullstedt ~~ On Sat, Dec 18, 2010 at 2:01 PM, Tom van der Woerdt i...@tvdw.eu wrote: Hello David, Currently the API does not shorten the links for you yet. In the future Twitter may implement this, but currently you will have to shorten the links yourself, via (for example) bit.ly. Tom On 12/18/10 1:19 AM, David E. Wheeler wrote: Howdy, I'm writing an iPad app that has a Share via Twitter feature. I'm trying to understand how to count characters, including URLs before I post to the API. I thought these might be FAQs, but t.co does not show up in the FAQ and has only two hits via Google's search of this list, so I apologize if these are in fact FAQs. So I tried to post a new status message that was longer than 140 characters, but I counted the URL as only 19 characters, per [this message][] from Raffi. Unfortunately, the API rejected the message as too long. So my questions are: * Should I be counting URLs as only 19 characters? * If so, will the Twitter API be adjusted to count URLs as only 19 characters, and not reject messages that are longer because the URLs are longer? * And if that's the plan, when is it likely to happen? * And should I also count URLs that are less than 19 characters as 19 characters, on the assumption that they will *always* be wrapped? Ah, I just did a search for link wrap and say [this thread][] from September. Doesn't look like there was an official answer from Twitter -- did I miss it? If not, does anyone have any idea when there might be more information on this stuff and how it will affect the API? Thanks, David [this message]: http://groups.google.com/group/twitter-development-talk/msg/9bdd19b025fe0cba ? [this thread]: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/dacc3bdc5b1e1d67 -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] t.co Posting Questions
On Dec 20, 2010, at 4:16 AM, Emil Tullstedt wrote: As for bit.ly, there is an API for bit.ly which aids you in using URL-shortening until t.co is finished.. Yeah, but it's rate-limited. I'm using http://s.coop/ for now. Dead simple. Best, David -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] t.co Posting Questions
On Mon, 20 Dec 2010 10:21:32 -0800, David E. Wheeler da...@kineticode.com wrote: On Dec 20, 2010, at 4:16 AM, Emil Tullstedt wrote: As for bit.ly, there is an API for bit.ly which aids you in using URL-shortening until t.co is finished.. Yeah, but it's rate-limited. I'm using http://s.coop/ for now. Dead simple. Best, David *All* services are rate-limited and *none* are free. ;-) -- http://twitter.com/znmeb http://borasky-research.net A mathematician is a device for turning coffee into theorems. -- Paul Erdős -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] t.co Posting Questions
On Dec 20, 2010, at 12:16 PM, M. Edward (Ed) Borasky wrote: Yeah, but it's rate-limited. I'm using http://s.coop/ for now. Dead simple. Best, David *All* services are rate-limited and *none* are free. ;-) True. David -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] t.co URL Shortener removing valid characters from URLs
Hey (first post!), We recently launched a community site for LittleBigPlanet and are having a few problems with the tweet button shortening our links but removing characters from the end of the URL. So I start with this URL: http://lbp.me/v/0b6z- The tweet button then converts this to: http://t.co/m1kHX6D ...which then redirects to (missing the hyphen): http://lbp.me/v/0b6z ...and results in a 404 as that url doesn't exist. The original URL is perfectly valid - so is this expected functionality? Is there any way to force the URL shortener to respect the full URL, or should we consider rejigging our URL hashes? Help much appreciated thanks! :) -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] t.co URL Shortener removing valid characters from URLs
Thanks for the report, we'll investigate. I can't think of a workaround at the moment unfortunately. On Fri, Dec 17, 2010 at 3:51 AM, Tom_Molecule commun...@mediamolecule.comwrote: Hey (first post!), We recently launched a community site for LittleBigPlanet and are having a few problems with the tweet button shortening our links but removing characters from the end of the URL. So I start with this URL: http://lbp.me/v/0b6z- The tweet button then converts this to: http://t.co/m1kHX6D ...which then redirects to (missing the hyphen): http://lbp.me/v/0b6z ...and results in a 404 as that url doesn't exist. The original URL is perfectly valid - so is this expected functionality? Is there any way to force the URL shortener to respect the full URL, or should we consider rejigging our URL hashes? Help much appreciated thanks! :) -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] t.co Posting Questions
Howdy, I'm writing an iPad app that has a Share via Twitter feature. I'm trying to understand how to count characters, including URLs before I post to the API. I thought these might be FAQs, but t.co does not show up in the FAQ and has only two hits via Google's search of this list, so I apologize if these are in fact FAQs. So I tried to post a new status message that was longer than 140 characters, but I counted the URL as only 19 characters, per [this message][] from Raffi. Unfortunately, the API rejected the message as too long. So my questions are: * Should I be counting URLs as only 19 characters? * If so, will the Twitter API be adjusted to count URLs as only 19 characters, and not reject messages that are longer because the URLs are longer? * And if that's the plan, when is it likely to happen? * And should I also count URLs that are less than 19 characters as 19 characters, on the assumption that they will *always* be wrapped? Ah, I just did a search for link wrap and say [this thread][] from September. Doesn't look like there was an official answer from Twitter -- did I miss it? If not, does anyone have any idea when there might be more information on this stuff and how it will affect the API? Thanks, David [this message]: http://groups.google.com/group/twitter-development-talk/msg/9bdd19b025fe0cba? [this thread]: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/dacc3bdc5b1e1d67 -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] t.co wrapped urls in search api response, no unwrap param or entity currently?
I have a nightly batch process that does two searches based on a number of params from the day's data. I don't see that anything has changed here: http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search But now I'm seeing t.co urls in the tweet.text instead of the real url (even though the real url did match my search), and I don't see any attribute set to figure out the real url. This means that url is hidden until I click it, and that won't work for me. Is this temporary, is the documentation out of date? I don't see a url unwrapper api for t.co, so, are there no solutions? -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] t.co wrapped urls in search api response, no unwrap param or entity currently?
Hi Justin, At the moment the Search API doesn't support Tweet entities and so this information is not available without querying the REST API for the Tweet using: http://api.twitter.com/1/statuses/show.json?id=123456?include_entities=1 Best @themattharris Developer Advocate, Twitter http://twitter.com/themattharris On Thu, Oct 28, 2010 at 12:30 PM, Justin justin.carl...@gmail.com wrote: I have a nightly batch process that does two searches based on a number of params from the day's data. I don't see that anything has changed here: http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search But now I'm seeing t.co urls in the tweet.text instead of the real url (even though the real url did match my search), and I don't see any attribute set to figure out the real url. This means that url is hidden until I click it, and that won't work for me. Is this temporary, is the documentation out of date? I don't see a url unwrapper api for t.co, so, are there no solutions? -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] t.co question
What are the plans to implement the automatically t.co url shortening feature via tweets that are sent in via the API? I am getting ready to add this ability to my application, but if Twitter is going to make it an automatic feature then I can save myself the trouble if they will have it implemented soon. I looked at the announcements and did not see any recent updates on this feature. Looking forward to your comments. Dave -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] t.co and fail whales
Twitter folks, how are you going to ensure that t.co links are not affected by over-capacity situations on your infrastructure? If you're routing t.co links through your existing infrastructure, absolutely *everyone's* links are going to be broken when you start throwing fail whales, even when the link is clicked in third-party applications. Are you running t.co on its own separate and dedicated infrastructure? -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] t.co and fail whales
On Fri, 3 Sep 2010 09:12:32 -0700 (PDT) Dewald Pretorius dpr...@gmail.com wrote: Twitter folks, how are you going to ensure that t.co links are not affected by over-capacity situations on your infrastructure? If you're routing t.co links through your existing infrastructure, absolutely *everyone's* links are going to be broken when you start throwing fail whales, even when the link is clicked in third-party applications. Are you running t.co on its own separate and dedicated infrastructure? Ah, that brings up the next idea of how to enhance my application :) It wouldn't be all that hard to keep a cache/database of all the t.co links seen in a user's incoming timeline, and their resolution. The user would then have a private link resolution database, to protect against such service outages. Seems pretty straightforward, perhaps people should do that sort of thing. Bernd -- Bernd Stramm bernd.str...@gmail.com -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
[twitter-dev] t.co link wrapping and the new 140 characters...
I just want this to be confirmed by @raffi If I understand correctly http://groups.google.com/group/twitter-api-announce/browse_thread/thread/14d5474c13ed84aa This means that I can securely send a 120 (or less) character message + a link, no matter how long the link is, it will be translated into 20 characters, and so the total being 140 character I'm fine. Right? My Rails app will send hey this is a message with always a http://link.com/path/to/resource; and all I need to check is that hey this is a message with always a is 120 chars, right? Thanks for confirming this, that would be amazingly cool because it would mean I don't need (and nobody would need) to call some t.co API to shrink a URL. Then I would only need to count on the updated clients (and twitter.com) to display my http://link.com; as a text and http://t.co/jhdafkjh; as a link! Wouldn't be a big deal if some (most) clients display the t.co as a text :) Cheers. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
[twitter-dev] t.co Rollout
I just got an email from Twitter about oAuth and t.co. Given that I have about five accounts, I assume I will get more copies. ;-) Anyhow, in the section on t.co, there was this line: You will start seeing these links on certain accounts that have opted-in to the service How does an account opt-in to t.co? Will there be a setting in the web app, similar to opting-in to locations? Will there be an API call, or will Twitter simply wrap all the links posted by an account that has opted in? If I post a bit.ly link and Twitter wraps it via t.co, will the unwrapped display unwrap just the t.co piece, or will it go all the way down to the raw URL? -- M. Edward (Ed) Borasky http://borasky-research.net http://twitter.com/znmeb A mathematician is a device for turning coffee into theorems. - Paul Erdos -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] t.co Rollout
My recollection is that the character count question was discussed on this list, but I don't remember the number. -- M. Edward (Ed) Borasky http://borasky-research.net http://twitter.com/znmeb A mathematician is a device for turning coffee into theorems. - Paul Erdos Quoting John Meyer john.l.me...@gmail.com: On 9/1/2010 9:34 PM, M. Edward (Ed) Borasky wrote: I just got an email from Twitter about oAuth and t.co. Given that I have about five accounts, I assume I will get more copies. ;-) Anyhow, in the section on t.co, there was this line: You will start seeing these links on certain accounts that have opted-in to the service And in a related question, exactly how is this going to affect character count? Will it be based on the bit.ly URL, or the t.co URL? -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
[twitter-dev] T.co and Privacy Policies
Initially I did not see a privacy issue with t.co But, having thought more about Twitter forcing us to use the t.co link as the first-hop destination, I believe there are some potential privacy issues that need to be clarified. 1) Normally you need to specify in your service or product's privacy policy that you are doing click tracking and other individual or aggregate data collection. How does t.co affect your privacy policy when you knowingly divert a user to an intermediary service (Twitter) that collects data, without the user knowing about the collection or having an opportunity to read and agree to the privacy policy of Twitter? Many clicks will come from people who do not use Twitter or do not have a Twitter account. 2) When you display anchor text of http://cnn.com but send the user to http://t.co/xx when they click the anchor text, isn't that deceptive? The user expects to be sent directly to CNN.com, as inferred by the anchor text, and not to an intermediary service that the user has no knowledge of what that service is going to do or collect. This goes hand in hand with 1) above.
Re: [twitter-dev] t.co mixed messages
While it's true that some details are still being worked out, the following is the intention: a) You post the link http://f.ws/tco within a tweet b) Within the published, text component of the tweet, you'll see the t.coURL c) within the entities of the tweet, you'll see your http://f.ws/tco link d) It's up to clients on how they want to render the link. They might want to render it as a t.co link. They might want to reference the annotation and render the URL there (which would be an f.ws link, not the ultimate destination). They might want to do something else with how they display the URL, or interpret the URL referenced in the entity by some other means. Taylor On Wed, Jun 9, 2010 at 9:06 PM, TJ Luoma luo...@gmail.com wrote: On the list we were told: 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. On the website, (http://blog.twitter.com/2010/06/links-and-twitter-length-shouldnt.html) Twitter said: When this is rolled out more broadly to users this summer, all links shared on Twitter.com or third-party apps will be wrapped with a t.co URL. A really long link such as http://www.amazon.com/Delivering-Happiness-Profits-Passion-Purpose/dp/0446563048might 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- or as the whole URL or page title. Ultimately, we want to display links in a way that removes the obscurity of shortened link and lets you know where a link will take you. Reading that last sentence, it makes it sound like you are going to auto-expand shortened URLs, which would effectively kill all other URL shortening services. Can someone clarify this? I searched through the list archive but didn't see an answer. If I post http://ƒ.ws/tco http://xn--3ha.ws/tco to Twitter (which is a redirect to http://blog.twitter.com/2010/06/links-and-twitter-length-shouldnt.html), will the user see http://ƒ.ws/tco http://xn--3ha.ws/tco and if the user clicks on http://ƒ.ws/tco http://xn--3ha.ws/tco will it actually go through (for analytics, etc)? Thanks! TjL
Re: [twitter-dev] t.co Is cool, and I might have an issue with it anyway.
On Thu, 10 Jun 2010 12:14:06 -0700 (PDT) @IDisposable idisposa...@gmail.com wrote: Unlike many posters here, I REALLY LIKE the t.co shortening idea ... So, who's going to yell at us? With all you data miners out there clicking and downloading everything in sight, pretty soon you will only measure the noise created by data miners, web crawlers and the like. Google, yandex and the rest are already a signigicant amount of the traffic for small sites. What this means is that because you are introducing more and more background noise into your data, you will only be able to measure the really strong signals. That narrows what you can find, and you risk that eventually you find only obvious things. -- Bernd Stramm bernd.str...@gmail.com
[twitter-dev] t.co Is cool, and I might have an issue with it anyway.
Unlike many posters here, I REALLY LIKE the t.co shortening idea. In addition to enabling the blocking of malicious links, it will enable Twitter to start offering some metrics and buzz rating on shared links. I might have an issue with adhering to the letter of the TOS, if not the actual spirit. To get to the point, I need to introduce our platformso let me explain our Twitter use at BuzzRadius (platform) and STL Tweets (canonical example). In each metro vertical silo, we consume a curated list of users (organised as per-category Twitter Lists against per-top-level-category twitter users -- e.g. http://twitter.com/STLT_Politics/city-of-st-louis) using the timelines, and ALSO consume a ton of searches for hashtags- per-category, a search against common local terms terms and the old- style (Summize based) search for geocoded profiles in a radius around the metro area. This gives us a local lens into Twitter that we offer up to anyone (even not using/having a Twitter account). You can see an example of the platform in use at http://stltweets.com Once we get tweets, we extract the RawLinks, Hashtags, Mentions and label/categorize them based on which of the sources provided the tweet. We then offer those categorized list of tweets under the various tabs like http://stltweets.com/Tweets/CityPolitics we provide a local search against the curated tweets (to enable focused results). The INTERESTING part is that we then take the RawLinks and canonicalize them and explore them to solve several problems: 1) We want the meta-data of the final destination of the Link... headline, body-text, media-type, etc. This allows presentation of type-specific link lists (e.g. Photos, Videos, Audio, Location, News, etc.) We can also grab thumbnail and embedding information to enable presentation on our side where possible. 2) We want to take all the RawLinks that point to the same actual destination link and follow them all the way down and associate the RawLink to a canonical Link. We do this by following links, redirections, frame-busting, query-string stripping of utm-tracking (etc.), link rel=canonical and all that other fancy stuff to get a URL that is the final destination of the RawLink. This allows us to calculate a Buzz value for the Link based on how many people tweet about it, how recently, etc... EVEN IF the use different sources, shorteners, etc to get there. 3) We provide an ordered/ranked list of Links whenever a user visits a links page like http://stltweets.com/Links/CityPolitics if someone clicks on a link on this page, we send them to a Link detail page that show the meta-data and all the tweets that reference the Link (independant of the RawLink that leads there). 4) In the next deployment, we will also be doing ANONYMOUS link click- through tracking of the presented links to also gather the resonance in our audience for feed-forward into the Link ranking in bullet 3. Right now, that tracking is done only when clicking off the Link detail page like http://stltweets.com/Links/CityPolitics/Detail/804058 but we're also going to be redecorating the Tweet links when rendering the tweets in a stream. SO FINALLY TO THE POINT: In our current release, we present the RawLink in the tweet without redecoration so once Twitter starts feeding us t.co links, we'll be proffering those up just fine. Were good to go on any pages showing the original tweets (any Tweet list, including the list of tweets referencing a canonicalized Link). In future release, we will still be okay, because we'll click through our site and serve a 302 redirection to the original t.co URL (which in all likelihood is also to a shortener, but no matter). In our current release, when we show the user the canonicalized Link page, the tweet listing is good to go (see above), but the Link detail section at the top is NOT compliant because we cannot tell WHICH OF MANY possible RawLinks the user is interested in, so we cannot serve the original link at all. Once Twitter starts serving t.co links, we cannot know which (of possibly many) the user is responding to. This sucks for Twitter, because they can't gather metrics, or mal-filter. In our case, we distribute the clicked juice to ALL the RawLinks that canonicalized to this Link based on the number of tweets that each RawLink got. It's an estimate, but it is all we have. In a future release, we will be putting in a best-effort change in that if a Link has only ONE RawLink referring to it, we'll actually click-through that RawLink instead of the canonicalized Link. This will enable proper tracking in a original URL (e.g. the utm-tracking, etc that we stripped will be honored). Once Twitter starts serving t.co URLs, we'll thus pass through per the TOS. As you can, however, we cannot ALWAYS do the right thing, because we don't know which RawLink to redirect through if the user clicks through the Link instead of the Tweet. So, who's going to yell at us?
[twitter-dev] t.co issue -- querying for original url in streaming search apis
I'm creating a new thread for this because a few others have mentioned it,
and we haven't gotten a response yet. My hunch is that changing those APIs
involve other teams within Twitter, so figuring out a solution could be
challenging.
Here is the issue. We need to be able to get matches on the original URL
through the streaming and search APIs. For me, I'm tracking act so I can
match tweets that link to 'http://act.ly'. This is not a link shortener
service, the actual pages live at act.ly, and it was all designed
specifically for Twitter so there would be no need for url shorteners.
As far as I'm concerned, it's fine if that link changes to t.co, as long as
I can still get matches on act.ly (or act) through the streaming API (the
search API is going to be important for people too, but less of an issue for
me personally).
The most elegant way to fix this would be to allow tracking of the original
URL. So I can put in a domain name, or URL substring, and match everything
that way. Same with search. This would be useful to a lot of people, and
virtually all link oriented web apps with APIs provide a way to get all the
matches for a particular domain. (digg, google, yahoo, etc)
I'm sure there are other workaround ways of doing this, and I'm all ears.
It would be SUPER NICE (wink wink) to hear some kind of assurance that
there will be a way for us to query this type of information before
the t.cochanges go live.
Thanks guys...
Jim Gilliam
http://act.ly/
http://twitter.com/jgilliam
On Tue, Jun 8, 2010 at 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 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]
}
],
...
},
Re: [twitter-dev] t.co issue -- querying for original url in streaming search apis
Currently Search (and probably Streaming) returns results that match text in unshortened URLs not just in the text of the status. I doubt It would change now especially with t.co coming. Abraham - Abraham Williams | Developer for hire | http://abrah.am @abraham | http://projects.abrah.am | http://blog.abrah.am This email is: [ ] shareable [x] ask first [ ] private. On Wed, Jun 9, 2010 at 12:13, Jim Gilliam j...@gilliam.com wrote: I'm creating a new thread for this because a few others have mentioned it, and we haven't gotten a response yet. My hunch is that changing those APIs involve other teams within Twitter, so figuring out a solution could be challenging. Here is the issue. We need to be able to get matches on the original URL through the streaming and search APIs. For me, I'm tracking act so I can match tweets that link to 'http://act.ly'. This is not a link shortener service, the actual pages live at act.ly, and it was all designed specifically for Twitter so there would be no need for url shorteners. As far as I'm concerned, it's fine if that link changes to t.co, as long as I can still get matches on act.ly (or act) through the streaming API (the search API is going to be important for people too, but less of an issue for me personally). The most elegant way to fix this would be to allow tracking of the original URL. So I can put in a domain name, or URL substring, and match everything that way. Same with search. This would be useful to a lot of people, and virtually all link oriented web apps with APIs provide a way to get all the matches for a particular domain. (digg, google, yahoo, etc) I'm sure there are other workaround ways of doing this, and I'm all ears. It would be SUPER NICE (wink wink) to hear some kind of assurance that there will be a way for us to query this type of information before the t.co changes go live. Thanks guys... Jim Gilliam http://act.ly/ http://twitter.com/jgilliam On Tue, Jun 8, 2010 at 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 Gilliam http://act.ly/ http://twitter.com/jgilliam On Tue, Jun 8, 2010 at 4:33 PM, Dewald Pretorius dpr...@gmail.comwrote: 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.
Re: [twitter-dev] t.co issue -- querying for original url in streaming search apis
We will have this support in the streaming API. Track terms will work against tweet text as well as entity text. Currently streaming does *not* work as Abraham describes below. We only match against tweet text, and don't do any link expansion/contraction. ---Mark http://twitter.com/mccv On Wed, Jun 9, 2010 at 12:13 PM, Jim Gilliam j...@gilliam.com wrote: I'm creating a new thread for this because a few others have mentioned it, and we haven't gotten a response yet. My hunch is that changing those APIs involve other teams within Twitter, so figuring out a solution could be challenging. Here is the issue. We need to be able to get matches on the original URL through the streaming and search APIs. For me, I'm tracking act so I can match tweets that link to 'http://act.ly'. This is not a link shortener service, the actual pages live at act.ly, and it was all designed specifically for Twitter so there would be no need for url shorteners. As far as I'm concerned, it's fine if that link changes to t.co, as long as I can still get matches on act.ly (or act) through the streaming API (the search API is going to be important for people too, but less of an issue for me personally). The most elegant way to fix this would be to allow tracking of the original URL. So I can put in a domain name, or URL substring, and match everything that way. Same with search. This would be useful to a lot of people, and virtually all link oriented web apps with APIs provide a way to get all the matches for a particular domain. (digg, google, yahoo, etc) I'm sure there are other workaround ways of doing this, and I'm all ears. It would be SUPER NICE (wink wink) to hear some kind of assurance that there will be a way for us to query this type of information before the t.co changes go live. Thanks guys... Jim Gilliam http://act.ly/ http://twitter.com/jgilliam On Tue, Jun 8, 2010 at 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 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
Re: [twitter-dev] t.co issue -- querying for original url in streaming search apis
Fantastic, thank you! On Wed, Jun 9, 2010 at 2:48 PM, Mark McBride mmcbr...@twitter.com wrote: We will have this support in the streaming API. Track terms will work against tweet text as well as entity text. Currently streaming does *not* work as Abraham describes below. We only match against tweet text, and don't do any link expansion/contraction. ---Mark http://twitter.com/mccv On Wed, Jun 9, 2010 at 12:13 PM, Jim Gilliam j...@gilliam.com wrote: I'm creating a new thread for this because a few others have mentioned it, and we haven't gotten a response yet. My hunch is that changing those APIs involve other teams within Twitter, so figuring out a solution could be challenging. Here is the issue. We need to be able to get matches on the original URL through the streaming and search APIs. For me, I'm tracking act so I can match tweets that link to 'http://act.ly'. This is not a link shortener service, the actual pages live at act.ly, and it was all designed specifically for Twitter so there would be no need for url shorteners. As far as I'm concerned, it's fine if that link changes to t.co, as long as I can still get matches on act.ly (or act) through the streaming API (the search API is going to be important for people too, but less of an issue for me personally). The most elegant way to fix this would be to allow tracking of the original URL. So I can put in a domain name, or URL substring, and match everything that way. Same with search. This would be useful to a lot of people, and virtually all link oriented web apps with APIs provide a way to get all the matches for a particular domain. (digg, google, yahoo, etc) I'm sure there are other workaround ways of doing this, and I'm all ears. It would be SUPER NICE (wink wink) to hear some kind of assurance that there will be a way for us to query this type of information before the t.co changes go live. Thanks guys... Jim Gilliam http://act.ly/ http://twitter.com/jgilliam On Tue, Jun 8, 2010 at 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 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.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.colink instead. and, we want to
Re: [twitter-dev] t.co issue -- querying for original url in streaming search apis
Just to say it, this matching of actual URL as well as the shortened, supplied URL has been regarded as a bug by our users; it confuses them. I would prefer it if it were optional to search so that I could turn it off... They only want to match the literal text... We provide means for them to deal with the actual/final URL by others means and in a different context. The entire t.co idea is not really of use to us as a monitoring service. Sent from my iPhone On Jun 9, 2010, at 2:46 PM, Abraham Williams 4bra...@gmail.com wrote: Currently Search (and probably Streaming) returns results that match text in unshortened URLs not just in the text of the status. I doubt It would change now especially with t.co coming. Abraham - Abraham Williams | Developer for hire | http://abrah.am @abraham | http://projects.abrah.am | http://blog.abrah.am This email is: [ ] shareable [x] ask first [ ] private. On Wed, Jun 9, 2010 at 12:13, Jim Gilliam j...@gilliam.com wrote: I'm creating a new thread for this because a few others have mentioned it, and we haven't gotten a response yet. My hunch is that changing those APIs involve other teams within Twitter, so figuring out a solution could be challenging. Here is the issue. We need to be able to get matches on the original URL through the streaming and search APIs. For me, I'm tracking act so I can match tweets that link to 'http://act.ly'. This is not a link shortener service, the actual pages live at act.ly, and it was all designed specifically for Twitter so there would be no need for url shorteners. As far as I'm concerned, it's fine if that link changes to t.co, as long as I can still get matches on act.ly (or act) through the streaming API (the search API is going to be important for people too, but less of an issue for me personally). The most elegant way to fix this would be to allow tracking of the original URL. So I can put in a domain name, or URL substring, and match everything that way. Same with search. This would be useful to a lot of people, and virtually all link oriented web apps with APIs provide a way to get all the matches for a particular domain. (digg, google, yahoo, etc) I'm sure there are other workaround ways of doing this, and I'm all ears. It would be SUPER NICE (wink wink) to hear some kind of assurance that there will be a way for us to query this type of information before the t.co changes go live. Thanks guys... Jim Gilliam http://act.ly/ http://twitter.com/jgilliam On Tue, Jun 8, 2010 at 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 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
[twitter-dev] t.co mixed messages
On the list we were told: 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. On the website, (http://blog.twitter.com/2010/06/links-and-twitter-length-shouldnt.html) Twitter said: When this is rolled out more broadly to users this summer, all links shared on Twitter.com or third-party apps will be wrapped with a t.co URL. 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- or as the whole URL or page title. Ultimately, we want to display links in a way that removes the obscurity of shortened link and lets you know where a link will take you. Reading that last sentence, it makes it sound like you are going to auto-expand shortened URLs, which would effectively kill all other URL shortening services. Can someone clarify this? I searched through the list archive but didn't see an answer. If I post http://ƒ.ws/tco; to Twitter (which is a redirect to http://blog.twitter.com/2010/06/links-and-twitter-length-shouldnt.html), will the user see http://ƒ.ws/tco; and if the user clicks on http://ƒ.ws/tco will it actually go through (for analytics, etc)? Thanks! TjL
