Hacker News Reader

Looking at the ID format in the first example, I have to recommend against including the protocol ("https:") in a key/ID. This makes it hard for people to later upgrade from HTTP to HTTPS, because it breaks all of those references. It also makes it hard to try out new protocols side by side, like IPFS.

View on HN

A URL always includes the scheme. `http://www.example.com/1/ ` and `https://www.example.com/1/` could represent different content. If you want to change the scheme but keep the old links working, you need to redirect from the old to the new.

That is the definition of a URL, but not a law of nature. If these keys would be more useful with the scheme being implicit, then perhaps they shouldn't be URLs.

> This makes it hard for people to later upgrade from HTTP to HTTPS, because it breaks all of those references.

While someone else pointed out the rest of the URL could conceivably point to different content, in practice, it seems like most deployments have a 1:1 correspondence and will redirect from http://(.) to https://(.) when SSL is deployed so this is not so critical for the http(s) case imho..

Reply on news.ycombinator.com