feat: customize ipns dnsResolvers

[SgtPooki]

Title

feat(verified-fetch): customize ipns dnsResolvers

Description

Adds the ability to customize dns resolvers to verified-fetch.

Users should then be able to add custom doh resolvers to helia-service-worker-gateway as mentioned at ipfs/service-worker-gateway#22

Notes & open questions

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if necessary (this includes comments as well)
• I have added tests that prove my fix is effective or that my feature works

[SgtPooki]

self review

[SgtPooki]

self review. ready for peers

[SgtPooki]

this aggregate error should probably have a length greater than zero 🤔

Looks like we're logging the error, but not returning them:

helia/packages/verified-fetch/src/verified-fetch.ts

Line 314 in 7c07e11

this.log.error('Error walking path %s', path, err)

[achingbrain]

FWIW, AggregateError has really poor DX as the default message logged to the console doesn't include any of the actual errors which can lead to spurious issues being reported and a lot of wasted time.

In other places where there's only one entry in .errors we unwind it to just throw that error instead.

In this case, if there's an error, it should be made available, otherwise no error should be thrown?

[SgtPooki]

Another question here. Do we want to add dnsResolvers to the first object?

to stick to the pattern of "components in first object, options that alter how things work in the second" I think it would make sense in either place.. 🤔

[2color]

I think dnsResolvers are deserving of the same importance as routers which makes the case to move it to the first object.

routers is currently used for IPNS routing (and CID routing in the future). Assuming that we see IPNS and DNSLink as being of equal importance dnsResolvers should live beside routers in my humble opinion.

[2color]

On the other hand, customising dnsResolvers requires importing the constructors for dnsOverHttps and dnsJsonOverHttps which does reduce ergonomics.

[SgtPooki]

it'll still be optional either way, but I think I agree with you.

[achingbrain]

I think maybe in the first argument, keeping the routers/gateways/resolvers together makes sense to me.

The only thing we have in the second arg is contentTypeParser, not 100% on why we have two args right now anyway!

[SgtPooki]

After looking at this for a bit and starting to change both args to a single object, but contentTypeParser has to be in the second obj, or we need to accept a possible .helia option in the first obj, or else users can't pass both a custom Helia & contentTypeParser

[2color]

I just realised we have another problem now. We cannot instantiate @helia/verified-fetch with a custom instance of Helia and also customising dnsResolver.

This came up in the SW Gateway, where we now are faced with a choice:

1. Either we instantiate Helia with the IDBBlockstore in the service worker but have no way to customise the dnsResolvers
2. We customise the dnsResolvers (along with gateways and routers) but cannot use the IDBBlockstore.

This is how they compare:

// option 1
  const helia = await createHeliaHTTP({
    blockstore,
    datastore,
    blockBrokers: [
      trustlessGateway({
        gateways: [...config.gateways, ]
      })
    ],
    routers: [...config.routers, 'https://delegated-ipfs.dev'].map(rUrl => delegatedHTTPRouting(rUrl))
  })

  const verifiedFetch = await createVerifiedFetch(helia, { contentTypeParser })

// ---- OR

// option 2
  const verifiedFetch = await createVerifiedFetch({
    gateways: [...config.gateways, 'https://trustless-gateway.link'],
    routers: [...config.routers, 'https://delegated-ipfs.dev'],
    dnsResolvers: ['https://delegated-ipfs.dev/dns-query'].map(dnsJsonOverHttps)
  }, {
    contentTypeParser
  })

This seems like something we'd want to address. Naively we could move dnsResolvers to the second parameter and frame it as follows: the first config param is to customise Helia or pass a Helia instance, while the second is to customise verified-fetch specific config.

Any thoughts @SgtPooki @achingbrain ?