Skip to content

the 5555 <---[ THING ]---- 5555 revelation is too enlightening#8

Merged
jbenet merged 1 commit into
multiformats:masterfrom
Mithgol:master
Aug 17, 2016
Merged

the 5555 <---[ THING ]---- 5555 revelation is too enlightening#8
jbenet merged 1 commit into
multiformats:masterfrom
Mithgol:master

Conversation

@Mithgol
Copy link
Copy Markdown
Contributor

@Mithgol Mithgol commented Aug 17, 2016

I believe that the question “Which one of these is the encoder and which the decoder?” becomes really deep when 5555 <---[ THING ]---- 5555 is 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 ]---> 8888 instead of its current form.

@jbenet jbenet merged commit e6be85b into multiformats:master Aug 17, 2016
@jbenet
Copy link
Copy Markdown
Member

jbenet commented Aug 17, 2016

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.
On Tue, Aug 16, 2016 at 20:11 Mithgol notifications@github.com wrote:

I believe that the question “Which one of these is the encoder and which
the decoder?” becomes really deep when 5555 <---[ THING ]---- 5555
is 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 ]---> 8888 instead of its current form.

You can view, comment on, or merge this pull request online at:

#8
Commit Summary

  • the 5555 <---[ THING ]---- 5555 revelation is too enlightening

File Changes

Patch Links:


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#8, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIcoURJ9ENxUe6pXIp_-Rj1EccBdPBSks5qglGpgaJpZM4Jl-WZ
.

lidel added a commit that referenced this pull request Apr 14, 2026
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants