ux: detect local trustless gw and default to it

[lidel]

Right now, the app default to a single public gateway at trustless-gateway.link

This ok, but makes perf. testing tied to remote backend which is provided on best-effort basis.

Suggested improvement

Default to local gateway, if present

Probe well-known localhost URL for presence of trustless gateway, and prepend it to the list.

A good test is http://127.0.0.1:8080/ipfs/bafkqablimvwgy3y?format=raw and confirming the response is hello bytes and Content-Type: application/vnd.ipld.raw.

An easy win for IPFS Camp, we should probe for 8080/8081 (kubo/desktop).
We could also probe 8090 (rainbow).

This is a first step towards adding resiliency.
In the future, we could do similar probing for gateways from https://ipfs.github.io/public-gateway-checker/ but focusing on localhost detection is a priority atm.

This way, service-worker-gateway would have a path to be fully independent of public infra for block retrieval if the user has IPFS Desktop installed.

Optional sidequest: enable /routing/v1 in IPFS Desktop by default

Similar, we could expose /routing/v1 from Kubo in the next version of IPFS Desktop, and service-worker-gateway that confirmed local gateway exists, could then probe if /routing/v1 exists.

The caveat here is that this should be used in addition to the public one because Kubo will filter out peers it can't use (so no /http ones for now), limiting its utility to bitswap over wss and webtransport.

[2color]

Based on testing on the SW Gateway deployed to both localhost and inbrowser.dev, it seems that the Chrome blocks requests to localhost in a service worker. It seems that localhost is not treated as secure context when the request originates from a service worker.

@lidel also tried setting the local gateway in the config of inbrowser.dev on Firefox and saw the same behaviour, i.e. requests to localhost from the service worker are blocked (and not showing up).

Next step: set up a simple reproduction to demonstrate that requests from a service worker to localhost are blocked to ensure that it's not related to our set up

[lidel]

Triage notes based on slack discussion:

• allowLocal and allowInsecure settings (code) are the underlying reason (both false by default)
  • sidenote: filled allowInsecure: false should respect Secure Contexts helia#564
• a quick fix on the ipfs/service-worker-gateway side, to unblock IPFS Camp demo use case, we set both to true for now if a localhost gateway URL is provided in the config

[lidel]

Descoping from Camp milestone due to limtied utility (see Brave issue in #303 (review)).