How to updrade from deprecated `multicodec` package? about js-multiformats

[rvagg]

One of the reasons the table was removed from the equation is that it's too big and just growing over time and the focus of a large majority of JavaScript programs is web deployment, where bundle size matters; so the table is now a reference, and individual codecs and other packages implementing parts of the table, bring their codes and names to the party and you use it from there.

If you're operating outside of the straightforward paths (e.g. using an IPLD codec where the codec does all this work for you and exports a code etc.), then it gets a little more verbose. I wonder whether there's utilities in the various js-libp2p packages that could make this easier for your case, @achingbrain might have alternative suggestions. But here's a form that uses the current multiformats packages to do something like what you're doing:

import { varint } from 'multiformats'
import { base58btc } from 'multiformats/bases/base58'

// this is from the multicodec table
const codec = { name: 'ed25519-pub', code: 0xed }

// thing we want to multibase encode
const thing = new Uint8Array([0xde, 0xad, 0xbe, 0xef])

// set up a target byte array we want to encode to,
// first by figuring out how long it needs to be, then prefixing it with the code
const el = varint.encodingLength(codec.code)
const encoded = new Uint8Array(thing.length + el)
varint.encodeTo(codec.code, encoded) // set prefix
encoded.set(thing, el) // add the original bytes

// if you want it multibase encoded, use encode(), if you want just
// base encoded (without multibase prefix), use baseEncode()
const baseEncoded = base58btc.encode(encoded)
console.log(baseEncoded)

If this is something you're doing often, then the prefix-a-codec thing might be worth abstracting out to a utility; it's the most verbose bit.

I hope this helps.

[rvagg]

Every system has boundaries, you have to make choices regardless of what you're offered here. Those choices may be forced by implementations (is a hasher or codec even available in your language / environment?), or they may be local, due to the system being implemented.

The majority of systems using multiformats have a narrow scope; very few are expansive and attempt to cover as many codecs, hashers, etc. as possible. Kubo / Helia are probably the best examples of expansive systems, and even those have very narrow limits if you consider the scope of the multicodec table.

In JavaScript, bundle concerns add another layer of constraints and most applications are narrowly focused and choose and use at most one, or two codecs, and one or two hash functions. Many systems (e.g. a social media app like Bluesky) have precisely 1 codec and 1 hasher; and that's all they need and that's all they expect. If we shipped a package that pulled in every possible hasher and codec then it'd be entirely unacceptable to builders of most systems. So we take the opt-in approach.

[nickreynolds]

Thanks for your detailed response! Was able to get my refactor working.

[mirceanis]

@rvagg I thought the whole point of multicodec is that it is self-describing.
If people choose to implement only parts of the table, it fails to be self-describing and becomes an implementation detail.
It then seems more efficient to just agree on a format for whatever protocol is being implemented instead of agreeing to use multicodec and additionally agreeing on a subset of codecs to implement.