Comments (10)
the latter two may expose local network information, i would consider those security-sensitive.
from ipfs-companion.
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.
from ipfs-companion.
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.
from ipfs-companion.
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.
from ipfs-companion.
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.
from ipfs-companion.
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.
from ipfs-companion.
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.
from ipfs-companion.
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
from ipfs-companion.
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.
from ipfs-companion.
Closing → this discussion continues at ipfs/in-web-browsers#9
from ipfs-companion.
Related Issues (20)
- [MV3 Beta Bug] Recovery Redirect Loop HOT 1
- [MV3 Beta Bugs] browserAction updates broken in Firefox HOT 1
- [MV3 Beta Bugs] Invalid "Target" in Redirect Rules UI
- [MV3 Beta Bugs] Single catch-all rule per subdomain gateway HOT 4
- Refactor E2E tests
- Brave: synchronize settings when backend is "Provided by Brave" HOT 1
- Intro screen cleanup
- [MV3 Beta Bug] Redirect infinite loop with Brave when hitting "purple IPFS button" HOT 4
- [Epic] Helia Node Type HOT 2
- the IPFS companion is disabled even with Kubo is running HOT 19
- #x-ipfs-companion-no-redirect opt-out does not work in 3.0.0
- e2e Tests are broken HOT 1
- Disable Brave redirect when Companion global redirect is enabled HOT 3
- Optional injection into page context menu HOT 2
- feat: upgrade countly sdk HOT 2
- test: re-enable firefox tests in e2e
- Migrate publishing setup to ipfs.tech HOT 2
- / \ ~~~°•Fibonacci •°~~~ ↕️ / \ HOT 2
- Remove countly.ipfs.tech telemetry
- ipfs://example.com in Chromium should produce error
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ipfs-companion.