Specify APIs for interaction between browser & IPFS

[flyingzumwalt]

@lgierth

another important thing to deliver (crosscutting the user stories) is a list of concrete features and APIs that we need to make this better

Background

@Gozala:

What else ? How should these APIs look like ? What restrictions should browser pose in regards to these APIs ? Quotas like indexedDB ? Disallow reads across origins (across hashes ?) ? Should there be a form of CORS for IPFS content ?

@Gozala:

I expect this to be a question with in first top 10 you’d be asked by browser vendors as long as you aim or “dweb apps”. if IPFS is a more positioned as distribution network of static files than that becomes less relevant.

In a separate conversation thread:
@jbenet

• For now, They can use js-ipfs to have a full ipfs node directly in the browser, or js-ipfs-api to use those APIs.

@Gozala

That sort of means "dweb apps" get unlimited power to read / write content, which I doubt is going to fly.

@jbenet

• We want to come up with a nice set of APIs to be provided by {addon, extension, webextensions} that js-ipfs and js-ipfs-api can cleanly polyfill, so adoption can just improve over time.
• Native APIs are the long-term goal.

@Gozala

I expect browser vendors to be more interested what APIs need to be exposed to allow “dweb apps”, implementation details are less important.

[lidel]

If it helps, this is a short list if "IPFS things" that are used in ipfs-firefox-addon:

• checking if URL is IPFS resource (is-ipfs)
• checking if IPFS resource is pinned (js-ipfs-api – ipfs.pin.ls|add|rm)
• fetching node metadata (js-ipfs-api) There is a potential room for improvement: right now addon downloads full peer list, as we are lacking API that returns simple 'peer count'.
• uploading file/URL to IPFS (js-ipfs-api: ipfs.util.addFromURL(url, callback))
• (experimental, slow and disabled by default) checking if FQDN has dnslink in in its DNS record (manual request to /api/v0/dns/ -- js-ipfs-api does not support it, see details in Support for /api/v0/dns/ ipfs-inactive/js-ipfs-http-client#501)

Apart form that, we need WebExtension API for handling custom protocol (ipfs/ipfs-companion#164)

Separate area of interest can be summarized as "exposing subset of IPFS APIs as window.ipfs" on every webpage. There was a discussion in ipfs-inactive/js-ipfs-http-client#387 and ipfs/ipfs-companion#37, but the consensus seems to be that it is not safe without some kind of access-control (eg. via Tokens: ipfs/kubo#1532).

[lidel]

Update: there is a proposal for adding DNS-related API to WebExtension API. I've added suggestion to include querying for TXT records (so that dnslink can be detected natively by the browser):

• https://bugzilla.mozilla.org/show_bug.cgi?id=1343849#c2

[ghost]

Continued in #35