Should IPFS paths at different gateways share the same ipfs.files chroot? #453
Labels
area/window-ipfs
Issues related to IPFS API exposed on every page
status/deferred
Conscious decision to pause or backlog
topic/security
Work related to security
It gets really interesting when accessing
ipfs.files
viawindow.ipfs
at IPNS site.I've run the snippet above at
/ipns/ipfs.io
and:https://ipfs.io/ipns/ipfs.io/
creates
/dapps/https/ipfs.io/ipns/ipfs.io/test-from-ipfs.io
http://127.0.0.1:8080/ipns/ipfs.io/
creates
/dapps/http/127.0.0.1%3A8080/ipns/ipfs.io/test-from-127.0.0.1:8080
Do we want to merge IPFS scopes (
/ipns/
and/ipfs/
) by removing HTTP component so that both above URLs will have access to the sameipfs.files
root at/dapps/ipns/ipfs.io/
?Pros:
ipfs.files
API and do not worry about the way user loads the dapp, no reports of "missing user data" if someone switches between gatewaysCons:
ipfs.files
via ACL for this new gateway, it still won't work.window.ipfs
is added by the extension, and the same extension automatically detects requests to IPFS Paths and replaces them with requests to either custom or public gateway defined in Preferences. This means malicious JS will never get loaded, as we use 'trusted' gateway instead, even when embedded js-ipfs is used.The text was updated successfully, but these errors were encountered: