At the IPFS 0.5 Launch Meetup, a demo showed the attendees IPFS gateways with the hash as a subdomain, a new feature which should soon be implemented on the official ifps.io gateway.
And I’m super stoked about it.
This is seriously going to make my life way easier and will simplify the global transition from Web 2 to Web 3.
In this post, I’ll explain to you why.
Path Gateways and Why I Dislike them
Currently, urls to IPFS gateways are formatted with the hash in the url as a path. In other words, they look like this: gateway/ipfs/HASH
For example, look at this url to an IFPS gateway point to the current hash for codeclimbing.com:gateway.ipfs.io/ipfs/QmPfrjn4yKTR6b7ueR97ytzky2EYma1tiXm3x4b2Tv6ZF4/
My beef with path gateways is that they require website owners to make additional configurations when migrating a traditional website to IPFS.
Let’s list a few problems someone might encounter when trying to host a site on IPFS.
The first issue is with loading static assets.
The file located at the address will be an index.html file. The browser will start by loading this file. Then, this index.html will ask for javascript and css files alongside other static assets, such as icons and images.
When navigating traditional sites, these files will be located relative to the site’s domain. So when going on codeclimbing.com the index.html will be fetched at codeclimbing.com and the static assets will be fetched RELATIVE to the domain such as codeclimbing.com/static/assets.... This is perfectly fine, of course, but what happens when the user is accessing the site through an IPFS gateway?
The browser will fetch the static assets relative to the url of the gateway. For example, it will start searching for assets at gateway.ipfs.io/static/assets... which is completely wrong, because the correct url should be relative to the index.html file which is asking for those assets. The correct url should look like gateway.ipfs.ip/ipfs/HASH/static/assets...
The second problem comes from routing from SPAs such as pages using React, Vue or other frameworks.
Again, the problem is that SPAs (Single Page Applications) will create their paths relative to the domain and not take into account the gateway’s path url.
And there’s a third problem too which is with using local storage, because the local storage is attached to the gateway’s domain, not the website. Which mean the local storage is shared through all sites that use that gateway.
Yeah, that’s super weird…
The Solution: Subdomain Gateways
The problems described above can be fixed with additional configuration. Loading static assets can be fixed using relative urls, the problem with SPAs can be fixes by using hash routing and the problem with local storage can be fixed by using a state container such as Redux.
But we shouldn’t have to do this. It would be so much better if users could put their websites on IPFS and simply have it work without having to figure out why their website isn’t working. This slows down adoption of IPFS.
And that’s where subdomain gateways come in.
Subdomain gateways have the ipfs hash as a subdomain.
For example, the url would look like this: HASH.gateway/
The consequence? No more hashes in the path!!
If a website worked on a certain domain the user can simply migrate his website AS IF and it will simply work! No problem with static assets, SPAs or anything else.
A cool feature demoed at the meetup, consisted in converting path gateways to subdomain gateways by default. So all the problems above will all go away. Very cool!
Coming Soon!
I’m not sure when this feature will be implemented on the ipfs.io gateways, but I’m super stoked about it.
Not only it will make my life way easier since I often have to deal with sites on IPFS, but I believe it will accelerate the global adoption of IFPS.