Consider using multibase, multihash, multicodec

[dhh1128]

Moved from openssi/peer-did-method-spec#106. Tagging @msporny , @OR13 , @mavarley, and @swcurran, who were following the issue there.

[OR13]

I am a big fan of multicodec... but I suspect that better alignment with KERI may result in a refinement on top of it.

@SmithSamuelM noted on the last call that KERI identifiers have a specific prefix which indicated that they are not updatable (like did key)... I suspect that proper encoding of keri identifiers will yield identifiers that look like did key, but have extra prefix information....

this is more of an issue for KERI that did peer now, imo.

[SmithSamuelM]

KERI uses a much more efficient coding than multi-codec. All cryptographic material in all KERI event elements use the coding. This makes contextual interpretation of cryptographic material explicit. Because in most cases KERI's encoding is net zero increase in size (replaces Base64 pad characters with code characters) this benefit comes for free. So the idea of multi-codec is applied to KERI but it is much better tuned.

That is always the choice. Use something that is in the wild but not well tuned or use something well tuned. In this case I chose the well tuned because it greatly simplifies the the conveyance of cryptographic agility. We get it for free. Because design goal of KERI is universality it wants to have cryptographic agility for each and every element of cryptographic material but not complicate the events with extra fields in order to do so. The derivation code is able to be compact and typically zero overhead only because it is tuned. Multi-codec is way more cumbersome. When you start to add up the extra bytes to multi-codec every element of cryptographic material not just the identifier it becomes significant. So KERI's derivation code is net better. The coding for that is already done in the python, javascript, and rust implementations.

[OR13]

@SmithSamuelM where is the spec for the encoding scheme KERI uses... I'm having a hard time feeling like undocumented encoding schemes are better than documented ones :) ... and multicodec is not even on the IETF / W3C track...

its trivial to register multicodec prefixes, I'm happy to register the ones needed for KERI assuming they can be isolated...

If KERI developers are fundamentally opposed to using multicodec, we need to document the encoding scheme cleanly and independently before proceeding... we can do that here or W3C, IETF.

@SmithSamuelM can you link to the appropriate KERI issue to discuss documenting KERI string encodings of identifiers and events? this is more about KERI string representations that DID Peer at this point.

[SmithSamuelM]

@OR13 One of the challenges in doing anything innovative is resisting the temptation to do stuff thats not. So I think before trying to pull KERI off in to the weeds on a nascent but not yet standard multicodec. Give it some room to breathe so innovation can actually occur. One of KERI's goals is performance in event streaming and sourcing applications. So I spent a lot of time innovating on a coding scheme that makes a performance difference. It matters.

[OR13]

@SmithSamuelM totally agree, can we discuss KERI / Binary / String encoding on another issue.