docs: example how to enable both HTTP and libp2p at the same time

[lidel]

Extracting from discussions with @aschmahmann

https://github.com/ipfs/helia-verified-fetch/tree/main/packages/verified-fetch#usage-with-customized-helia shows how to configure custom helia with HTTP-only(?) backend.

iiuc /wss bitswap providers discovered over delegated routing API are dead and can't be used for bitswap due to lack of libp2p.

We should have an explicit example which enables both HTTP and bitswap-over-llibp2p backends at the same time, and make it a prominent one, then have HTTP-only after it.

[lidel]

@2color @SgtPooki i feel it could also be me being out of loop for a while, is there a technical reason why we don't have http+libp2p mode, or is it just a matter of docs?

[2color]

No technical reason. We could get one going.

[SgtPooki]

FYI I also recently opened ipfs/helia#638

I don't think there's a technical reason, but I am in favor of adding an example that enables client-only-libp2p for doing bitswap without doing any dht-walking or other work. it should be a pretty simple config honestly, just https://github.com/ipfs/helia/blob/4f14996a9b976f2b60f4c8fe52a4fd1632420749/packages/helia/src/utils/libp2p-defaults.browser.ts#L34 without:

• bootstrap
• dht
• autonat

[2color]

I think we need to find a better way to allow users to customise Helia and libp2p when instantiating VerifiedFetch. By better I mean better than instantiating libp2p and Helia with custom configuration, as we do in the Service Worker. For most developers this approach is too complex and error prone.

Maybe it's also time for us to enable p2p retrieval by default in Verified Fetch.

How to do this today

const helia = await createHelia()
const verifiedFetch = await createVerifiedFetch(helia)

However, with this, you get hundreds of connections due to the bootstrap nodes and the DHT Client. Since Verified Fetch is concerned with retrieval

How can you do this without all the connections

// Create helia without connecting to any bootstrap peers
const helia = await createHelia({
  libp2p: {
    peerDiscovery: [],
  }
})

However, this will still instantiate the DHT service. Another problem is that this will also have all transports enabled, and we know some of them don't work well, e.g. WebTransport.

Path forward

My initial instinct is to handle this in the Verified Fetch constructor by adding additional options similar to the way they are displayed in the SW Gateway (https://inbrowser.link/#/ipfs-sw-config) that will determine whether Helia/http or libp2p helia and which transports. If don’t imagine that most devs will want to customise like we did in the SW Gateway (it’s pretty unruly).

Concretely, I was thinking along the lines of:

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

Lines 648 to 667 in 7bf29f3

	/**
	* Whether to enable WebTransport providers.
	*
	* @default false
	*/
	webSockets?: boolean
	/**
	* Whether to enable WebTransport providers.
	*
	* @default false
	*/
	webTransport?: boolean
	/**
	* Whether to enable WebRTC providers.
	*
	* @default false
	*/
	webRTC?: boolean

I'm exploring the DX around this in #130. Feedback would be appreciated @achingbrain @SgtPooki @lidel

[SgtPooki]

Feedback would be appreciated @achingbrain @SgtPooki @lidel

We chatted about this in Helia WG today and decided that:

1. we should just disable webtransport by default in helia's libp2p defaults: fix: remove webtransport from default transports helia#674
2. we shouldn't modify init options for @helia/verified-fetch in feat: support p2p retrieval by default #130
   • instead just set up verified-fetch with direct retrieval by default and keep using gateways/routers as passed.