On Sat, Aug 2, 2025 at 2:23 PM Melvin Carvalho <melvincarvalho@gmail.com> wrote: > If there’s a path to accommodate this (e.g., via a publicKeyHex field or alternate verification method type), I’d be happy to support and contribute. But pushing existing infrastructure to adopt a new encoding format unilaterally, especially without a clear migration strategy, feels like a misstep. The Multibase header for lowercase hex is: *f* The Multikey header for a secp256k1 256-bit public key is: *e701* An example of a random secp256k1 256-bit public key is: 03d0857e7d01daf430a13b1b054d4c4179367704e567333fd70deb29e0d5413f72 Therefore, the Multibase encoding of the Multikey value is: *f**e701*03d0857e7d01daf430a13b1b054d4c4179367704e567333fd70deb29e0d5413f72 You will notice that the hex value following the header bytes (*f**e701*) is kept as-is, which seems to address your concern, Melvin. Translating to/from this format is a matter of adding a 5-byte (*f**e701*) header, or removing it, which seems like a workable "migration strategy". Am I missing something? -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. https://www.digitalbazaar.com/
Received on Saturday, 2 August 2025 19:25:00 UTC