ipfs in web apps guide #1970
ipfs in web apps guide #1970
Conversation
|
|
||
| - Using the [`Verified Fetch`](https://www.npmjs.com/package/@helia/verified-fetch) library, which was modelled after the `fetch` API and returns `Response` objects, with the main difference being that it allows you to fetch data by CID, abstracting away the details of content routing, transports and retrieval. For more examples and background see the [release blog post](https://blog.ipfs.tech/verified-fetch/). | ||
| - Using the [`helia`](https://github.com/ipfs/helia/) library, which is the foundation for the `verified-fetch` library, and provides a more comprehensive and modular API for interacting with the IPFS network, beyond just retrieval. | ||
| - Using public recursive gateways, e.g. `ipfs.io` with HTTP. This is not recommended for most use cases, because it forgoes the verifiability and trustlessness enabled by content addressing. Granted, it might be the easiest way to retrieve data in a web application, but is also the most fraught with security and centralization concerns. |
There was a problem hiding this comment.
Do we want to mention that our goal is to push away from public backend infrastructure like this and that we aim more toward trustless gateways?
There was a problem hiding this comment.
We should link to the gateways page which is pretty up to date with these nuances. Also are you refering to trustless gateway providers or just recursive trustless gateways?
There was a problem hiding this comment.
Our team goals include moving away from recursive trustless gateways AFAIK, but we will probably always run a trustless gateway provider. I'd have to defer to Lidel/Adin for a 5-10-year plan. We don't need to mention it if it's that far ahead.
My main point was that, besides informing the readers that it's not recommended, we should also indicate that we are "tightening our purse strings" regarding hosting those services.
There was a problem hiding this comment.
I agree completely. Just not sure if this belongs here. This information about the general shift applies to a lot of content in the docs, so maybe worthy of it's own section in the gateways page.
Co-authored-by: Russell Dempsey <[email protected]>
Co-authored-by: Russell Dempsey <[email protected]>
|
Nice! Definitely prefer the "on the web" nomenclature to "in the browser", as if "the browser" was a homogenous thing rather than a collection of semi-incompatible runtimes. |
Co-authored-by: Alex Potsides <[email protected]>
* origin/main: (24 commits) Revert "edit problematic file" fix: use offical action now that pr has been merged edit problematic file fix: use forked langauge tool action ci: review prs with languagetool chore: bump versions in installation docs (#1958) Update docs/how-to/gateway-troubleshooting.md add blockchain to list of accepted words fix vale error add reprovide to accepted words correct dht expiration time for records correct dht expiration time and improve ipns docs fix: update pinning services Update merkle-dag.md fix: formatting Update docs/concepts/ipfs-implementations.md chore: use current-ipfs-version fix: lint docs: docker container limits change helia language to TS ...
There was a problem hiding this comment.
💭 we should avoid breaking links (https://www.w3.org/Provider/Style/URI).
@2color mind adding /how-to/browser-tools-frameworks/ /docs/how-to/ipfs-in-web-apps/ to docs/.vuepress/redirects 🙏 ?
What's in this PR