Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ux: detect local trustless gw and default to it #299

Open
lidel opened this issue Jun 14, 2024 · 3 comments · May be fixed by #303
Open

ux: detect local trustless gw and default to it #299

lidel opened this issue Jun 14, 2024 · 3 comments · May be fixed by #303
Assignees

Comments

@lidel
Copy link
Member

lidel commented Jun 14, 2024

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 48080 (brave) and 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.

@lidel lidel added this to the IPFS Camp 2024 milestone Jun 14, 2024
@2color 2color self-assigned this Jun 18, 2024
@2color
Copy link
Member

2color commented Jun 18, 2024

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
Copy link
Member Author

lidel commented Jun 19, 2024

Triage notes based on slack discussion:

  • allowLocal and allowInsecure settings (code) are the underlying reason (both false by default)
  • 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

@2color 2color linked a pull request Jun 19, 2024 that will close this issue
3 tasks
@lidel
Copy link
Member Author

lidel commented Jun 28, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment