Expose some information to JS in the site

[Kubuxu]

Possibly in collaboration with chrome addon, expose some useful data to sites wanting to use more of IPFS:

• is (web+)fs:/ handled - for rewriting or local protocol handlers
• js-ipfs-api
  some more?

EDIT: changed after discussion

[the8472]

the latter two may expose local network information, i would consider those security-sensitive.

[Kubuxu]

They might but some apps require user to provide them and it would be nice if user could set them once.

Maybe make them in form if getter and ask user for permission.

[the8472]

it would be good to understand the use-cases for API use. maybe it could be translated to HTTP verbs instead so the javascript doesn't need to know about the particular gateway.

Gateways should be an invisible implementation detail in my opinion.

[Kubuxu]

There are various use cases for API, really everything that requires more than showing static site. Forums, pastebins, pinmanagers and so on.

For gateway, yes, it should be transparent but there might be cases when it would be useful.

Gateway address might not be critical for IPFS Web development but API access is.

[the8472]

directly exposing js-ipfs-api might make more sense, if it's possible to hide the gateway.

but there might be cases when it would be useful.

I don't think "might be useful" is a good argument to expose private information by default.

[Kubuxu]

With incoming Token API, ipfs/kubo#1532, it might be harder but if tokens were added to the js-ipfs-api with this in mind it will be possible (on solution would be allowing to create multiple sub-APIs with different tokens, so if there is no token you use default and if there is you can choose to use your own token).

Gateway address might be useful if I would like to create link for you to download things form in external application but I can live without it.

[lidel]

For discussion about web+fs:<hash> see #36.

As for providing access to local API:

We don't have any real life use cases for this. I agree it might be useful, but it is hard to design anything without real life needs/constraints.

Just to move discussion forward: let's say we initialize document.ipfsAPI object with js-ipfs-api on IPFS pages after user explicitly accepted the risk (via some kind of permission confirmation dialog).
Right now API access is unlimited and someone could remove all my pinned items. A big red light.

We need to wait until something like Token API is available and revisit this idea then.

[the8472]

I think an important question is which subset of the API would be safe to use for untrusted content without any opt-in or authentication.

I mean any website can at least XHR POST to its own origin, modulo adblockers&co disabling that. So at least ipfs-add and the 0.4.0 pipes might make some sense? Or like I mentioned above maybe those should be mapped to HTTP/WebDAV verbs (post/put/patch/move/...)

But that's probably a question that should be answered in the context of ipfs/api

[Kubuxu]

I agree that we should wait for Token API to come up.

Use cases for local API are already there: http://ipfs.ydns.eu/ipns/boards.ydns.eu/ (custom gateway as it is 0.4). Any application, not static way that wants to run on IPFS will have to use API.

[lidel]

Closing → this discussion continues at ipfs/in-web-browsers#9