Compatibility with deno

[sebilasse]

For an ActivityPub project I need ipfs in deno and this seems most promising to me. Currently it seems that the crypto.generateKeyPair is not supported, coming from https://github.com/libp2p/js-libp2p-crypto

See https://stackoverflow.com/questions/72584422/how-to-convert-node-crypto-generatekeypairsync-to-deno

This is the error stack:

[AsyncFunction: createLibp2p] [Class: MemoryDatastore] [Class: MemoryBlockstore] [Function: unixfs] [Class: CID] [AsyncFunction: createHelia]
error: Uncaught Error: Not implemented: crypto.generateKeyPair
    at notImplemented (ext:deno_node/_utils.ts:7:11)
    at generateKeyPair (ext:deno_node/internal/crypto/keygen.ts:8:5)
    at ext:deno_node/internal/util.mjs:83:15
    at new Promise (<anonymous>)
    at generateKeyPair (ext:deno_node/internal/util.mjs:68:12)
    at Module.generateKey (file:///Users/ed/Library/Caches/deno/npm/registry.npmjs.org/@libp2p/crypto/1.0.14/dist/src/keys/ed25519.js:31:23)
    at Module.generateKeyPair (file:///Users/ed/Library/Caches/deno/npm/registry.npmjs.org/@libp2p/crypto/1.0.14/dist/src/keys/ed25519-class.js:105:52)
    at generateKeyPair (file:///Users/ed/Library/Caches/deno/npm/registry.npmjs.org/@libp2p/crypto/1.0.14/dist/src/keys/index.js:35:34)
    at createEd25519PeerId (file:///Users/ed/Library/Caches/deno/npm/registry.npmjs.org/@libp2p/peer-id-factory/2.0.3/dist/src/index.js:6:23)
    at createLibp2pNode (file:///Users/ed/Library/Caches/deno/npm/registry.npmjs.org/libp2p/0.43.3/dist/src/libp2p.js:395:32)

[achingbrain]

I'm not massively familiar with approaches for polyfilling APIs in deno.

For the browser there's config in @libp2p/crypto to load a pure-js implementation of Ed25519 - is there a way we can get deno to do the same thing?

[sebilasse]

[discovering deno] @kitsonk @bartlomieju @denoland ^ Can we?

tl;dr ipfs in deno would be superfun

[bartlomieju]

If you're asking about the missing crypto API, you can watch https://github.com/denoland/deno/issues/18455 for updates on the provided APIs. We intend to ship crypto.generateKeyPair() next week.

[achingbrain]

That's awesome!

I wasn't asking about the missing API, I was asking if there's a way to override the files deno loads for a given module so we can polyfill missing APIs until they are shipped, in a similar way to using the "browser" field in a package.json to load browser-compatible implementations of whatever feature.

If the missing parts are being implemented though I'm more than happy to hang on and use the proper versions of APIs ❤️

[bartlomieju]

There's no way to override the files Deno uses to polyfill these APIs. Unfortunately you will have to wait for it :)

[justin0mcateer]

@sebilasse Have you been able to work on this any more with the latest version of Deno? Has anyone else made any progress?

[bartlomieju]

FYI crypto.generateKeyPair() is available in Deno v1.33

[justin0mcateer]

FWIW, I tried the latest version Deno with one of the simple examples from the 'js-libp2p' repository yesterday and I couldn't get it to run (with minimal effort). Unfortunately, there are some transitive dependencies deep in the stack (in this case 'jsbn') that are extremely old/unmaintained, that use archaic export patterns that Deno does not seem to support (at least not well).

I spent quite a lot of time on this last year and ultimately concluded that it was not feasible at that time. I think the situation has gotten much better, a lot (thanks @achingbrain and team) of hard work has gone into overhauling the top level packages to be: 1) TypeScript 2) Fully ESM 3) Browser Friendly 4) Having less dependencies (esp Helia vs js-ipfs)

I would like to spend some time to do some deep analysis on the transitive dependencies and see how much effort it would be to eliminate the old/outdated transitive dependencies. Unfortunately, we have other pressing matters at this time. However, we might be willing/able to sponsor someone to take on the analysis and/or remediation effort if there is interest.

[achingbrain]

Thanks for looking in to this. If a hitlist of problematic dependencies can be produced, we can certainly look at removing or replacing them.

A quick glance through the code shows that jsbin is a dependency of @achingbrain/ip-address (a temporary fork of ip-address with https://github.com/beaugunderson/ip-address/pull/148 applied), itself only used to validate IP4/IP6 addresses supplied as strings so could probably be replaced with a regex.

[SgtPooki]

Has anyone published a repo containing the attempts discussed in this thread? It would be nice to have something for us to hack on and push fixes to.

[SgtPooki]

I threw together https://github.com/SgtPooki/helia-deno quick and am blocked on asymmetricKeyType. see https://github.com/SgtPooki/helia-deno#current-blockers

that issue seems to be tracked by https://github.com/denoland/deno/issues/18928 on the deno side.

[justin0mcateer]

I would be very interested in collaborating on that.

Have you seen this PR?: https://github.com/denoland/deno/pull/18651

[SgtPooki]

@justin0mcateer feel free to push a PR to SgtPooki/helia-deno if you have any improvements. I skimmed https://github.com/denoland/deno/pull/18651 but it doesn't mean much to me right now. What am I missing?

[SgtPooki]

Related: https://github.com/esm-dev/esm.sh/issues/562

[sebilasse]

FYI https://jsr.io/@std/crypto is now stable