Option to redirect IPFS-like paths to public IPFS gataway

[lockedshadow]

I consider IPFS Companion not only as good companion for those who already running an IPFS node, but also as companion for those who only "taste" what IPFS is. It should show to curious users a bit of permanence that IPFS is provided, isn't it?

Currently, some of redirection that IPFS Companion performed is...

• IPFS-like paths to local IPFS gateway;
• ipfs://, ipns://, dweb:/ipfs and dweb:/ipns to local or public gateway (experimentally).

But not IPFS-like paths to public IPFS gateway, even if local gateway is disabled. So it would be great to also have an option to redirect IPFS-like paths to public gateway, if local gateway isn't enabled. If someone has copied a link to some public gateway, and after that this gateway disappeared, then this link as a whole becomes broken, isn't it? But with this option that link could be seamlessly redirected to operating gateway, even for those who not (yet?) running it's own node.

[lidel]

Error recovery is a valid use case for having this type of redirect, I created #640 for tracking that separately, thank you for the idea!

@lockedshadow Was that the only reason you proposed this feature? If not, I'd appreciate some additional use cases.

Right now I am not sure if we want to redirect everything to a single public gateway by default when user has no local IPFS node, as it removes value added by having a federation of multiple public gateways hosted by different orgs and re-centralizes entire endeavor.

[lockedshadow]

@lidel You're right, is not the only reason. Some other reasons is...

• Ensure that data with the same CIDs is actually the same across all gateways. It may be considered as form of empirical evidence of IPFS capabilities.
• Those who not (yet) running local node eventually could want to change one default public gateway to another, and also seamlessly rewrite all new and saved links. Even if public gateway is still alive, there may be other reasons for prefer another one: insufficient performance, network connectivity issues...
• Conceptual reason: public gateway URL has a "transport" and "value" part, but only "value" part is... valuable in long-term. Therefore, it should be possible to arbitrary redirect the "value" part to any another "transport" not only by manually concatenation "transport" and "value" part, but also automatically.
• Testing reason: one may want to testing performance of certain public gateways. A context menu item would be useful for this. Something like "Open this link via default public gateway".

Of course, redirect everything to a single public gateway shouldn't be enabled by default — exactly by reasons that you mentioned. But option to enable redirect would be useful in cases listed above.

(Perhaps it also makes sense to put a link to public gateway checker to the addon settings?)

[lidel]

Thanks! Some notes below.

Ensure that data with the same CIDs is actually the same across all gateways.

Yeah, gateway operator has the power to return something else and without hashing the payload (the exact same way CID was generated) user is unable to tell anything mailicious happened. HTTP Gateway Validator is tracked in #593 but it won't work on Chromium any time soon (missing APIs), so "always redirecting to a trusted public gateway" could be the next best thing security-wise.

Those who not (yet) running local node eventually could want to change one default public gateway to another, and also seamlessly rewrite all new and saved links.

Ok this makes sense, especially bookmarks etc. UX is painful, but it is possible get this type of redirect working today, you just need to follow instructions from #588

We will make this easier to set up as a part of mew UI for Backend Control: #491

[lockedshadow]

Thank you for clarification! Perhaps I should have read the whole of issues more carefully...

Yeah, gateway operator has the power to return something else and without hashing the payload (the exact same way CID was generated) user is unable to tell anything mailicious happened.

Security reasons is also very significant (and should be treated as another reason), but this reason is not even about security, but about... initial experience of curious users who are trying IPFS at first time. For those who are accustomed to current state of web, concept of "content addressing" (which may be considered as one of fundamental conception of IPFS) may not be very clear. Therefore, it's may be important for those users to make sure yourself that physically location is really doesn't matter in IPFS — by loading the same CID from various public gateways with help of IPFS Companion.

In other words, this particular reason is not about everyday use, but about... initiation of new users. Seems like it also makes sense during transition period...

[lidel]

If someone has copied a link to some public gateway, and after that this gateway disappeared, then this link as a whole becomes broken, isn't it?

Update: IPFS Companion will now recover on HTTP and network errors (#640), it is enabled by default:

What remains to be done is a better UI that enables user to redirect to a public gateway of their choice (instead of local one).

[jessicaschilling]

Closing this issue due to "Default Public Gateway" and "Recover Failed HTTP Requests" settings in Companion taking care of a lot of this user story. Let's open more specific issues for any other efforts as needed. Thanks!