UX for sharing files that take long time to hit preload servers

[lidel]

Extracted from #44 (review)

Problem

When sharing big files it takes time for actual data to hit preload servers.

Imagine a scenario:

• You add 3GB file, copy download link, close the tab, share it with friends
• Friends start to download data
• ... but you closed the tab (js-ipfs) or shut down daemon (go-ipfs) before entire thing propagated to preload server
• there is no other source to fetch data from and they are stuck at 15% forever :(

Solutions

• For files bigger than "X" we probably should display a message warning user that the tab should be open until their friend downloads entire thing.
  • feat: use jsipfs as fallback instead of public gateways #44 (comment)

    I agree that it needs to be addressed ASAP, but always and not only when using an embedded js-ipfs node. Even if the user is using a local node, if he adds a file, gets the share link and then quits its daemon, the file is "lost". That must be explicit somewhere, and I think it should be somewhere in the copy of "how the share app works".

• ?

Thoughts?

cc @ipfs-shipyard/gui (as this is relevant to all our apps)

[SgtPooki]

I think we should display a message to users when uploading a large file. We could also have an informational message visible at all times for all file sizes that communicates when this issue could come up.

It might be worth adding an onunload prompt to users warning them that the file may not be able to be downloaded after they close the tab as well.

[SgtPooki]

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

[juliaxbow]

Thoughts and mock up below. Let me know your feedback so I can modify! I can share the Figma file if needed.

Large file size help text:

• Instruction to not close the window is already included in Step 2, so that would be the natural place to include messaging re: file size.
• Upon upload of a larger file, we could also include a warning icon with help text upon hover reiterating a) the file will take longer to upload and b) not to close the window.
• These changes (see below) are discreet but visible. Let me know if you want to explore a more obvious/urgent warning.

Sharing link delay:

• I would also suggest that we don't generate/make available--the sharing link until the file is completely uploaded. That way we ensures that no one gets stuck downloading a file that is unavailable due to someone prematurely closing the window. Mock-ups included below. Is there any reason you can think of that we wouldn't want this? I.e. do we currently allow recipient downloads to happen simultaneously with sender uploads?

Notes
I made some minor UI recommendations (redlined below) beyond the scope of this issue. Feel free to ignore.

IPFS.Share.mov

• See alert icon and pop-up at 7 seconds in
• Note that in the above video, hovering over the QR code takes you to the download page. This is for prototype navigation only. The QR code should only function as a QR code.

• see added file size text in Step 2 of instructions

Current IPFS Share upload/share/download windows for reference