TLDR If you use Brave v1.19 the ipfs:// scheme can be used for subresources only if the root document was also loaded from ipfs:// (or ipns://)
This behavior was implemented on purpose.
Mixed-protocol behavior on the web is an uncharted territory and we want to do it right, without introducing unnecessary unknowns on the regular web.
Click here for more context
Note that modern browsers are HTTP-centric and the only cross-protocol behavior that is well understood is http:// vs https:/, with the only difference being TLS wrapper. HTTP-HTTPS cross-protocol requests follow well understood rules and nearly all concerns are guided by the secure context state of each side.
ipfs:// is something new, with different characteristics. It is marked as “secure context” in web browser, you have access to Web APIs as on https:// page, but it is not HTTPS. Thanks to content-addressing user gets integrity verification (which is not present in https://), but then browser asks multiple peers for content (instead a single server).
Together with Brave we decided to not expose ipfs:// on http* documents, and take time to audit, research, and understand potential value and all ramifications first.
great so actual innovative uses of this stuff is still impossible because meh troons shaking in their boots. where can someone just build a normal decent browser that allows us to make web apps that can access cids, as intended, or do you just want to be permanent stagnating in the dark age? seems im going to have to ask my users to enable developer mode
I want my app to have no backend at all, so you can have the html by itself and it works without a central server. Libraries I hear about all seem to be backend. Seems will be fine anyway if the website is itself from ipfs and the user is accessing it on brave as ipfs:// works when the website itself is ipfs://. There will be a taster website which lets users upload local files to see how it works and encourage them to switch to brave and ipfs full version