JS IPFS fallback #310
JS IPFS fallback #310
Conversation
There was a problem hiding this comment.
Thank you, looks exciting!
Some things to address before merging:
-
We should have a checkbox on the Preferences screen that disables this fallback
-
Browser action popup looks confusing. It kinda suggests that the user is using node at
ipfs.io. Perhaps we should explicitly indicate that we are running in-browser JS-IPFS node for uploads with ipfs.io as public gateway?
Eg. add an item named "API" below "GATEWAY" and set it to "[email protected]" when fallback is active?
| @@ -28,6 +30,40 @@ function initIpfsApi (ipfsApiUrl) { | |||
| return window.IpfsApi({host: url.hostname, port: url.port, procotol: url.protocol}) | |||
| } | |||
|
|
|||
| async function fallbackToBrowserIpfs () { | |||
There was a problem hiding this comment.
Hm.. fallbackToLocalJsIpfs may be more clear.
| @@ -348,6 +384,10 @@ function handleMessageFromBrowserAction (message) { | |||
| } | |||
| } | |||
|
|
|||
| function isBrowserIpfs () { | |||
There was a problem hiding this comment.
How about isLocalJsIpfs ? It is less confusing.
I'm interested in your opinion on why that's necessary. I was thinking we might need it for when a user switches on their daemon after the fallback happens. I had originally considered that the extension should just automatically switch to using a running daemon if it became available...but I'm not convinced yet that that's a good idea! I've just been talking to @olizilla and I think he's got a good point - right now, As a side thought - for your average non-technical user, waiting 20s to fallback to Either way, it's preferable to have an IPFS running than not, so i think falling back to
I agree, it shouldn't suggest that the user is using the node at ipfs.io. Again, @olizilla pointed out that "GATEWAY" isn't useful information in the context of js-ipfs in the browser - it can't be changed, and has to be used, so we can just remove it. I'm not keen on "API: [email protected]" since Let me know that you think 😄 Awesome to get the conversation going! 🚀 |
|
I'm basically just re-stating @lgierth and @lidel from this issue https://github.com/protocol/lab-week-unconf/issues/23 in that a goal is
So if we view the add-on from the perspective of a new user, then you want it to just work. If we detect that a local ipfs daemon is running, then we're in pro-mode and we want to show all the info and options. I'm not saying that we hide everything from users without a local daemon, but it's interesting to think about what a user who is just trying out ipfs needs and how much info is appropriate. |
|
(fantastic discussion!)
There are many reasons why some users may want to opt-out from running local js-ipfs node, from the top of my head:
I agree, changing the default will improve initial user experience. The checkbox can be named "Use my own daemon", "Use external API" or something like that:
Yes, but we don't want to.. lie 🙃
The more specific, technical goal is to use js-ipfs for both reading and writing. Writes to IPFS are possible today just fine (via I am aware that this limitation may not exist in Brave, but we need to think about Firefox and Chrome users and try to keep experience similar across all browsers, where possible. Note that when run in Firefox, js-ipfs fallback introduced in this PR routes all IPFS requests to a public HTTP gateway (default is Right now browser action icon suggests user is "online", displays "swarm peers", it looks like we are connected to IPFS network: While technically it is true, all content is loaded over public HTTP gateway. Not IPFS. When running js-ipfs there is no "enable redirect" button, nothing. I want to avoid situation where this "partially working js-ipfs" feels disingenuous to users who expect extension to use distributed web for loading content. Let me know if I am overthinking it 🙂 |
|
Hi @lidel, We've had some thoughts since last week and we have a couple of changes and suggestions aimed to address some of the feedback above. As we already discussed, and if you're still ok with the idea, then lets make JS-IPFS the default so first time (and non-technical) users get an awesome experience. However for this first pass lets park the fallback idea. I think it over complicates things and I'd rather just make it really easy to turn on your own IPFS node without having to start a daemon (i.e. start an embedded JS-IPFS node). Since all the current ipfs-companion users are "power users" we should aim to make this as non-disruptive as possible by placing the toggle switch directly on the popup, so they can just switch back (and forth) really easily. I've done some mockups: External
Embedded
We could also get the "stars" in the background of the header as per the website...you get the idea though :) I think the embedded/external toggle deals with any ambiguity around what kind of IPFS node is being used, and with the logo/status being moved up to the top of the popup we have space to change "GATEWAY" to "HTTP GATEWAY" (not visualised). @olizilla and I have the goal of getting IPFS into the Brave browser, and right now we're thinking we'll be able to feature detect what extension APIs are available and allow Brave users to have IPFS content served directly to them by JS-IPFS. If this becomes too complicated then we might have to fork, but we'd rather push the boundaries here in ipfs-companion and have all the browsers benefit from any improvements we make towards that goal. I hope that maybe one day Firefox/Chrome browser extensions will allow IPFS to serve content. If that happens we'd no longer be being disingenuous towards Firefox/Chrome users and the gateway/redirect configurations go away*. * ok so not completely, I see that there's definitely a use case for being able to use an external redirect that's not your local IPFS daemon. I'd expect the toggle to also be on the settings page, so perhaps it's worth adding a message there where there's more real estate to explain the state of play with the embedded IPFS node and the extensions API? |
|
@alanshaw I am sold. Wholeheartedly agree with proposed direction!
Keep up great work! |
|
See #320 |
This PR adds
js-ipfsto the extension and will fallback to using it if it cannot be connected within 20s.There's still some work to do on the contextual menus, but the basics are there!