-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow web apps to request pin of files or even a general permission to pin. #981
Comments
This comment has been minimized.
This comment has been minimized.
This sounds related to a wider discussion about node reuse and resource sharing on the web (ipfs/in-web-browsers#158), but I'll focus on "exposing IPFS API on web pages" below. On past experimentsWe did some
As noted in #589 (comment):
If we bring something like this back, and expect web developers to use it, it must be future-proof, so would have to be a dedicated API independent of js-ipfs. Opportunity to explore native APIs in browsers like BraveSomething we could explore is exposing some sort of Personally I believe in "no API is the best API" mantra, so instead of having const { cid } = await fetch('ipfs://cid', { method: 'POST' }), body: data).json() This is just an idea, but we may start experimenting with this type of "no library" approach on HTTP Gateways soon (protocol/web3-dev-team#1). On user agencyMy main worry around is that user agency is often glossed over behind "there should be popup and user will decide" and web3 users are essentially living in Microsoft Windows UAC hell where they are blindly trained to accept every access control popup and at the end of the day there is a decrease of security because the burden of opsec was shifted onto user who has limited decision-making budget every day. Ideally there should be no popup unless a permanent persistence is required, and things should be automatically sandboxed for each origin based on Origin and Referer headers. Figuring out the details in a way that does not compromise privacy by enabling "supercookies" is the biggest challenge here. Gathering feedback@felixniemeyer Is The list usually starts with "I want I'd like to understand most common use cases better and design user journey end-to end, and then think about developer apis. For example, what is the value of local pinning if the user closes the laptop and both nodes disappear? Can we improve setup of remote pinning service so no API key copying is necessary, and it feels more like granting oauth2 permission (ipfs/pinning-services-api-spec#34)? etc I'd love to hear your thought on this (and don't feel constrained by existing APIs, lmk what "ideal" world would look like) 🙏 |
I'm in a similar boat but with a more complex use case. I have built a web-app that can do live streaming on IPFS. It require access to a IPFS node with; Currently in brave using the fetch API is equivalent to Security is a big concern but also privacy. How do we prevent website from snooping around for specific CIDs on the user's node or how to prevent website from running malicious code fetched from ipfs. Baseline for me is no user interaction required, unfortunately we're far from that at the moment. I wish I knew more about browser and web stuff so that I could help... |
Is your feature request related to a problem? Please describe.
I'm writing a web app which stores user data (e.g. text articles) on ipfs. Therefore I'm running a local ipfs-js node in the web app. But when the user closes the tab, the browser ipfs node shuts down and added files are barely accessible.
From the web app code I would like to ask the ipfs companion to add a certain content (by cid or arraybuffer) to the local ipfs node.
Describe the solution you'd like
I imagine ipfs companion could provide an ipfsCompanion object into the JS scope similarly like Metamask provides the web3 context.
I could then do
ipfsCompanion.add(cid)
. ipfs companion would ask the user - "hey, this web app wants to pin that (size: xx kB)" and then add it upon user confirmation. Ipfs companion may even ask the the user "do you want to permit apps from < host > to add files to your local ipfs node in general?". If the user consents, future add requests would be permitted automatically.The ipfs companion could expose the full ipfs js api to web apps this way.
I also thought about the ipfs pinning API (I'm not very familiar with it) but maybe that's enough for the ipfs companion to expose for now.
If this is in scope of the ipfs companion extension I could help with development.
The text was updated successfully, but these errors were encountered: