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.ipfs experiment 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 */ }

[lidel]

Closing due to #589 (comment)