All links will be wrapped. It's not about length.
On Tue, Jun 8, 2010 at 9:06 PM, Alex B <alex.boswo...@gmail.com> wrote: > OK, it's a little confusing naming for display URL, as that implies > that is what clients should show directly to the users, as most of the > time I would imagine that field should be cut for brevity. > > The difference between having a ping service that can help twitter > track clicks and a redirect service that can help twitter protect > users, and having twitter simply force-edit everyone's tweet texts, is > that instead of providing a new service that developers and users can > opt to use, you are providing a service that everyone _must_ use or > add code to work around. > > You could have simply provided an extension to posting new tweets that > identified the real urls of shortened urls, that would have protected > short url providers who invested in your platform and allowed > developers to add the improvement on their own time frames. > > I like the general idea of embedding real links in the twitter > metadata even if it adds to an already bloated tweet data payload, but > Twitter isn't respecting its ecosystem here by forcing complexity on > all developers and giving a time frame of weeks to change established > code developed over years. > > On Jun 9, 11:18 am, Raffi Krikorian <ra...@twitter.com> wrote: >> > What's the algorithm for the display url? Ideally it will be a >> > predictable length, to aid predictability in tweet display code. >> >> i'm not sure why the display_url would be of predictable length? the >> display_url is -exactly- the URL that the user has sent into the system. >> so, that may be of varying length. >> >> > If the motive is really to protect us from malicious URLs, what about >> > giving a service we can call to route links through your protective >> > redirect servers? Then we can give users the option to be protected by >> > your malicious detection algorithms if they want. >> >> If you want to click track every URL for whatever reason, ask client >> >> > developers to hit a ping URL if the user clicks? I'm not sure >> > otherwise how you will tell in a software client if it's the user >> > requesting the t.co URL or the software. >> >> i guess i'm confused on this as well? isn't that what t.co does? >> >> >> >> >> >> > On Jun 9, 6:57 am, Raffi Krikorian <ra...@twitter.com> wrote: >> > > hi all. >> >> > > twitter has been wrapping links in e-mailed DMs for a couple months >> > > now<http://bit.ly/twttldmemail>. >> > > with that feature, we're trying to protect users against phishing and >> > other >> > > malicious attacks. the way that we're doing this is that any URL that >> > comes >> > > through in a DM gets currently wrapped with a twt.tl URL -- if the URL >> > turns >> > > out to be malicious, Twitter can simply shut it down, and whoever follows >> > > that link will be presented with a page that warns them of potentially >> > > malicious content. in a few weeks, we're going to start slowly enabling >> > this >> > > throughout the API for all statuses as well, but instead of twt.tl, we >> > will >> > > be using t.co. >> >> > > practically, any tweet that is sent through statuses/update that has a >> > link >> > > on it will have the link automatically converted to a t.co link on its >> > way >> > > through the Twitter platform. if you fetch any tweet created after this >> > > change goes live, then its text field will have all its links >> > automatically >> > > wrapped with t.co links. when a user clicks on that link, Twitter will >> > > redirect them to the original URL after first confirming with our >> > database >> > > that that URL is not malicious. on top of the end-user benefit, we hope >> > to >> > > eventually provide all developers with aggregate usage data around your >> > > applications such as the number of clicks people make on URLs you display >> > > (it will, of course, be in aggregate and not identifiable manner). >> > > additionally, we want to be able to build services and APIs that can make >> > > algorithmic recommendations to users based on the content they are >> > > consuming. gathering the data from t.co will help make these possible. >> >> > > our current plan is that no user will see a t.co URL on twitter.com but >> > we >> > > still have some details to work through. the links will still be >> > displayed >> > > as they were sent in, but the target of the link will be the t.co link >> > > instead. and, we want to provide the same ability to display original >> > links >> > > to developers. we're going to use the entities attribute to make this >> > > possible. >> >> > > let's say i send out the following tweet: "you have to check outhttp:// >> > dev.twitter.com!" >> >> > > a returned (and truncated) status object may look like: >> >> > > { >> > > "text" : "you have to check outhttp://t.co/s9gfk2d4!";, >> > > ... >> > > "user" : { >> > > "screen_name" : "raffi", >> > > ... >> > > }, >> > > ... >> > > "entities" : { >> > > "urls" : [ >> > > { >> > > "url" : "http://t.co/s9gfk2d4";, >> > > "display_url" : "http://dev.twitter.com";, >> > > "indices" : [23, 43] >> > > } >> > > ], >> > > ... >> > > }, >> > > ... >> >> > > } >> >> > > two things to note: the text of the returned status object doesn't have >> > the >> > > original URL and instead it has a t.co URL, and the entities block now >> > has a >> > > display_url attribute associated with it. what we're hoping is that with >> > > this data, it should be relatively easy to create a UI where you replace >> > thehttp://t.co/s9gfk2d4inthe text with the equivalent of >> >> > > <a href="http://t.co/s9gfk2d4";>http://dev.twitter.com</a> >> >> > > this means the user would not see the t.co link, but we all can still >> > > provide the protection and gather data from the wrapped link. for the >> > > applications that don't choose to update, the t.co link will be shown >> > (and >> > > the goal to protect users will be met). i just want to emphasize -- we >> > > really do hope that you all render the original URL, but please send the >> > > user through the t.co link. if you do choose to prefetch all the URLs >> > on a >> > > timeline, then, when a user actually clicks on one of the links, please >> > > still send him or her through t.co. We will be updating the TOS to >> > require >> > > you to check t.co and register the click. >> >> > > related to this: the way the Twitter API counts characters is going to >> > > change ever so slightly. our 140 characters is now going to be defined as >> > > 140 characters after link wrapping. t.co links are of a predictable >> > length >> > > -- they will always be 20 characters. after we make this live, it will be >> > > feasible to send in the text for a status that is greater than 140 >> > > characters. the rule is after the link wrapping, the text transforms to >> > 140 >> > > characters or fewer. we'll be using the same logic that is in >> > > twitter-text-rb to figure out what is a URL. >> >> > > look for an update to dev.twitter.com where we'll have a best practices >> > > document on how to use these t.co links. >> >> > > what's the timeline? "soon" we'll enable this on @twitterapi, @rsarver, >> > > @raffi, and a few other test accounts so you all have live data to play >> > > with. on the timescale of weeks (to potentially a month or two), we'll >> > roll >> > > this out to everybody. >> >> > > of course, if there are any questions, just feel free to direct them to >> > > @twitterapi! >> >> > > -- >> > > Raffi Krikorian >> > > Twitter Platform Teamhttp://twitter.com/raffi >> >> -- >> Raffi Krikorian >> Twitter Platform Teamhttp://twitter.com/raffi >
