I see this very similar to IPv4 and IPv6, and adoption. Non content addressable URL addressing simply is "good enough" for most use cases, and bittorrent is "good enough" for serving content durably and somewhat in a content addressable manner (file hashes, magnet torrents, immutable torrents). Do we need IPFS URLs? It doesn't appear so, it seems like a solution seeking a problem. IPFS gateways will always be a target for abuse and copyright claims as well.

If you want to reference resources securely, https://developer.mozilla.org/en-US/docs/Web/Security/Defens... is available and widely supported.

▲

rhodey 7 hours ago | parent | next [-]

I think something like IPFS is definitely needed. There is nothing stopping you from distributing a webapp on bittorrent but you'll also need to add a README for instructions on how to run the webapp on localhost so a browser can render it. So thats not something that any non-technical user wants to do.

▲

fc417fc802 3 hours ago | parent | next [-]

Arguably that's a browser shortcoming that applies equally to IPFS (as well as all the other "alternative" internet protocols). (But yes I realize IPFS is a much better fit for the purpose when you dig into the details.)

▲

toomuchtodo 7 hours ago | parent | prev | next [-]

Can you share potential webapp use cases that would rely on IPFS or using IPFS for referencing resources would be an improvement? Perhaps my mental has gaps on this topic, and my thoughts and assertions could be incorrect.

	▲	rhodey 7 hours ago \| parent [-]
		The arguments for "reproducible builds" are strong and so think reproducible builds but for something that can be loaded in the browser. Browser is a big deal because its a sandbox also. For example Signal could be a webapp if we had content addressable hashing and it would be sandboxed.

▲

stackghost 7 hours ago | parent | prev [-]

Content-addressable storage as a whole is a non-starter with non-technical users.

▲

chriswarbo 7 hours ago | parent [-]

I don't understand. Billions of non-technical users are loading URLs like `https://cdn.foo/?guid=deadbeefdeadbeefdeadbeef` all the time. Why would they care if those URLs became `ipfs://deadbeefdeadbeefdeadbeef` instead?

▲

stackghost 33 minutes ago | parent | next [-]

The number of normies visiting urls directly from a CDN is a rounding error.

Non technical users like pronounceable domain names. It's why we aren't just using IP addresses.

CAS is intimidating to non-technical types.

	▲	chriswarbo 13 minutes ago \| parent [-]
		Pronounceable names can point to a content address, the same way they can point to an IP address. For example, https://dnslink.dev points a DNS name to a content address; git refs point to git objects; etc.

▲

6 hours ago | parent | prev [-]

[deleted]

▲

somat 3 hours ago | parent | prev | next [-]

My go to example: IPFS is Plan9 to bittorrent's UNIX. Some achingly beautiful design, willingness to completely disregard existing messy conventions(for example: The ipfs unified url format) and, like you said, still not enough better for people to want to change.

▲

rhodey 7 hours ago | parent | prev [-]

Oh and sorry I missed your comment on "Subresource Integrity".

The deal here is Subresource Integrity will only help you if the index.html is considered trusted/authoritative. So you still need a way to get index.html to users and users need a way to say "is this the true index.html"