Hi,
Is it possible to get those links when using the user_timeline REST
API:
http://twitter.com/status/user_timeline/{user}.json?count=5&callback=?
The returned result doesn't give you any links - the http/https and
the links to other twitter accounts are just as plain text.
I need a simple way
I've noticed on Raffi's timeline a field called expanded_url not
display_url for a t.co entity. Is the expanded_url element to be
treated differently, or is it as it says it is, the expanded version
of any url and not necessarily just t.co urls?
On Jun 10, 3:38 pm, Rich wrote:
> Another question
Another question will you HAVE to use include_entities=true to see the
display_url or will it always be included?
On Jun 10, 4:21 am, ASK wrote:
> How disruptive - and not in the "good way", for the most part.
>
> For example, I've recently been developing a link shortening platform
> with some u
How disruptive - and not in the "good way", for the most part.
For example, I've recently been developing a link shortening platform
with some unique aspects (similar to Twitter annotations). Here is a
mashup that leverages my platform in conjunction with Twitter:
http://mvtweets.com/tweetmap. Jus
On 6/9/2010 7:00 PM, Bernd Stramm wrote:
On Wed, 09 Jun 2010 17:13:04 -0700
"M. Edward (Ed) Borasky" wrote:
Quoting Ken:
Not exactly spyware, but deceptive. Don't expect the public to
appreciate this.
How is this deceptive? Who is being deceived, and how?
How? There is text that is marke
On Wed, 09 Jun 2010 17:13:04 -0700
"M. Edward (Ed) Borasky" wrote:
> Quoting Ken :
>
> > Not exactly spyware, but deceptive. Don't expect the public to
> > appreciate this.
>
> How is this deceptive? Who is being deceived, and how?
How? There is text that is marked as a link, for example
"http
Quoting Ken :
Not exactly spyware, but deceptive. Don't expect the public to
appreciate this.
How is this deceptive? Who is being deceived, and how?
On Jun 9, 9:45 pm, Bernd Stramm wrote:
If an application wants to provide the original intent of the user, it
is forced (by ToS), to present
Not exactly spyware, but deceptive. Don't expect the public to
appreciate this.
On Jun 9, 9:45 pm, Bernd Stramm wrote:
> If an application wants to provide the original intent of the user, it
> is forced (by ToS), to present a link that doesn't go to where it says
> it does. That is problematic,
Quoting Bernd Stramm :
On Wed, 09 Jun 2010 12:22:03 -0700
"M. Edward (Ed) Borasky" wrote:
Quoting Ron B :
> I just had one of those *rough edges* brought to my attention that I
> think may also have already been alluded to on this thread. Some
> users use long URLs as a portion or even thei
Hi Raffi,
my Twitter client has an option to post links to del.ico.us, Read-it
Later and Instapaper. Do I have to post the t.co links there or will I
be allowed to use the expanded links?
ole @ mobileways.de / @janole on Twitter ( Gravity Twitter Client for
Symbian )
On 9 Jun., 00:57, Raffi Krik
On Wed, 09 Jun 2010 12:22:03 -0700
"M. Edward (Ed) Borasky" wrote:
> Quoting Ron B :
>
> > I just had one of those *rough edges* brought to my attention that I
> > think may also have already been alluded to on this thread. Some
> > users use long URLs as a portion or even their entire tweet.
Quoting Ron B :
I just had one of those *rough edges* brought to my attention that I
think may also have already been alluded to on this thread. Some
users use long URLs as a portion or even their entire tweet. This
tweet technique is being used significantly in tweets about the Gulf
oil spill
Chris, I am not worried about that or any of this, but agree that it's
unfortunate to lose the choice. And it feels wrong to be obfuscating
links to my own website...
For apps that display tweets, I understand that the t.co link must be
used and not the display link. But what does it mean, "requir
I just had one of those *rough edges* brought to my attention that I
think may also have already been alluded to on this thread. Some
users use long URLs as a portion or even their entire tweet. This
tweet technique is being used significantly in tweets about the Gulf
oil spill crisis, for exampl
My 2 pence:
The difference with bit.ly is that I choose to use it. If I don't want
to use it I'm not forced to.
Additionally, what happens if the t.co service goes down? All links
will be temporarily broken until the service goes back up.
On Jun 9, 4:17 pm, Harshad RJ wrote:
> On Wed, Jun 9, 2
Quoting Ron B :
Users are accustomed to the fact that use of *free* services is
entirely *as is* and at their own risk, so none of us should feel we
have to protect their privacy or their security beyond this original
expectation. If they don't like the performance, security, or privacy
implica
Users are accustomed to the fact that use of *free* services is
entirely *as is* and at their own risk, so none of us should feel we
have to protect their privacy or their security beyond this original
expectation. If they don't like the performance, security, or privacy
implications of this chang
I think it pretty much depends on what Twitter will require us to do
when following t.co links. On their own website and in their own
Twitter clients I could imagine that they will track link usage from
people clicking on the link (sooner or later.)
If they don't require third party clients to sen
I, like others, have problems with this new "service". My main
concern is this. In the past, we had an expectation that what we post
to twitter will be shown verbatim. Some people will want to post a
url and know that it will be shown that way across all sites/apps.
Like it or not, urls have me
-totally-
the timeline on this is, i think (and i'll check to be sure), sometime like
6-8 weeks.
On Wed, Jun 9, 2010 at 1:45 AM, Rich wrote:
> Please make sure the timeline for this is LONGER than 2 weeks please,
> some of us have to code this and then wait at least a week to get
> through Appl
Rich,
That of course would be the right thing for Twitter to do. In other
words, if they want this change, then they must take the bulk of the
pain, instead of creating a problem and dumping it on the developers
to solve.
On Jun 9, 11:46 am, Rich wrote:
> My proposal is you need to keep the 140
On Wed, Jun 9, 2010 at 6:48 PM, Dewald Pretorius wrote:
>
> I don't buy the click tracking privacy argument. Twitter will have no
> more insight into clicks than what bit.ly or any other shortening
> service has,
>
The difference being that the user who clicks the links in Twitter will have
most
As well as everything that others have asked, I'm also concerned about the
following:
1) Does this mean that tweets can effectively be infinite length - say I
write a tweet with 120 chars of text and then
http://www.a-really-really-really-long-url-maybe-with-a-message-encoded.com/in-the-middle-of-
I'm a +1 one for the huge can of worms this is going to cause with
realtime character counting. Here are my concerns
1) An app realtime character counts what is entered in a text box and
that could end up being wrong when posted (and in the mobile space
making ANOTHER http call just get yet anoth
Dewald Pretorius wrote:
> StatusNet, blog, etc.). If the privacy argument carried any water, then
bit.ly
> would be a far greater privacy threat than Twitter.
I agree, and that's why I (and others) were working on solutions to get
around bit.ly and other link shorteners. And, Twitter has already d
This thing really is a can of worms, in terms of:
1) The impact on the ecosystem if characters are counted after link
wrapping.
2) The impact on Twitter's core system and SMS communication if
characters are counted before link wrapping.
3) The perception that there is no guaranteed stability in th
Would it be possible to use a 3rd party URL lengthener (like
http://longurlplease.com/) then use that?
Alice posts bit.ly/foo
Twitter changes it to t.co/bar
LongUrl returns bit.ly/foo resolves to example.com
App shows http://t.co/bar";>example.com
When Bob clicks on example.com, he hits t.co, whic
> But if apps don't update and user sends a tweet which is just below
> 140 characters say, 139, and which contain a link(s) shorter than 19
> (or is it 20) characters will mysteriously fail. The user will wonder
> why the app doesn't let them send the tweet when their app clearly
> says it's still
At present my code reads a tweet in plain text format. It then adds
tags to any links, the @username and the #tags. It then looks for
twitpic/flickr/youtube etc urls it will add a clickable thumbnail to
the top of the tweet.
As I can see it, my code will need to put the t.co in the tag, do
a look
Please make sure the timeline for this is LONGER than 2 weeks please,
some of us have to code this and then wait at least a week to get
through Apple's approval system. This is especially important when it
comes to detecting images, etc.
Richard
On Jun 9, 4:27 am, Raffi Krikorian wrote:
> yeah
Sorry if this is pedantic, but can you point to Twitter's definition
of "malicious" ?
Obviously, viruses, phishing etc. Presumably, "fraudulent" or
"illegal" would be included, but this might vary depending on the
jurisdiction.
Also, if a site is banned in country x, can the government of x
reque
On Tue, 8 Jun 2010 22:19:04 -0700 (PDT)
Hwee-Boon Yar wrote:
> But if apps don't update and user sends a tweet which is just below
> 140 characters say, 139, and which contain a link(s) shorter than 19
> (or is it 20) characters will mysteriously fail. The user will wonder
> why the app doesn't l
But if apps don't update and user sends a tweet which is just below
140 characters say, 139, and which contain a link(s) shorter than 19
(or is it 20) characters will mysteriously fail. The user will wonder
why the app doesn't let them send the tweet when their app clearly
says it's still within 14
Existing url shortners will continue to work just fine. We're not
going to resolve them to their final link and remove them from the
chain.
By redirecting all links, we can protect all users and the entire
ecosystem much faster. The adoption via opt-in would be slower, and
might never reach critic
All links will be wrapped. It's not about length.
On Tue, Jun 8, 2010 at 9:06 PM, Alex B wrote:
> OK, it's a little confusing naming for display URL, as that implies
> that is what clients should show directly to the users, as most of the
> time I would imagine that field should be cut for brevi
OK, it's a little confusing naming for display URL, as that implies
that is what clients should show directly to the users, as most of the
time I would imagine that field should be cut for brevity.
The difference between having a ping service that can help twitter
track clicks and a redirect servi
Are all links going to be wrapped or only long links? If it's the
latter, what's the definition?
1. This affects how we count characters before sending and has quite a
potential to go wrong, since we'll now need to know exactly which
links are going to be wrapped in a tweet.
2. It's also going to
I was basing my statement on the blog post, which indicated that at least
some "display URLs" will be truncated:
http://blog.twitter.com/2010/06/links-and-twitter-length-shouldnt.html
"A really long link such as
http://www.amazon.com/Delivering-Happiness-Profits-Passion-Purpose/dp/044656
30
yeah - its definitely case that counting characters will become a bit more
subtle. i hope that we can provide a really good and easy way to help you
all out. at the very least we are going to update documentation, but i know
we can do better than that.
On Tue, Jun 8, 2010 at 8:17 PM, Andy Matsub
>
> Right now, Twitter can see all the links that users *post*, but they don't
> see which links users *click*.
>
> In order to implement this feature, Twitter has already built the framework
> that does all the hard work that applications need to protect users'
> privacy
> against (link-shortener)
>
> What's the algorithm for the display url? Ideally it will be a
> predictable length, to aid predictability in tweet display code.
>
i'm not sure why the display_url would be of predictable length? the
display_url is -exactly- the URL that the user has sent into the system.
so, that may be of
Raffi wrote:
> related to this: the way the Twitter API counts characters is going to change
> ever so slightly. our 140
> characters is now going to be defined as 140 characters after link wrapping.
> t.co links are of a
> predictable length -- they will always be 20 characters. after we make th
our hope is to eventually provide this analytics.
On Tue, Jun 8, 2010 at 7:14 PM, Sami wrote:
> I don't see how this feature could impact user privacy more than what
> it is right now. Today Twitter stores all links for all users and they
> can spy on them and the t.co shortner is not changing t
Sami wrote:
> I don't see how this feature could impact user privacy more than what it
is right
> now. Today Twitter stores all links for all users and they can spy on them
and the
> t.co shortner is not changing that :)
Right now, Twitter can see all the links that users *post*, but they don't
se
What's the algorithm for the display url? Ideally it will be a
predictable length, to aid predictability in tweet display code.
If the motive is really to protect us from malicious URLs, what about
giving a service we can call to route links through your protective
redirect servers? Then we can gi
I don't see how this feature could impact user privacy more than what
it is right now. Today Twitter stores all links for all users and they
can spy on them and the t.co shortner is not changing that :)
My question is, will developers have access to analytics from t.co
through API?
Thanks
+1 on this, I'd like to know the answer as well.
Damon/@dacort
On Jun 8, 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
If you do this, you will literally be forcing app developers to waste users
time and money, especially over metered GRPS/3G connections.
If the user can see the full URL, then why do they need to be "protected"
any more than they are when they use any other service? If anything, you
should be
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 Preto
So what are you saying? Suck it up? That's what I am hearing.
I have a work-around for the problem, in that I can simply adjust my
in-house shortening service to start generating 19-character URLs. But
other developers don't have that option.
On Jun 8, 8:58 pm, Raffi Krikorian wrote:
> its true,
its true, and we understand that.
just to correct my previous post, however -- t.co links are 19 characters.
On Tue, Jun 8, 2010 at 4:53 PM, Dewald Pretorius wrote:
> This is not unique to me. This will be problematic for anyone who uses
> a shortening service that shortens URLs to less than 20
>
> How will this affect links for third party services that clients
> handle natively, such as Twitpic (and obviously TwitLonger, which
> already has shorter dedicated short urls for its posts)?
>
that's why we are providing all the data back out in the API. while the
tweet itself may have t.co,
This is not unique to me. This will be problematic for anyone who uses
a shortening service that shortens URLs to less than 20 characters.
In these cases, you are basically adding characters to the submitted
text, and then rejecting the submitted text as being too long.
On Jun 8, 8:33 pm, Dewald
How will this affect links for third party services that clients
handle natively, such as Twitpic (and obviously TwitLonger, which
already has shorter dedicated short urls for its posts)?
I'll also be interested to see how this goes down with the privacy
types who will now be paranoid that Twitter
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
55 matches
Mail list logo
