Description
Right now -- I should say, from how I understand it -- js-multiformats defines an interface for encoding and decoding using individual codecs. This encapsulates the codec pattern perfectly well. In fact, for encoding, it's really all you need; seeing as you can only encode something using a single codec.
However, when dealing with IPLD in the more general sense (which strives to be polymorphic over its serializations), developers are left on their own to create codec/hash registries that will hopefully be complete enough to be able to deserialize what's given to them.
This is especially exacerbated in the case of libraries which take CIDs from their users. Library authors have to either:
- Include as many codecs as possible
- This introduces massive dependency size overhead
- Future needs for codecs means library updates are necessary
- Accept extra codecs to be matched against when deserializing data
Obviously, the former of the two is an obvious antipattern. The latter, though, has been used successfully in many of the higher level JavaScript IPFS libraries to provide generic interfaces libraries can consume -- dependency injection.
I propose a similar interface, named something like a PolyMultidecoder which exposes an add() and remove() to (de)register BlockDecoders, and a single decode() which resolves and uses the correct decoder, or throws an error if it's otherwise missing.