Feature request: Access for client side javascript apps by Permissions API

[jurjendevries]

As developer of distributed javascript client side apps it is currently not possible to read and write to IPFS. This is of course a security feature, but without this it is hard to make a distributed web apps that doesn't relay on servers that have to do some work with nodejs or so. So a solution / feature request for this is to use the browsers Permissions API so that a user can give permission to read and write in at its local browser build in IPFS node.

[lidel]

Dropping some quick thoughts:

• Prior art was window.ipfs experiment, which we deprecated a while ago (https://github.com/ipfs/in-web-browsers/issues/172)
  • requires HTTP API that was designed for browsers (Core JS abstraction over RPC over HTTP at /api/v0/ is not one)
  • requires explicit browser support, which means gateways need to do something else
  • ..longer list of downsides here
• "No API is the best API"
  • Current line of thinking is that basic CRUD operations on IPLD data could be performed by allowing Fetch API (JS) to interact with ipfs:// and ipns:// addresses.
  • read-only or read-write, depending on used method (GET/POST/PATCH)
  • clean fallback to HTTP thanks to gateways
  • Brave does not allow ipfs:// URIs on https:// websites at the moment.
    • Sounds like we have a way to connect the dots here by allowing read-only (or read-write) ipfs:// interaction on https:// websites – it could be done via Permissions API

The above are just quick thoughts, needs focused analysis.

[SionoiS]

Chiming in to say that for my use case (social media) I would need; dag put & get, pubsub sub & pub, name resolve & publish, id, add and cat.

I see 2 path, first, a totally new standard for IPFS in browsers, which I don't think will happen, second, using the fetch API, which seams doable.

The permission API could be used to enable write access.