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.
There was a problem hiding this comment.
Agree there is need to communicate "listen, gateways may disappear st some point, look at Cloudflare one not being a thing anymore, don't build things on sand". But it is out of scope here, work for future PR.
Virtually all pages that touch gateways needs to be redone, we have too many pages with partial and often outdated info (created before https://specs.ipfs.tech/http-gateways/ existed).
Co-authored-by: Russell Dempsey <1173416+SgtPooki@users.noreply.github.com>
Co-authored-by: Russell Dempsey <1173416+SgtPooki@users.noreply.github.com>
|
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 <alex@achingbrain.net>
* 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 ...
proto.school is not future-proof, better point at glossary
lidel
force-pushed
the
ipfs-web
branch
4 times, most recently
from
61307e1 to
ac888a8
Compare
dont validate links if they dont include slash (fixed youtube embedds)
What's in this PR