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

Reply via email to