Do not lose information about HTTP provider if https:// URL is pasted

[agmap]

When fetching content with an IPFS gateway URL (https://{gateway-URL}/ipfs/{CID}/{optional path to resource}) I would like this gateway URL to be automatically appended to the end of the recursive fallback gateway list. This way I can retrieve the content if all other direct retrievals and inbrowser.link fail.
It is justifiable because the new gateway is created by the user URL input.

The same would also be desirable in helia-verified-fetch.

[2color]

This seems to overlap a bit with the idea of dynamically encoded providers: ipfs/helia-verified-fetch#242

[agmap]

More to the background.
Many NFTs and DID URLs have URI with IFPS gateway URL and not in neutral format ipfs://{CID}.
To fetch the URI of the NFT I just take the NFT URI and pass it in service worker gateway or using helia-verfied-fetch which fetch the content verifiable and trustless directly from the providers.
Sometimes its not possible to fetch the content, but is available on the gateway of the NFT URI, which is not in the default fallback recursive gateway list.

Alternatively when helia fetch fails, I could fetch the content using the NFT URI without using helia-verified-fetch or add this gateway in the list of recursive gateway. But this always need action to be done.
But I would really like, it automatically loads in service worker gateway and helia-verfied-fetch, without adding parameters or changing the IPFS URL, ....
I don't know if that PR, you mentioned, helps in that case.

It was just an idea of mine. If it doesn't make sense, then please feel free to close this request so that everything doesn't overflow.

[SgtPooki]

That makes sense, I think this issue has merit on it's own based on your use case

[lidel]

Triage note:

• @agmap could you elaborate on the UX you expect?
  • Where are you entering https://{gateway-URL}/ipfs/{CID}/{optional path to resource} ? Into input at https://inbrowser.link ?

    

  • Is your expectation that when you do that the gateway-URL is "added automatically to this list" (in practice, we dont want to do it permanently, but just for the retrieval session context related to the root cid -- in practice the same, due to origin isolation, but noting to be formally correct)?

    

• Ask to not lose information about "one potential working HTTP provider" when passing HTTP gateway URLs tro verified-fetch is sensible, but probably should happen in https://github.com/ipfs/helia-verified-fetch

Right now, we are unsure what is the ask here.

[agmap]

Yes,
when I enter a direct gateway url like
https://gateway.pinata.cloud/ipfs/bafybeidfmcgmrpfrfpmrx7swrwlon7ul4bqv4k6hoaedqotdu22psni5ae

The gateway should automatically temporary added to the Recursive Gateways List for loading the CID. (not permanently, only for the season for loading this CID)

This way, the CID is loaded even if the CID is not announced on IPNI or IPNI has an outage.

The same should be internally done by helia/verified-fetch. When I pass a gateway url the gateway should also automatically used in gateways for fetching the CID. (The gateway should also not permanently added, only for the season for loading this CID)

import { createVerifiedFetch } from '@helia/verified-fetch'

const fetch = await createVerifiedFetch({
  gateways: ['https://trustless-gateway.link', 'https://gateway.pinata.cloud' ],
  routers: ['http://delegated-ipfs.dev']
})

const resp = await fetch('https://gateway.pinata.cloud/ipfs/bafybeidfmcgmrpfrfpmrx7swrwlon7ul4bqv4k6hoaedqotdu22psni5ae')

const json = await resp.json()

[achingbrain]

@lidel given the position in ipfs/specs#504 (comment) is this something we still want to do? It seems like scenario B to me.

[lidel]

This feels orthogonal to that IPIP. What is done here is pasting normal gateway URL on landing of https://inbrowser.link, and appending the gateway from the URL to the list of fallback trustless gateways I guess?

Feels like nice to have optimization, by not P2, more like P3 if we ever have too much time on our hands?