Hacker News Reader

Comment by tkaemming | Hacker News Reader

What would happen when those messages are delivered to a user's phone via SMS? There's still a nontrival amount of users having status updates/direct messages delivered to their mobile phones that probably wouldn't appreciate a message with a 50+ character URL (or the URL being stripped, effecting message integrity).

View on HN

They could apply URL shortening to a tweet when delivering over SMS, if necessary.

Or they could apply URL canonicalization to tweets delivered any other way: follow all the 302s until they get the actual page, then replace with those URLs instead. (Actually, the best approach would be to canonicalize the URL on its way in, and then shorten with a single, known URL shortener on the way out, if sending via SMS. This would stop the "shortener wars" in its tracks, which is probably a good thing, because each shortener that dies leaves dangling links in its wake.)

and then shorten with a single, known URL shortener on the way out

Which should be Twitter's own built-in shortener.

What happens when something in the middle redirects infinitely, is slow, or is down? Does the tweet have to wait until canonicalization to show up? How long are people willing to wait? Is it acceptable to not be able to link to a site unless it's up?

As OpenID implementors have noticed, these issues cannot simply be ignored. Making an untrusted HTTP request is tricky business.

The nice thing about tweeting (and most tweet clients) is that you expect people to be linking to a site they just visited, not a random URL they typed from memory. (As long as the client says "checking links..." with a little spinner beside each URL getting replaced with a check or an X, I don't think users will mind waiting.) Also, "when something in the middle redirects infinitely", sharing that link would be malicious on the part of the poster, so it's okay to make them wait for some sort of time-out.

However, if you want to eat your cake and have it too, you can just change "canonicalize then shorten for SMS" to "always shorten, first pointing the shortened URL at the original URL, then asynchronously updating the shortened URL's target to the canonicalized URL, once the canonicalizing daemon has processed it."

Why would the users need to have a URL over SMS though? Couldn't it just say 'link?' Then the user could view the tweet later through another interface to get the actual URL.

Some people in this world gone mad use SMS for twitter, and have a browser right there on their phone! :)

I guess my thought was that if you had a browser you wouldn't use SMS, but a Twitter app or the web interface.

Reply on news.ycombinator.com