Open Gozala opened 3 years ago
This sounds sensible, but you may want to update example to use generic path gateway:
- * cid.toURL().href // 'https://bafybeigizayotjo4whdurcq6ge7nrgfyxox7ji7oviesmnvgrnxn3nakni.ipfs.dweb.link/'
+ * cid.toURL(new URL('https://dweb.link')).href // 'https://dweb.link/ipfs/bafybeigizayotjo4whdurcq6ge7nrgfyxox7ji7oviesmnvgrnxn3nakni'
/ipfs/{cid}
path at subdomain gateway is a safer default, as go-ipfs will do additional check and convert CID to subdomain-safe version even if original one is not DNS-safe (docs, https://github.com/ipfs/go-ipfs/pull/7441)I'm not sure about it. To me CID is a concept that is independent of IPFS. Hence I would rather put IPFS-style URL generation into a higher level library. Please consider this comment an opinion and not something blocking this effort.
@vmx, perhaps one of the options could be scheme
, which defaults to ipfs://
to allow you to use any protocol?
There is an ongoing effort to try and reframe "IPFS" to be something other than the go-ipfs and js-ipfs instantiations and decouple it from the current 'IPFS DHT'. It goes something like this (iterating on language from Juan):
IPFS is:
Which then encompasses go-ipfs, js-ipfs, the 'IPFS DHT' gateways, Filecoin and any other stack that uses CIDs to form DAGs with some form of ~p2p.
So when viewed in that lens, this change kind of makes sense landing here. It shouldn't be viewed as "this thing can be fetched from an IPFS gateway because it's in 'the IPFS DHT'". Rather, it should mean "this is an IPFS-style link to something, it can be found in the IPFS stack, but you may need further context to actually locate the block."
There had been various discussions about the fact that in the wild we see IPFS urls to specific gateways. I think we can bake a best practice into CID implementation by adding a method like:
Note that here we reinforce several of the best practices:
ipfs://${cidv1}
is the default that we to see.