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
{{ message }}
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.
IPFS SW should use local IPFS node on the system and transparently fallback to in-browser IPFS node when local node isn't available.
Overview
I am working towards makeing in-browser IPFS exposed through SW compatible with a REST API exposed by local IPFS daemon / gateway. For more details see ipfs/in-web-browsers#137
There is already code in place that binds API endpoints to IPFS API calls, but it's not available in browser dist and there is an assumption about running in nodejs using hapi.
Proposal
I would like to propose to factor out API endpoint binding code into separate lib or maybe just bundle and in a way that would remove node / hapi assumptions, such that would allow us to share that codebase across SW and nodejs contexts.
The text was updated successfully, but these errors were encountered:
There is obvious overlap with #1820, it maybe that just expanding it's context would make more sense than having this as separate issue. However it was fairly easy to address issue pointed out there using https://github.com/ipfs/js-ipfs-http-response but dealing with Daemon REST API continues to be quite painful due to larger API surface.
There should be no dependencies on Hapi in this tree but it does use joi for validation and boom for creating http friendly error messages.
So, in that sense if we just extracted src/http to a seperate module as-is, you could share it without further work if you built an adapter to map whatever request system you're using to them.
Please feel to reopen with any comments by 2023-06-02. We will do a final pass on reopened issues afterwards (see #4336).
This issue will most likely be handled as we improve on Helia, but marking as "wontfix" for now for the sake of analyzing any of these js-ipfs deprecation issues.
Type:
Feature
Severity:
Medium
Description:
TL;DR
IPFS SW should use local IPFS node on the system and transparently fallback to in-browser IPFS node when local node isn't available.
Overview
I am working towards makeing in-browser IPFS exposed through SW compatible with a REST API exposed by local IPFS daemon / gateway. For more details see ipfs/in-web-browsers#137
There is already code in place that binds API endpoints to IPFS API calls, but it's not available in browser dist and there is an assumption about running in nodejs using hapi.
Proposal
I would like to propose to factor out API endpoint binding code into separate lib or maybe just bundle and in a way that would remove node / hapi assumptions, such that would allow us to share that codebase across SW and nodejs contexts.
The text was updated successfully, but these errors were encountered: