feat: use jsipfs as fallback instead of public gateways #44
Conversation
ghost
added
the
|
When a file larger than 1GB is found, a warning is shown: (in the image I mocked it to be for files larger than 2MB)
|
fsdiogo
changed the title
There was a problem hiding this comment.
I really like the icon color matching message left border -- makes it easy to see which files may cause trouble 👍
Some asks below:
-
BUG: Link to IPFS Companion is broken (both links points at desktop)
- This is probably because the same
<1>tag is used for both. Check working version of tag interpolation in i18n in ipfs-companion (Welcome/Landing Page).
- This is probably because the same
-
STYLE: What if we change the message to be more actionable and emphasize value added by Desktop/Companion?
- Perhaps something like:
If you experience issues when downloading large files, try IPFS Desktop and IPFS Companion for improved performance.
- Perhaps something like:
-
FUN: I noticed ipfs-redux-bundle by default also tries to connect to local API port directly – not sure if it is a bug... it could be a feature ;)
Open problem: Upload
I think this PR should also address UX of Upload part: when you add a big file it will be added to local js-ipfs repo but it will take time for actual data to hit preload servers.
Imagine a scenario (with js-ipfs running on the page):
- You add 3GB file, get working download link, close the tab, share it with friends
- Friends starts to download data
- ... but you closed the tab before entire thing propagated to preload server, there is no other source and they are stuck at 15% forever :(
Until we have some sort of background worker we probably should display the same yellow icon and a message warning user that the tab should be open until their friend downloads entire thing (when embedded js-ipfs is used).
|
Fixed the broken link and updated the copy, thanks @lidel! About the open problem: I agree that it needs to be addressed ASAP, but always and not only when using an embedded |
|
👀 |
@lidel that was intentional, is it a problem? |
|
@olizilla not a problem, I think it makes sense for Share app to do such opportunistic lookup, at least until we have "API lookup heuristic" spec and UX worked out. |
There was a problem hiding this comment.
This PR is neat! ✨ I think using a random shortId as a stable reference for files as the go from Dom style file object, to streams, to ipfs references is a really good idea.
One roadblock to this is that the "download all" trick doesn't work for me in Firefox (v63 on macos 10.14)
|
@lidel thanks! now i see it. That is gross. In part it's a bug from https://github.com/tableflip/uri-to-multiaddr - I assumed that dnsaddr was a generic protocol for "could be dns4 or dns6", but it actually means, check this domain for a dnslink! The only reference I can find to back that up is multiformats/go-multiaddr-dns#7 (comment) which needs more documenting. The next problem is there seems to be no way to convert a uri to a multiaddr correctly without being able to do dns lookups or know in advance if a domain will resolve to an. ipv4 or ipv6 address. multiformats/multiaddr#22 |
|
I was going to suggest that ip4/ip6 hint (based on presence of a specific DNS record type: So.. is the fix to just switch the default API multiaddr to |
Closes #43.