Fission is dedicated to building and improving on decentralized web protocols. Redirect support is an officially accepted improvement for IPFS that makes it easier to host modern web applications.

IPFS-Hosted Websites

Imagine you developed a web application and its files are sitting in a directory on your computer. Once that directory is added to IPFS, the website can be viewed by pointing your web browser at an IPFS Web Gateway that has the content. You can even map a DNS record to the site via the magic of DNSLink, thus giving users of your site a normal web experience. This has served IPFS users well for some time. In fact, this blog is hosted on IPFS in a similar manner.

However, there are some opportunities for improvement.

What happens when the URL a user types in fails to resolve?

For example, https://fission.codes/bad-url (at the time of this writing) returns the following IPFS error message:

ipfs resolve -r /ipns/fission.codes/bad-url: no link named "bad-url" under bafybeihxn3jcp7jexlfqb7nun7ygvt5jmd4takomnm2wpqhebicpb7oloi

While the message does tell the user what has gone wrong (“no link named ‘bad-url’”), it doesn’t give any hints on how they can get to where they are trying to go. The text is also very tiny, and IPFS terminology is used in the error message. In short, it’s not a great user experience. It would be nice if we could tell the IPFS Web Gateway to intercept any of these bad URLs and redirect the user to a pretty 404 page.

Now imagine that the web application you developed is a single-page application. Single-page applications typically have a single HTML file that loads up JavaScript code, and then the JavaScript code handles all routing logic, using pushState to change the browser’s URL when navigating to different sections of the app. This works wonderfully, and the URL changes feel nice and snappy, since they do not involve a server request.

But what happens if the user reloads the page from one of these new URLs? Since these new URLs don’t correspond to any path in your web application’s files in IPFS, once again the user will receive a confusing IPFS error about missing links.

Introducing Redirect Support

Justin Johnson, a Protocol Engineer at Fission, has helped solve these problems by adding Redirect File support to IPFS. Let’s walk through how to use it together.

First, you’ll create a file called _redirects and store it at the top level of the web app. This file will contain redirect rules, telling the IPFS Web Gateway that if a URL doesn’t resolve to any content in IPFS, it should redirect to the specified path instead.

For example, the following line tells the Gateway to intercept any missing path and redirect to /pretty-404 instead.

/* /pretty-404 404

For the single-page application example, the following line tells the Gateway to intercept missing paths and treat them as rewrite rules, letting the single HTML file and the JavaScript it loads handle all of the routing.

/* /index.html 200

For more information on Redirects support, see the official docs.

IPFS Specs and Improvement Proposals

As IPFS has become more popular, there has become a need for more IPFS implementations to exist. For example, number zero is building Iroh, an IPFS implementation written in Rust that can run on phones and other memory constrained devices.

In order for these implementations to interoperate, there needs to be a clear definition of what it means to be an IPFS implementation, and that definition takes the form of specs. The IPFS community is currently in the process of filling in missing specs, and has also introduced a lightweight improvement process, where anyone can submit an InterPlanetary Improvement Proposal (IPIP) along with corresponding spec changes.

The first approved IPIP was the definition of the IPIP process itself, and we are so excited to share that the first approved IPIP that actually improves IPFS is Fission’s _redirects File Support on Web Gateways, along with the Kubo implementation.

Stay up to date on all of Fission's projects by joining our Discord server.