Iāve been trying to get my website on IPFS. I tried almost two years ago, and it looks like some things have gotten better in the meantime. However, the same thing that didnāt make sense before still doesnāt make sense.
Like most websites - like, for example, this forum - my website (macwright.org) uses absolute links. Hopefully it goes without saying that absolute links are very useful, and that changing them to relative links is not at all an easy workaround.
Unfortunately, given the way that the localhost:8080 gateway works, and the ipfs.io gateway, absolute links donāt work. If you try to rehost a website using them onto IPFS, all the absolute links will yank out the /ipfs/... or /ipns/... bit of the URL and replace it with just the linked path.
It looks like ipfs.io itself uses relative links, probably to work around this limitation. I canāt find anything in the documentation about IPFS for websites about this problem.
Any ideas? This is limitation breaks most most websites, so even if it isnāt fixable, it should probably be mentioned in the documentation so that similar folks donāt go through steps 1-9 just to get blocked by step 10.
Iām not sure if this is related to your concerns, but I think the long term goal for this is for there to be native support for IPFS built into browsers. In the meantime, you can link to /ipfs/... and /ipns/... paths using a trusted gateway (e.g.,https://ipfs.io/ipfs/..., another one, or even one you run). If the user has an IPFS browser plugin installed it can redirect it to a local gateway the user is running.
Thereās a bunch of discussion on this here (link is to a summary post)
Is there a reason sites like yours canāt use relative links to link to other parts of the same site? Iāll admit that absolute links are useful for linking to external resources, but using relative links within a site should be transparent to users.
If youāre talking about absolute links to within the same site, I donāt think it goes without saying why absolute links are very useful for that use case. Iād be curious to hear what absolute links offer that relative links donāt for linking within the same website.
I suppose it depends on what tools youāre using, but static site generators like Hugo make using relative links trivial.
Iād be curious to hear what absolute links offer that relative links donāt for linking within the same website.
Sure, so letās say that youāre using Jekyll. You write a post. People read that post both on the front page (/) and some permalink (/2019/04/01/hi.html). From that post, you link to some other post.
Do you link with ../../../foo.html, because you expect it to be accessed from the permalink, or do you omit all the backtracking, because you expect it to be from the front page? This is the essence, essentially: when youāre writing your content, you donāt know where it is.
This idea extends to resources. The post has some CSS dependency. Does the <link> element reference ../../../? Or not? This is why pretty much all the websites on the internet use paths with /. Hit up boingboing, or metafilter, or kottke, or wherever: they all use absolute links that start with either the full path, or /.
Hopefully this makes it a bit clearer why requiring relative URLs is a problem. I could write a bunch of code to rewrite all the URLs on my site to point to each other, but when I write a post about how I made my website work on IPFS and how you can too, I canāt say with a straight face that itās reasonable if it requires that kind of hack.
So, thereās some good news: we will be moving to putting the CID/IPNS-key/HASH in a subdomain by default (so every site gets its own origin). That is, websites will be hosted from https://HASH.ipfs.dweb.link/... instead of https://ipfs.io/ipfs/HASH/.... The nice side effect is that absolute links will ājust workā.
Unfortunately, itāll still likely be a few months before this lands.
Great, glad that thereās a solution coming down the line. Q: that looks like itās going to be a change to the web gateway ā is there potentially a way for absolute links to work with the āpure IPFSā approach ā not sure about the name, but the way that you access sites via localhost:8080 when running the local gateway. While itās great that the web gateway exists for certain usecases, using it by default seems to defeat the purpose of a decentralized system.
For anyone using the browser companion, the browser companion will proxy requests to the gateway through the local gateway. The local gateway can then intercept and handle these requests on the external gatewayās behalf.
Eventually, the plan is to (once browsers add proper support for custom protocols) support ipfs://Qm.../... and ipns://.
(note: some operating systems can also handle subdomain.localhost)
Yes, I agree. All this github server side rubbish is for geeks and people with too much time to faf about. Whats the easy fix for relative urls? Thats all we need. Cheers.
If you need relative URLs, just use a subdomain gateway, like this: Address IPFS on the Web | IPFS Docs, therefore you will be able to use relative links to the root. It might not work everywhere but there is no better solution yet.