Detect and communicate "offline/connecting to swarm" state

[lidel]

Extracted from https://github.com/ipfs-shipyard/ipfs-share-files/issues/41#issuecomment-442175082

Problem

[..] if you [use js-ipfs fallback and] try to download a file without having connected to a bootstrap node, the UI hangs. When everything is working the download goes to your download folder, as per the browser settings.

I don't know what a bootstrap node is or how I would connect to it. Is that something that needs to be explained on the download page?

My point was not everyone has fast internet and sometimes it can take up to 10s of seconds before embedded js-ipfs connects to bootstrap/preload nodes.

UI looks "ready" immediately, so user adds files to local node (which is still "offline"), copies URL, shares it and.. nothing happens.

Solution?

I think we are missing proper UX around communicating what is happening to the user.

This could be a good opportunity to explain that IPFS does not use a centralized service which is fragile and can be easily blocked, but a robust, decentralized network of peers.

There are multiple ways of handling this, below is just an example:

• monitor the number of peers by counting output of ipfs.swarm.peers
• if ipfs.swarm.peers < 1 indicate "offline mode" / "connecting to swarm, please wait"
  • perhaps not accept input from user, make UI (Add button) feel inactive?
  • display some kind of "connecting to swarm" splash screen/animation that is both engaging and informative

Does it sound like a good approach? Would love to hear some thoughts on this.

[fsdiogo]

My point was not everyone has fast internet and sometimes it can take up to 10s of seconds before embedded js-ipfs connects to bootstrap/preload nodes.

UI looks "ready" immediately, so user adds files to local node (which is still "offline"), copies URL, shares it and.. nothing happens.

Does the added files become available after connecting to the bootstrap nodes?

There's a real danger of the user leaving the page if the first step of using the app is waiting a long time before interacting with something. If the answer to my previous question is "Yes", we can do it the other way around: let the user add instantly whatever he wants, and then use a nice animation showing the files propagating or the connection to other peers (even if it's not totally accurate with what is happening).

Ideally the animation should be compelling and somehow explain some of the process. We could come up with some animated SVG for example, that would be pretty cool.

[lidel]

Does the added files become available after connecting to the bootstrap nodes?

Yes, afaik you should be able to add a file to local js-ipfs repository in "offline mode" (when no connection is yet established) and when connected provide it to others (preload notes).

let the user add instantly whatever he wants, and then use a nice animation showing the files propagating or the connection to other peers (even if it's not totally accurate with what is happening).

Sounds good!

We could introduce additional trick to make upload screen feel less "busy":

• Instead of showing share link all the time, replace it with a button "Get share link" which when clicked generates and displays share link for current set of files
  • If connected to some peers, just show share link immediately
  • If there are no peers yet, then (and only then) display animation until we are online
• When a new file is added, old share link is removed and replaced with "Get share link"

[fsdiogo]

• Instead of showing share link all the time, replace it with a button "Get share link" which when clicked generates and displays share link for current set of files
  • If connected to some peers, just show share link immediately
  • If there are no peers yet, then (and only then) display animation until we are online

That could work.. I'm not completely sold to that solution because I don't love the fact that we're adding an additional step to get the share link.

Moreover, we should always provide the share link even if there are no peers connected because the user may want to share the link and then leave the app to do the work, instead of having to wait to connect to peers and only then share the link.

[lidel]

I don't love the fact that we're adding an additional step to get the share link.

The "Get share link" button solves UX problem in scenario where user adds a file, copies share link for that directory, then adds more files and gets surprised the copied link does not contain all the files (or does not notice it and recipient does not get all the intended files).

I agree we could make it possible to copy link when there is no peers, makes sense, but in that case there should be some addition visual indication "connecting to IPFS swarm is in progress".

[SgtPooki]

@juliaxbow. Low priority but could use a mock if you get free-time

[juliaxbow]

I think I partially addressed this in #46 but I'd recommend withholding the link until the the files are available. However, in reading this thread it sounds like there is a compelling reason we'd want to make the link available prior. Can anyone elaborate why the following is necessary? My understanding is that even if the user leaves the app they still need to keep it running.

we should always provide the share link even if there are no peers connected because the user may want to share the link and then leave the app to do the work

Including screenshots of what I suggested below as it is different from the "get share link" button proposal.