feature request: redirects

[Mithgol]

This is a feature request that is not related to a specific implementation (such as go-ipfs) but proposes a feature for IPFS as a whole. Therefore it goes to the main repository (unless I've misunderstood something).

The proposed feature is the following: IPFS API (both CLI and REST) should have a way to store in IPFS (obtaining a hash, an IPFS URL, etc.) a resource which is not a file, but a redirect to the given URL.

When opening that resource by a web browser, any IPFS gate (such as a local gate at localhost::8080, or the default gateway gateway.ipfs.io, or any other) must redirect the browser to the given URL, using 302 Found (or, optionally, 301 Moved Permanently) as its HTTP response status code.

I believe that feature can have a couple of useful applications.

[Mithgol]

Application example 1: link shortening.

Some resources in the current Web, such as https://www.pscp.tv/w/bMxHOTF6dktOV3hyWnFKamV8MWRSS1pidm9ham9LQhXx9Qj62IcZYgbApwWVmZH3h1QBQAJcp2KzxQp153I_ or https://tjournal.ru/61535-issledovanie-raznica-v-oplate-truda-muzhchin-i-zhenshchin-uvelichilas-vpervye-s-2006-goda-i-ne-ischeznet-eshche-217-let or https://video.twimg.com/ext_tw_video/926154571898028033/pu/vid/1280x720/zH5jPOGKhksO8PxJ.mp4 for example, have relatively long URLs (106 and 145 and 92 characters in this example).

Such length makes their use difficult in some applications. Examples:

• GitHub will truncate the first line of any commit message (making an URL unclickable) if the line exceeds 70 characters (unless the message is displayed on that commit's own page).

• SMS messages size is 160 7-bit characters, or 140 8-bit characters, or 70 16-bit characters (longer SMS are sent as several messages, usually at least doubling the price). Internet messaging sometimes impose similar limits (for example, it's not possible to use more than 100 characters in a reaction message in Twitter's Periscope).

• Some console applications (such as Fidonet echomail editors) are likely to have the default width of 80 characters (and IBM 80-column punched card format, designed in 1928, seems to be the historical cause for that), forcing long URLs to wrap (and sometimes failing to open them).

• Following the same IBM-inspired standard, most source code linters are used to limit the code lines' lengths around 80 characters using the corresponding options (such as JSHint's maxlen or ESLint's max-len; the latter even has the default of 80 for lines of code and comments). Using longer URLs brings you warnings.

Some services try to mitigate that obstacle by allowing some URL shortening based on guesswork (for example, you can guess and shorten https://tjournal.ru/61535-issledovanie-raznica-v-oplate-truda-muzhchin-i-zhenshchin-uvelichilas-vpervye-s-2006-goda-i-ne-ischeznet-eshche-217-let to https://tjournal.ru/61535- without hindering its performance).

Some services are running their own short domain and a dedicated hosting of short URLs (for example, http://www.animenewsnetwork.cc/news/2017-11-03/pokemon-the-movie-i-choose-you-film-latest-video-features-new-take-on-classic-english-theme-song/.123585 has a shorter equivalent http://4NN.cx/.123585 available via the button “SHORT URL”).

Some services just don't care, and their users usually have to find and use a reliable URL shortener service for themselves (such as https://goo.gl/ or http://bit.ly/ or http://tinyurl.com/ or https://is.gd/ for example). It introduces yet another point where link rot happens when a shortener is closed or banned or censored.

IPFS could (by supporting redirects) act as an URL shortener: while its URLs (such as https://ipfs.io/ipfs/QmT3fT1CtH3hWqXdkQW6iqCWgRttfpN9u8RbzwKHAv9Wky for example) are 67 characters long, they still are shorter than most of the limits imposed on URLs.

[Mithgol]

Application example 2: web-based dynamic part of an otherwise static site.

Until pubsub or IPFS POST make everyone happy, an IPFS-hosted web site is likely to remain mostly static and to reference its dynamic (changing) parts, hosted elsewhere.

That “elsewhere” might change in the future (because of the usual reasons behind any link rot: moving to a difference service, domain name change, paywalling, censorship, etc.), but that “reference” is only useful if it remains static on the static site.

Therefore that “reference” is likely to have the nature of an IPNS-hosted redirect to its current target.

(If an HTML page is expected as that target, a JavaScript that changes window.location is likely to suffice even now; however, for non-HTML types of content, an HTTP redirect is very desireable in the future.)

[Mithgol]

Application example 3: BitTorrent.

A fan of P2P-based file exchange wants to have an IPNS-hosted redirect to its favourite BitTorrent tracker (subject to change in IPNS if the tracker closes or otherwise misbehaves). It would allow the IPNS name to reside in that fan's torrents' infohashes permanently (the infohashes won't have to be rewritten, and the torrents reseeded, even if the tracker is changed: the only change of an IPNS-hosted redirect would suffice).

This application intends to circumvent a specific problem of BitTorrent-based P2P: a new tracker means a new infohash and thus effectively a new torrent to be reseeded (which is usually a 無駄 to be avoided if possible).

[Stebalien]

This is an interesting idea and would definitely be useful however, it runs counter to the philosophy of IPFS. IPFS is designed such that links never break (in theory, at least). If we were to build-in support for linking to URLs (location-based links) directly from IPFS, we'd lose this property. As such, we're unlikely to implement something like this.

Note: You can technically already do this (for browsers) with meta redirects however, in general, you probably shouldn't.

Application example 3: BitTorrent.

At that point, why not just use IPFS for the content? If users already need IPFS to resolve the tracker, they might as well just fetch the file over IPFS.

[MaxLaumeister]

I also want to see IPFS support 301 redirects.

The vast majority of the web is comprised of web pages that change from time to time, and while IPFS has immutability at its heart, IPNS is a layer that's proven very useful for mutable content.

I'd like IPFS to get to the point where I can host my website on it and have all the first-class features I currently get with my web host, including 301 and 302 redirects and custom 404/410 pages

From my understanding, HTTP status codes are not really integrated with IPFS since it's a separate protocol, but I think it would be useful to have a compatibility layer. The more compatible IPFS is with HTTP, the faster it will be integrated into the rest of the web, and the faster we'll start seeing native IPFS links in search engine results and from the rest of the older HTTP web.

Right now I could use CloudFlare's bridge to host my .com domain on IPFS, but I would have to use meta refresh redirects to redirect users from old links, and make do with CloudFlare's stock 404 page.

By allowing IPNS entries to redirect visitors in an unambiguous, 301-like way, IPFS gets to have its cake and eat it too. The choice of whether to link a mutable IPNS resource or an immutable IPFS resource becomes the choice of the end-user. This way, IPFS keeps data available while still allowing content curation.

[saurik]

I agree with @MaxLaumeister that this is essentially a blocking issue for a lot of "port existing web page to IPFS" attempts. I don't understand the status of this in "ipfs" vs. this other issue in "go-ipfs"? https://github.com/ipfs/go-ipfs/issues/7392