search

ipfs-shipyard / ipfs-share-files

Share files via IPFS
https://share.ipfs.io
MIT License
145 stars 29 forks source link

feat: use jsipfs as fallback instead of public gateways #44

Closed fsdiogo closed 5 years ago

fsdiogo commented 5 years ago

Closes #43.

fsdiogo commented 5 years ago

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)

warning
fsdiogo commented 5 years ago

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 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".

olizilla commented 5 years ago

👀

olizilla commented 5 years ago

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 ;)

@lidel that was intentional, is it a problem?

lidel commented 5 years ago

@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. However the error indicated by the first arrow here suggests we are using multiaddr without converting it to URL first somewhere (it then retries with real URL).

olizilla commented 5 years ago

@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 https://github.com/multiformats/go-multiaddr-dns/issues/7#issuecomment-375535931 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. https://github.com/multiformats/multiaddr/issues/22

lidel commented 5 years ago

@olizilla

I was going to suggest that ip4/ip6 hint (based on presence of a specific DNS record type: A vs AAA) could be added to the output of DNSLink lookup endpoint at /api/v0/dns/ (the other one being TTL), but we experience the error while resolving API address :man_facepalming: and asking https://ipfs.io/api/v0/dns/ is bit ugly.

So.. is the fix to just switch the default API multiaddr to /ip4/ ?