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
