Re: [twitter-dev] t.co?

[Tom van der Woerdt]

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?

[SM]

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

[Ben Marsh]

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

[David E. Wheeler]

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

Re: [twitter-dev] t.co Posting Questions

[Abraham Williams]

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  | 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 wrote:

> 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

[David E . Wheeler]

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 reverse

[Taylor Singletary]

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=23150950055153664&include_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  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

[twitter-dev] t.co reverse

[Amaury]

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 Posting Questions

[David E. Wheeler]

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

Re: [twitter-dev] t.co Posting Questions

[M. Edward (Ed) Borasky]

On Mon, 20 Dec 2010 10:21:32 -0800, "David E. Wheeler"
 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

[David E. Wheeler]

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

[Emil Tullstedt]

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  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

[David E. Wheeler]

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

[Tom van der Woerdt]

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-dev] t.co Posting Questions

[David E. Wheeler]

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

Re: [twitter-dev] t.co URL Shortener removing valid characters from URLs

[Taylor Singletary]

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
wrote:

> 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 URL Shortener removing valid characters from URLs

[Tom_Molecule]

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 wrapped urls in search api response, no unwrap param or entity currently?

[Matt Harris]

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  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 wrapped urls in search api response, no unwrap param or entity currently?

[Justin]

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-dev] t.co question

[DaveH]

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 link wrapping and the "new" 140 characters...

[StuFF mc]

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

Re: [twitter-dev] t.co and fail whales

[Bernd Stramm]

On Fri, 3 Sep 2010 09:12:32 -0700 (PDT)
Dewald Pretorius  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 and fail whales

[Dewald Pretorius]

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 Rollout

[M. Edward (Ed) Borasky]

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 :


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

Re: [twitter-dev] t.co Rollout

[John Meyer]

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-dev] t.co Rollout

[M. Edward (Ed) Borasky]

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

[twitter-dev] t.co Is cool, and I might have an issue with it anyway.

[@IDisposable]

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?

Re: [twitter-dev] t.co Is cool, and I might have an issue with it anyway.

[Bernd Stramm]

On Thu, 10 Jun 2010 12:14:06 -0700 (PDT)
"@IDisposable"  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

Re: [twitter-dev] t.co mixed messages

[Taylor Singletary]

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  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 " 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
>

[twitter-dev] T.co and Privacy Policies

[Dewald Pretorius]

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.

[twitter-dev] t.co mixed messages

[TJ Luoma]

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

Re: [twitter-dev] t.co issue -- querying for original url in streaming & search apis

[Jeffrey Greenberg]

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  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  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   
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  wrote:
> hi all.
>
> twitter has been wrapping links in e-mailed DMs for a couple months
> now.
> 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 re

Re: [twitter-dev] t.co issue -- querying for original url in streaming & search apis

[Jim Gilliam]

Fantastic, thank you!

On Wed, Jun 9, 2010 at 2:48 PM, Mark McBride  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  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  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 
> 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  wrote:
> >>> > hi all.
> >>> >
> >>> > twitter has been wrapping links in e-mailed DMs for a couple months
> >>> > now.
> >>> > 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 

Re: [twitter-dev] t.co issue -- querying for original url in streaming & search apis

[Mark McBride]

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  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  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  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  wrote:
>>> > hi all.
>>> >
>>> > twitter has been wrapping links in e-mailed DMs for a couple months
>>> > now.
>>> > 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 pro

Re: [twitter-dev] t.co issue -- querying for original url in streaming & search apis

[Abraham Williams]

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  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  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 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  wrote:
>>> > hi all.
>>> >
>>> > twitter has been wrapping links in e-mailed DMs for a couple months
>>> > now.
>>> > 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 

[twitter-dev] t.co issue -- querying for original url in streaming & search apis

[Jim Gilliam]

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  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  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  wrote:
>> > hi all.
>> >
>> > twitter has been wrapping links in e-mailed DMs for a couple months
>> > now.
>> > 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",
>> > ...
>> >   },
>> >   ...
>> >   "entiti