Ipfs-companion: window.ipfs: ipfs.cat does not return AsyncIterable

[SignpostMarv]

I'm noticing some slightly odd behaviour when comparing js-ipfs with the ipfs-companion.

js-ipfs cat reliably returns AsyncIterable, but ipfs-companion sometimes returns a Uint8Array and sometimes returns some other function.

generally, with the ipfs-companion enabled the page is stuck at ~110% CPU and frequently crashes or has to have it's task terminated.

Win 10, Chrome 80.0.3987.122, IPFS Companion 2.10.0

[lidel]

Thank you for reporting this!
I believe this is because IPFS Companion uses older version of js-ipfs and js-ipfs-http-client, thus exposes the old, non-async API.

We are tracking migration to the new js-ipfs(-http-client) in #843, but due to limited bandwidth that won't happen in Q1.

Should we disable window.ipfs until support for async iterables lands in Q2?

@autonome @alanshaw
IPFS Companion exposing non async API does more harm than good right now right now.
Most websites use window.ipfs opportunistically, and will continue working if it is not present.

I want to make a bugfix release and disable window.ipfsexperiment until we switch to the new API (keep user preferences and keep it in the UI, but make it greyed out on Preferences screen with a note that we are working on adding support for async iterables and it will come back in the next release).

Y/n?

[SignpostMarv]

re: disabling ipfs, it may be of use to end users to expose a means of asserting compatibility with a given js-ipfs semver string?

i.e. to clarify if (window.ipfs && window.ipfs.compatibleWith && window.ipfs.compatibleWith('js-ipfs:~0.41')) { /* use window.ipfs */ } else { /* load js-ipfs */ }

[baek4837]

Ipfsteam

[lidel]

Closing due to https://github.com/ipfs-shipyard/ipfs-companion/issues/589#issuecomment-712356448