Keep IPFS URIs?

[jbenet]

Is it possible to keep the IPFS urls instead of redirecting to gateway? i.e. proxy the request in the extension to the local gateway so url bar remains the same.

[lidel]

Depends.

Is your intent
A) to keep original HTTP URL such as
https://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D
while content is in fact loaded from IPFS when custom gateway is enabled?
B) to see canonical
fs:/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D
in the address bar no matter which gateway is used?

For the latter, there is a related PR in the works (#35, cc @the8472 ) that adds a setting to always use fs:/ipfs/.. in the address bar while a public or custom IPFS gateway is used over HTTP in the background.

I am not sure if similar is possible for original http: addresses. This kind of orchestration is based on a custom protocol handler (fs:) and a handler for http: is provided by the browser itself and I suspect we can't change it via safe APIs (the ones that will not get deprecated in 12-18 months).

[jbenet]

I want it so that if i enter fs:/ipfs/... i use the local gateway but the url stays the same (fs:/ipfs/...). (whether it should stay the same or change to https://ipfs.io/ipfs/... when using global is arguable)

[Kubuxu]

#35 aims to transform all requests to local gateway to look as fs:/ipfs/... (browser bar will showfs:/ipfs/...`.

I would like to ask if it would be possible to make it so site shows up as http://ipns.kubuxu.ovh but is downloaded from local gateway (A records of ipns.kubuxu.ovh point to public gateway and there is dnslink).

[lidel]

@jbenet Ok, then it sounds like #35 would address this need. I agree with the preference to use fs: only when loading via local gateway (public gateway is just a HTTP website in my mind).

@Kubuxu My plan is to detect dnslink in DNS and automatically redirect to local gateway (#44). If we had both #44 and #35, then opening http://ipns.kubuxu.ovh would redirect to fs:/ipns/ipns.kubuxu.ovh which is quite elegant IMO.

[jbenet]

public gateway is just a HTTP website in my mind

Sort of, i agree with making it clear, but links to https://ipfs.io/ipfs/... are fine to retrieve with ipfs -- i.e. redirected to the local gateway (and canonicalized to fs:).

[lidel]

links to https://ipfs.io/ipfs/... are fine to retrieve with ipfs -- i.e. redirected to the local gateway (and canonicalized to fs:)

Yup, that is the plan for #35: if redirect to IPFS is enabled, redirect IPFS paths (eg. https://ipfs.io/ipfs/* ) to fs: protocol handler (which will be transparently backed by local gateway).

[lidel]

Thanks to @the8472 the addon supports fs: in address bar (#70).
I plan to release it in v1.5.5 as an experimental feature (disabled by default).

I am leaving this issue open until we decide it can be enabled by default in v1.6.0.

[lidel]

v1.5.5 is available for testing 🎉

Remember to enable "native" fs: support in Preferences:

Opening fs:/ipfs/QmYHNYAaYK5hm3ZhZFx5W9H6xydKDGimjdgJMrMSdnctEm will opportunistically use local gateway (with fall-back to the public one if local gateway is offline).

Any feedback is welcome!

[whyrusleeping]

👍 great stuff :)

[Gozala]

I just found this thread as I was trying to get a ipfs protocol handler implementation that would correctly handle origin policies (which as far as I can tell isn't possible without altering firefox codebase in non trivial ways). As of this implementation (I have not checked source) but by the behavior my guess is that protocol handler uses simple-uri component for url creation, which has a drawback of having null origin, although internally whole url.spec is used for origin checks. As a consequence ipfs content linked to won't load at all. For example if you try to load ipfs webui as fs:/ipfs/QmU3o9bvfenhTKhxUakbYrLDnZU7HezAVxPM6Ehjw9Xjqy/ you'll notice that loaded page will look a lot different from http://127.0.0.1:8080/ipfs/QmU3o9bvfenhTKhxUakbYrLDnZU7HezAVxPM6Ehjw9Xjqy/ due to origin policies.

I think you could solve that to some degree by using standard-url component instead, but than you'd have another issue - all the ipfs content would have same fs://ipfs origin which puts you on the other end of the spectrum.

[the8472]

I attempted to implement a prototype for fs:/ URIs with origins, but an XPCOM feature it would have relied on was broken by e10s. See #71

[lidel]

Closing this issue as Legacy SDK is deprecated by Mozilla (#20).

For WebExtension status see #165: Support Custom Protocols in WebExtension or open a new one.