4 ms·

For the curious, SRI = SubResource Integrity. It’s a hash of the file, and browsers will not use the file if there’s a mismatch: https://developer.mozilla.org/e

For the curious, SRI = SubResource Integrity. It’s a hash of the file, and browsers will not use the file if there’s a mismatch: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... (ps, I dislike the name; you don’t encounter the term “subresource” anywhere else in webdev. It’s a “subresource” of the HTML document resource, eyeroll)

nerdponx 4y ago
If we're baking file hashes into the HTML... is there any work out there that goes the extra mile and uses IPFS as your CDN?
- viraptor 4y ago
  Depends what you mean by that precisely. But you can load things from cloudflare's ipfs gateway without doing anything special otherwise. Directly from ipfs - not without extensions.
  - nybble41 4y ago
    You could include js-ipfs[0] and fetch all your resources from IPFS without going through a gateway. However, this approach would make the site fully dependent on JavaScript. A PWA with a Service Worker could perhaps implement its own client-side "gateway", translating public gateway URLs into direct IPFS access. Without the Service Worker (or without JS) it would fall back to using the gateway. [0] https://js.ipfs.io/ https://js.ipfs.io/
  - nerdponx 4y ago
    Does an HTTP gateway actually allow you to make peer-to-peer IPFS connections, or does the actual content end up being routed through the gateway? And if so, wouldn't that be equivalent to a traditional CDN from the perspective of a client? It sounds like we'd need to have browsers implement IPFS protocol support directly for this to be a feasible alternative to centralized CDNs.