the 5555 <---[ THING ]---- 5555 revelation is too enlightening#8
Conversation
|
I laughed out loud in a subway :) This brings up that that IS a good example. X ----> X May really be X ----> Y ----> X Underneath the hood.
|
Introduce container codecs for IETF-standard asymmetric key formats that carry the algorithm identifier alongside the key material, so implementers can reuse existing crypto libraries and specs rather than mint a per-algorithm codec for every new scheme. - pkix-pub (0x40): SubjectPublicKeyInfo (SPKI) per IETF RFC 5280 section 4.1.2.7 - pkcs8-priv (0x41): OneAsymmetricKey (PKCS #8) per IETF RFC 5958 section 2 - both formats self-identify the key algorithm via the embedded AlgorithmIdentifier OID - codes placed in the single-byte varint range (< 0x80) so existing users of libp2p-key (0x72) in peer IDs and IPNS names can migrate without paying an extra prefix byte per identifier - 0x40 and 0x41 sit in the unclustered 0x39-0x4f free block, avoiding the ipld/CID-codec neighborhood at 0x70-0x7f Refs: - https://www.rfc-editor.org/rfc/rfc5280 - https://www.rfc-editor.org/rfc/rfc5958 - libp2p/specs#711
I believe that the question “Which one of these is the encoder and which the decoder?” becomes really deep when
5555 <---[ THING ]---- 5555is presented as one of the examples.That THING does not seem to encode and decode anything. A fan of zen might call it 無駄、 a workless work.
Such revelation is really enlightening but it probably carries the wrong message and that example should actually mirror the previous
5555 ----[ THING ]---> 8888instead of its current form.