You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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
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 ishello
bytes andContent-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) and8090
(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 defaultSimilar, 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.The text was updated successfully, but these errors were encountered: