multiformats / clj-multihash Goto Github PK

According to this https://multiformats.io/multihash/#the-multihash-format
the length should be var int while current implementation reads only one byte https://github.com/multiformats/clj-multihash/blob/develop/src/multihash/core.cljc#L200

See description, should be straightforward.

Hey @greglook!

Thanks so much for this. As you may know, we recently created the Multiformats organization to be a home for all of the multiformats - multiaddr, multihash, etc. Would you be interested in moving this repository to that organization? You would still have admin rights on the repository, but it would be a part of a wider organization. This would mean more relevant eyes on it (most likely) and better cross-repository issue tracking. We'd also add a line mentioning you as the original author, and of course your commits would stay the same.

Of course, keeping it on your profile is also cool; we'll still link to this from the main multihash repository at github.com/multiformats/multihash.

Thanks for taking the time to read this. 👍

Tracking issue, here: multiformats/multiformats#4.

Running either Java 11 or 17, lein tests fail during compilation with the error message
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.DatatypeConverter.

The simple fix is to update to more modern versions of clojure/clojurescript and mvxcvi/alphabase

Generate API docs with Codox and literate docs with Marginalia.

In multiformats/multicodec#25, we changed the blake2b and blake2s codecs to account for the fact that they're actually hash function families. We now allocate a range of codecs, one per hash.

Saw this in readme:

hash:sha2-256:dbd318c1c462aee872f41109a4dfd3048871a03dedd0fe0e757ced57dad6f2d7

nice-- i ran into the same need when making the CID spec here: https://github.com/ipld/cid#human-readable-cids. I would discourage use of : end prefer - because it would be great if people use the compressed representation in URNs instead of the expanded one... but i can be persuaded.

(I would want to ensure people don't use the string versions to rely on them for identifiers-- as the whole copy-pastability and versatility of multihash goes down with that).

See also

• https://github.com/multiformats/multibase
• https://github.com/ipld/cid

Hi @greglook !

Clerk cannot analyze this library using tools.analyzer.jvm since tools.analyzer trips over this expression:

Repro:

$ clj -Sdeps '{:deps {org.clojure/tools.analyzer.jvm {:mvn/version "RELEASE"} mvxcvi/alphabase {:mvn/version "RELEASE"}  mvxcvi/multihash {:mvn/version "RELEASE"}}}'
Downloading: mvxcvi/alphabase/maven-metadata.xml from clojars
Clojure 1.11.0
user=> (require '[clojure.tools.analyzer.jvm :as ana :as j])
nil
user=> (do (j/analyze-ns 'multihash.core) nil)
Execution error (ExceptionInfo) at clojure.tools.analyzer.passes.jvm.validate/validate-tag (validate.clj:235).
Class not found: (class (byte-array 0))

Are you open to a PR which fixes this problem?

I've started to work on this a bit in the cljs-support branch. The main differences so far are:

• Declaring the type itself, as cljs has a different set of protocols and method names than clj does for the same roles, e.g. clojure.lang.ILookup/valAt vs cljs.core.ILookup/-lookup.
• Encoding and decoding base58 from bytes, which I've handled by creating a new cross-compiled library alphabase. Also includes many utilities for working with bytes generically across the two runtimes.
• Clojure can leverage java.security.MessageDigest to get native SHA1 and SHA2 implementations, while cljs doesn't have an equivalent. I'll probably omit them for now and rely on the backend for hashing, or users can find another library to support them.