4 ms·

This issue boils down to "absolute links don't work". See here: https://discuss.ipfs.io/t/how-do-absolute-links-work/5267/3 https://discuss.ipfs.io/t/how-do-abs

This issue boils down to "absolute links don't work". See here: https://discuss.ipfs.io/t/how-do-absolute-links-work/5267/3 https://discuss.ipfs.io/t/how-do-absolute-links-work/5267/3. > 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/.. https://HASH.ipfs.dweb.link/... instead of https://ipfs.io/ipfs/HASH/... https://ipfs.io/ipfs/HASH/.... The nice side effect is that absolute links will “just work”. So every IPFS website is going to be https://HASH.ipfs.dweb.link/ https://HASH.ipfs.dweb.link/? I like that I can stick with the familiar dat://kickscondor.com. And it works today.

AgentME 7y ago
>So every IPFS website is going to be https://HASH.ipfs.dweb.link/ https://HASH.ipfs.dweb.link/? If someone sets up an IPFS DNSLink record for their domain, then it's just accessible directly from their domain. The user goes to https://example.com https://example.com, and if they have a normal browser, they fetch it as normal, and if they have the ipfs extension, they fetch it over ipfs instead. (There is also support for https://hash.ipfs.dweb.link/ https://hash.ipfs.dweb.link/, but as I said, I don't think that's what people should give to users if they can avoid it. Though that does have the nice benefit over dat:// links in that it works for normal browsers even if your web server goes down.)