Seeking feedback on IPFS feature

[John Turpish]

We're working on an effort to better integrate IPFS into Chromium-based browsers.

You can read a basic explainer of the intended feature here:
https://github.com/little-bear-labs/ipfs-chromium/blob/main/doc/explainer.md

I was hoping to reach out for any feedback/thoughts you might have.
Are there concerns we should have in mind before pushing for upstreaming?
What sorts of design decisions might make it more palatable?

The ChromeStatus feature is here: https://chromestatus.com/feature/5105580464668672

[guest271314]

This shouldn't be limited to HTTPS. 

[John Turpish]

Could you elaborate on which other transports/protocols you think should also be supported?

When I write HTTP(s) I'm referring to HTTPS and/or HTTP - we do and shall support both. HTTP is important mostly for the case where you're running your own node, e.g. on localhost.

There is also plan to consider/evaluate the "gateway over libp2p" peers, though I would imagine this isn't what you're discussing?

If you're thinking about the fact that several other transports are supported for the p2p communication between IPFS nodes, with quic being the most popular...
Up to this point we've been pretty explicitly intending not to have the browser participate in BitSwap or any other such custom p2p protocol. The idea has always been to have the browser communicate with gateways. If you want to challenge that, I'm open to hearing your ideas, but it is a much larger conversation.

[guest271314]

file:, chrome-extension:, isolated-app. 

I experiment, test API's, implementations, browsers, JavaScript runtimes and so forth, and might be breaking out of an Isolated Web App's intended sandboxes, in order to use TCPSocket(); using browser extensions to achieve use cases Web API's do not expose; offline testing locally on file: protocol. There one was a quic-transport. Then if I recollect correctly the idea was to not create arbitrary protocols. There there was Direct Sockets in a Progressive Web App. Then Direct Sockets got gated behind Isolated Web App proposal and implementation on Chromium, which effectively requires the code be a SIgned Web Bundle for TCPSocket(), UDPSOcket(), TCPSeverSocket() to be exposed - on isolated-app: protocol. So there's a few moving parts in Chromium; implementers change ideas, define a protocol, undefine a protocol, then define another protocol. Thus, this should be left open, for the user to define which protocol best suit the given use case and requirement, in the given version of Chromium.

[John Turpish]

My focus on HTTP is and has been driven by the fact that every IPFS gateway is an HTTP server and that's always been the case. 

> offline testing locally on file: protocol

Personally, when I've been testing IPFS stuff, I've always had access to 127.0.0.1 and can simply start a node. In the current proof-of-concept it's using SimpleURLLoader (in a quick-n-dirty way)... I suppose a `file:` URL might work there if you set the prefix as your custom gateway list, but I haven't tested it and wonder how the parameters like `?format=` would be handled. Certainly the filesystem wouldn't have the smarts a node would, e.g. that `bafkqaatine` and `mAVUAAmhp` are the same thing.