You can also instantly search for dupes. Keep the hashes in a database and just check before accepting the submission.

(This has always been an idea I was thinking about; nice to see it implemented)

it wouldn't work: dynamic content. even comment counters below posts would change the hash.

Actually, you can run it through an article scraper, then hash it.

it wouldn't be 'entire website content'

include dynamic content via javascript

Clever use. But do you think it would scale? Doesn't it rely on bit.ly and/or hashify.me being able to convert the URL into a readable page?

I am missing something. How is this dramatically different from passing around the data: URIs ?

data:text/html;charset=utf-8,However,%20data%20URI%20does%20the%20same%20without%20the%20server.

Here is a self-containing cached document, for simple texts probably with a better efficiency than base64.

EDIT: ah. The shorteners barf if you try to "shorten" the data URIs

Actually tinyurl will shorten it but your browser may not allow the redirect. Chrome throws up an error page for security reasons: http://tinyurl.com/3maue6t

Ha, nice - I tried only goo.gl and bit.ly

With http://preview.tinyurl.com/3maue6t it works, btw.

Though, tinyurl still barfs when I try to shorten the data URI that http://software.hixie.ch/utilities/cgi/data/data gave to me when I let it grab the index of HN.

I assume hashify.me stores the value associated with the hash.

I guess for this to work well. Dont you need Hashify to provider a service where you pass in hashcode and it returns the HTML to you.

You just wrap the call with good old JSONP and you are good to go.

> I assume hashify.me stores the value associated with the hash.

Not so. hashify.me has no server-side component (beyond nginx serving three static files). _bit.ly_ kindly provides the hash table. ;)

I tried to make a self-referencing page, but you need to be able to generate the hash of the page url that includes its own hash...

Not having the time to do so, I leave the challenge here: http://bit.ly/ialoWI

That's not possible because the base 64 encoding is longer than the plaintext. There are 4 characters of text in the URL for every 3 characters of text entered.

If you're willing to jump through hoops and js-compress your content, you can deal with this issue, unless your compressor uses something like crc. That way, you can grow the plaintext faster than the b64 - though you'd still need to do clever things with the url.

That's essentially what you're doing when you are trying to mine Bitcoin :)

until you jumped the api limit :D why not hot swap any shortner?

bit.ly is the only URL shortening service to support cross-origin resource sharing, as far as I'm aware.

The _right_ thing to do would be to build a shortening service designed to handle URLs of arbitrary length. I'm not sure that I'm willing to take on that responsibility, though.

Especially if used in conjunction with a text-extraction API such as Alchemy: http://www.alchemyapi.com/api/text/

That way you only get the text of the page, stored in a cache.