Open sebilasse opened 1 year ago
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?
[discovering deno] @kitsonk @bartlomieju @denoland ^ Can we?
tl;dr ipfs in deno would be superfun
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.
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 ❤️
There's no way to override the files Deno uses to polyfill these APIs. Unfortunately you will have to wait for it :)
@sebilasse Have you been able to work on this any more with the latest version of Deno? Has anyone else made any progress?
FYI crypto.generateKeyPair()
is available in Deno v1.33
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.
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.
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.
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.
I would be very interested in collaborating on that.
Have you seen this PR?: https://github.com/denoland/deno/pull/18651
@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?
FYI https://jsr.io/@std/crypto is now stable
For an ActivityPub project I need
ipfs
indeno
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-cryptoSee https://stackoverflow.com/questions/72584422/how-to-convert-node-crypto-generatekeypairsync-to-deno
This is the error stack: