ipfs:// everywhere #93
Conversation
There was a problem hiding this comment.
I am ok with adding support for https://${gateway}/ipfs://${CIDv1} notation on gateways as a cheap way of improving UX, but it should be a convenience redirect to a URL following an existing path or subdomain convention:
https://${gateway}/ipfs://${CIDv1}
→ https://${gateway}/ipfs/${CIDv1}
→ https://${CIDv1}.ipfs.${gateway}
We can't make it a canonical notation because its not compatible with subdomain root requirement (details below)
| > Above examples from 2nd to 5th could redirect to: | ||
| > `ipfs://${originHash(CID)}.dweb.link/ipfs://${CIDv1}/` |
There was a problem hiding this comment.
No cigar. Subdomains are how we want people to load websites because content root is aligned with URL root.
Adding this artificial path prefix breaks that alignment and breaks relative paths on every website :(
There was a problem hiding this comment.
No cigar. Subdomains are how we want people to load websites because content root is aligned with URL root.
My understanding is we want to make sure that content is origin isolated based on CID. We can accomplish that without teaching people how to translate CIDs into origins etc... It is a lot easier to teach programs like gateways to do that, for humans we could just keep ipfs://${CIDv1}/ regardless of (sub)domain. That gives us:
- Origin base content separation we seek.
- We retain same path in form of
ipfs://${CIDv1}across all gateways. Reinforcing that${bridge}in${bridge}ipfs://${CIDv1}is just a bridge toipfs://${CIDv1}.
Adding this artificial path prefix breaks that alignment and breaks relative paths on every website :(
You mean sites that use /images/cat.png would be broken ? That is a fare point, although I think something that we can overcome by redirecting to /ipfs://{CIDv1}/images/cat.png based on referrer.
Also would not those sites be as broken when loaded from https://ipfs.io/ipfs/${CIDv1} now ?
There was a problem hiding this comment.
Correct. We spent years fixing bugs in various static website generators to support truly relative paths, and it remained a big adoption blocker because there was always a new bug for something new filled.
Only when subdomain gateways got introduced, and the CID root became the root of URL path, all websites and tools started working out-of-the-box with IPFS.
👉 Redirects are transparent in browser context, so your fix will work for a subset of problems like loading images or other assets, but it won't fix websites that execute JS code based on window.location.pathname 💔
Due to this I don't believe this is feasible (creates more problems than it solves).
The best we could do, is to start returning ipfs:// URIs in Link header: ipfs/in-web-browsers#179
There was a problem hiding this comment.
👉 Redirects are transparent in browser context, so your fix will work for a subset of problems like loading images or other assets, but it won't fix websites that execute JS code based on
window.location.pathname💔
That historical context is really helpful! Do you by a chance have a pointers to above JS problems, so it could be quantified and pros and cons could be evaluated.
I realize this is an unfortunate tradeoff. Then I also think that turning ipfs://{cid}/path/file into https:///${cid}.gateway.tld/path/file is a cause of why later form is more prominent. I also believe that later form makes it really difficult for an average person to realize that gateway could be swapped.
Maybe there is a compromise, that make better tradeoffs ?
What I was suggesting here it should do following instead: The whole point here is that domain stuff, is for programs like browsers to do a the right thing and should be meaningless for humans. As for humans they can ignore that stuff in domain and always see |
Co-authored-by: Marcin Rataj <[email protected]>
No description provided.