IPFS Extension API

[cypt4]

IPFS Extension API is needed for content-posting extensions: At first we need some method that allows to start local node, so extension can communicate with the IPFS network using RPC calls. As follow-up we can provide some proxy interface that mirrors Kubo API, to allow using other IPFS client implementations under the hood.

[diracdeltas]

is this just for one extension or will any extension have access?

[yrliou]

@diracdeltas This came up during IPFS bi-weekly meeting, it should be just for whitelist extensions if we move on with this. I think we're still in some planning phases that we would need to define the use cases clearly and evaluating if the extension API is the best way to go before moving on to one solution.

[ikreymer]

Great to see this being discussed again. We (Webrecorder) use IPFS in the ArchiveWeb.page extension in Brave to allow storing web archives to the local IPFS node.

• Per previous discussions, we add the ipfs permission to the extension, which provides access to the chrome.ipfs API, which contains {getIPFSEnabled: ƒ, getResolveMethodType: ƒ, resolveIPFSURI: ƒ}. However, these APIs are especially useful at this point.
• To be able to write to the local node, we current check for navigator.brave.isBrave() and then simply port scan localhost ports that Brave uses for IPFS (45001, 45002, 45003, 45004, 45005) to see if we can connect to the kubo API.
• As this is protected by CORS headers, also use the chrome.webRequest API to override the Origin to bypass CORS.
• After data is written to the IPFS, we provide an ipfs:// as well as gateway links that users can then click and load.

The above process is far from ideal, and a far less hacky approach to writing to IPFS would be very welcome. I know there's the Writable Gateway work that is underway, and that could be one solution. Until that is ready, perhaps some kind of proxy URL that could provide direct access to the kubo API via something like brave://local-ipfs-node/ ? That would allow us to avoid this really hacky solution.

Other thoughts / related issues:

• It is not currently possible to do await fetch("ipfs://...") from any origin (this will simply fail). This might be a nice way to be able to support read access. I suppose if the brave://local-ipfs-node/ was a valid proxy, then it could work with reading as well.
• Being able to start the node if it isn't yet on would be good as well (I think currently only the IPFS Companion has access to that API)

Non-Extension Considerations:

• I don't know if providing non-extensions access to IPFS is on the radar, that's certainly more risky and probably should tie in to the Permissions API and would also need to consider storage quotas. Maybe this is out of scope for that for now... It would be great to solve this for extensions first!

[lidel]

Investing time into exposing Kubo-specific RPC is a bit risky.

Exposing chrome.ipfs.executeRpcCall(method, args) is fine for internal things like Brave Wallet, or IPFS Companion, but exposing it to third-party ones like Webrecorder is a slippery slope: it is not future-proof, will lead to feature creep, people asking to safelist more and more, and either we will make a bad call at some point, or will lock ourselves out of supporting alternative implementations (such as Iron in Rust), or have to maintain glue code that translates Kubo RPC to Iroh gRPC.

Instead, we should focus on real user needs and dedicated methods. afaik the only needs safelisted extensions should have addressed are:

• read-only
  • start/stop/status IPFS daemon
  • read/set preferred way of resolving ipfs:// and ipns://
  • read/toggle automatic redirect to local gateway
• writing/publishing
  • onboarding data to IPFS to get a CID and have local node provide it to other peers (incl. MFS/pinning)

For read-only path, there is no need for extension to know what is the port of local gateway – it should only learn that ipfs:// is supported (or have ability to enable it), and use that. await fetch("ipfs://...") working seamlessly is what we want.

For writing/publishing, we should not expose specific methods of Kubo RPC to the web platform. Instead, we should follow Gateway pattern and use implementation/vendor-agnostic interface. FYSA:

• I will be submitting IPIP this quarter to make POST possible on gateways. When it is finalized and implemented in Kubo, Brave will be able to grant access to it via await fetch("ipfs://...", {method: 'post'}).
• Access to MFS over local gateway is also planned, with intention to provide intuitive pinning management via fetch API and things like WebDAV.
• :point_right: The general idea is that we don't want to expose Kubo RPC to third-party extensions that can request it viaipfs permission api. Our endgame is switching to Rust implementation embedded in Chromium itself, and if we design Web API around fetch and ipfs:// URIs, then no breaking change will be required, because we leaked no Kubo-specific RPCs

:point_right: That being said, if brave://local-kubo-rpc/ proxy is easy to implement and solves write-via-Kubo-RPC needs raised by @ikreymer, that is also an acceptable step-gap for now. It does not leak much, just removes need for CORS-hacking and port-sniffing. chrome.ipfs.executeRpcCall is also acceptable, but only for internal extensions.

[lidel]

FYSA I've filled https://github.com/brave/brave-browser/issues/31199 for privileged APIs for IPFS Companion. I did not reuse this issue because this one is about less privileged APIs that extensions like Webrecorder could use.

[cypt4]

https://github.com/brave/brave-browser/issues/31012

[vadimstruts]

The IPFS local node and scheme has been deprecated