Re: [twitter-dev] Re: t.co?
You can learn about what t.co is and what it is used for by visiting http://t.co . That page has a summary description and links to a help article with more detailed information. Best, @themattharris On Jun 5, 2011, at 14:02, Tim Meadowcroft meer...@gmail.com wrote: The point of t.co, as I understand it, is twitter's very different dynamic with regards to spam. Consider a scenario: someone creates a new account, sends one message with @mentions of 5 high profile people, almost no text, but an http ref (perhaps wrapped behind a shortener, maybe not). In the world of email, this would skew towards a spam rating, in the twitter world this may be someone in an oppressed regime getting a desperate message out - twitter's vision is to facilitate such messages without leaving the door open to abuse. So rather than block the message (unlike email, this is close-to-real-time) they wrap the href in a t.co reference that THEY control and publish the message. If the real link turns out to be spam or malice or gratuitous nonsense, they can, at any point after publishing the message, simply redirect the t.co reference they've allocated, otherwise they leave it in place. When you look at t.co from this point of view, I believe it makes sense - you may or may not agree with the technique but I believe it's not some kind of land-grab for complete control, but quite a smart and considered approach to the trade-offs inherent in their service. There are interviews with their spam people that explain this in more detail if you search for them -- T -- 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 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] Re: t.co?
The point of t.co, as I understand it, is twitter's very different dynamic with regards to spam. Consider a scenario: someone creates a new account, sends one message with @mentions of 5 high profile people, almost no text, but an http ref (perhaps wrapped behind a shortener, maybe not). In the world of email, this would skew towards a spam rating, in the twitter world this may be someone in an oppressed regime getting a desperate message out - twitter's vision is to facilitate such messages without leaving the door open to abuse. So rather than block the message (unlike email, this is close-to-real-time) they wrap the href in a t.co reference that THEY control and publish the message. If the real link turns out to be spam or malice or gratuitous nonsense, they can, at any point after publishing the message, simply redirect the t.co reference they've allocated, otherwise they leave it in place. When you look at t.co from this point of view, I believe it makes sense - you may or may not agree with the technique but I believe it's not some kind of land-grab for complete control, but quite a smart and considered approach to the trade-offs inherent in their service. There are interviews with their spam people that explain this in more detail if you search for them -- T -- 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] Re: t.co question
Does anyone have an update from the Twitter team on when t.co will make its way into messages sent via API calls? On Oct 16, 7:01 pm, DaveH d...@idreia.com wrote: What are the plans to implement the automaticallyt.courl 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] Re: t.co question
And to ask a related url shortening question that I posed last week and has not been answered ... x.co/xyz was automatically detected as a URL link two weeks with newtwitter, but abruptly stopped working, forcing use of http:// or www. prefix to be prepended again. Can this feature be brought back? Mark -- 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] Re: t.co link wrapping and the new 140 characters...
Personally I feed the 140 should be whatever we send totally ignoring the t.co factor otherwise it'll confuse end users and look like apps are broken Still waiting for someone from Twitter to talk about hownthe 140 will work since they reannounced it the other day On Sep 3, 9:02 pm, StuFF mc m...@stuffmc.com wrote: I just want this to be confirmed by @raffi If I understand correctlyhttp://groups.google.com/group/twitter-api-announce/browse_thread/thr... 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 ahttp://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] Re: t.co link wrapping and the new 140 characters...
Users don't know / don't care about the 140 char limit. If an app allows them to send more than 140, they'll not thing it's a big deal. Twitter can simply communicate that any URL will count for 20 characters, and so, for ex., a tweet could contain 6 veeery long URLs, that would still fit in 140 chars. Not 7, we need spaces between those t.co's ;-) What I really love in the idea of t.co is that we'll display real URLs, and the only way to do it is to not count those real URLs as part of the tweet length. People (myself included) don't really like to see a bit.ly link - ever asked yourself what bit could mean for, for example, a french speaking grand'pa - they won't necessary click on the link coming from the grand son... ;) Anyways, Rich, I got your point, we need it to be clear from Twitter, but I think we should wait another week or two. ps: Congrats to the API team, good things coming lately. Cheers. On Sep 4, 10:14 am, Rich rhyl...@gmail.com wrote: Personally I feed the 140 should be whatever we send totally ignoring the t.co factor otherwise it'll confuse end users and look like apps are broken Still waiting for someone from Twitter to talk about hownthe 140 will work since they reannounced it the other day On Sep 3, 9:02 pm, StuFF mc m...@stuffmc.com wrote: I just want this to be confirmed by @raffi If I understand correctlyhttp://groups.google.com/group/twitter-api-announce/browse_thread/thr... 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 ahttp://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] Re: t.co Rollout
Please Twitter can you give us an update on how character counts will work Personally the only way I see it making sense is if it's still 140 for us and you change it after. Users will not understand when a character count wildly jumps when typing and will assume the app is broken. Also you've decided to change the users tweet and so surely the character count should reflect the users tweet itself? On Sep 2, 5:41 am, M. Edward (Ed) Borasky zn...@borasky- research.net wrote: My recollection is that the character count question was discussed on this list, but I don't remember the number. -- M. Edward (Ed) Boraskyhttp://borasky-research.nethttp://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] Re: t.co Rollout
I don't know the answer to the first few items, but I'm guessing that the URLs will be unwrapped to whatever was originally submitted to Twitter (i.e. whatever's currently shown when using the REST API timelines with ?include_entities=true in the parameters) -N -- @nikf On Sep 2, 4:34 am, M. Edward (Ed) Borasky zn...@borasky- research.net 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 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) Boraskyhttp://borasky-research.nethttp://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] Re: t.co Rollout
Different question on the same email that states that Twitter will start tracking every t.co click, whether on twitter.com or a Twitter app. Does anyone know if Twitter will update their API to allow us to get the Twitter Update ID that referred a particular click? Thanks, Boaz On Sep 1, 8:34 pm, M. Edward (Ed) Borasky zn...@borasky- research.net wrote: I just got an email from Twitter about oAuth andt.co. Given that I have about five accounts, I assume I will get more copies. ;-) Anyhow, in the section ont.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 tot.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 viat.co, will the unwrapped display unwrap just thet.copiece, or will it go all the way down to the raw URL? -- M. Edward (Ed) Boraskyhttp://borasky-research.nethttp://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] Re: t.co Rollout
Yeah my point is that clients when posting shouldn't have to be aware of this wrapping. As far as posting is concerned, what the client says is 140 characters is 140 characters. If Twitter decides to change the number of characters after posting, then that's their issue, it shouldn't be the client's issue. I really only need to give one reason for this, user's are stupid. If you have your character counter at 50 chars left and then all of a sudden it changes but your character display shows something else, they won't understand and will simply complain the app is broken. I believe all t.co links are 20 characters. -jonathan -- 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] Re: t.co Rollout
Are there any plans to include include_entities to the search api as we can't parse these unless it is included, and also means clients can't show proper links when using the search api -- 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] Re: t.co mixed messages
Hi Taylor, So is it correct to assume that my users will no longer be able to advertise their webpage links through a direct appearance of that link in their tweets (i.e. http://www.mygreatwebsite.com), because this new initiative will always obfuscate the link within a t.co wrapper? In fact, is it true that the only way the original link would be displayed in a tweet is if the client Twitter app viewing the tweet took advantage of the entities information provided with the tweet and converted the t.co link back to the original link prior to displaying the tweet (something my app has no control over)? Just my opinion, but I don't think Twitter should alter the content of their clients' tweets. How can Twitter know for sure that the alteration will be harmless to the original intended meaning of the tweet? What if, as a joke, a user wanted to include in their tweet the phrase www.whatthehell.com? Twitter would convert that into a t.co wrapper that goes no where, and destroy the meaning of the tweet in the process? I can appreciate why Twitter wants to be in the click loop for embedded URLs, but can you think about it some more and perhaps come up with a less intrusive way of do it? Ron On Jun 10, 9:44 am, Taylor Singletary taylorsinglet...@twitter.com wrote: While it's true that some details are still being worked out, the following is the intention: a) You post the linkhttp://f.ws/tcowithin 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 yourhttp://f.ws/tcolink 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...be wrapped as http://t.co/DRo0trjfor 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
[twitter-dev] Re: t.co Is cool, and I might have an issue with it anyway.
Oh, I know it... that's why a Sitemap.xml, ROBOTS.TXT and offering an OEmbed endpoint on your sites is a really good idea. Seehttp://oembed.com/ for the use of the latter. What's their business model? What do they sell to whom? OEmbed.com is the place where the standard is spelled out... e.g. what you should provide as a web developer if you want to encourage embedding and/or reduce crawling loads. As such, there's no business model (for them), but some website owner might have one that incentives you to use the standard. There is also a service that provides OEmbed data for tons of sites already, my favorite being http://api.embed.ly/ I have no idea what their business model is, but they have a wicked-cool service. Marc
[twitter-dev] Re: t.co issue -- querying for original url in streaming search apis
I would love to see twitter include the original unwrapped url in a key/value in the annotation field (else otherwise it's own specific key/value in the payload). There are loads of use cases for this: from search/discovery through to reducing latency for twitter clients that want to show the original url to the user (now potentially a two-stage task if url is original - bit.ly - t.co) B On Jun 9, 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.cochanges go live. Thanks guys... Jim Gilliamhttp://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
