- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Sun, 3 Aug 2025 21:19:00 +0200
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAKaEYh+u=QjdmKKwtJCcRJO6UMdhUDX5ozFbJe8x3TaGXMhCUQ@mail.gmail.com>
ne 3. 8. 2025 v 20:40 odesílatel Manu Sporny <msporny@digitalbazaar.com> napsal: > On Sun, Aug 3, 2025 at 2:28 PM Christopher Allen > <ChristopherA@lifewithalacrity.com> wrote: > > However, I believe that both Multikey and Multihash suffer from a > significant architectural flaw: they bind type to encoding, violating > proper layering principles. > > I don't think this is true? > > Multikey is a binary format. So is Multihash. Both consist of a binary > header that states how to interpret the remaining bytes. They are > completely independent of the base-encoding format. > > The Data Integrity specs do tend to make a choice when base-encoding, > because we had folks threatening to formally object if we didn't lock > down the base-encoding format... but to say that Multikey and > Multihash bind key/hash type to encoding is not correct. Both are > binary formats... base-encoding layers on top of them. > > Can you see what I'm missing, Christopher? I'm definitely missing > something, or your understanding of Multikey/Mulithash isn't correct. > Multikey doesn’t just encode bytes, it conflates key type with encoding, and then packages that into a self-describing identifier. That may be helpful for some use cases, but it creates tight coupling between what should be independent layers: Semantic type (e.g., “secp256k1”, “ed25519”) Encoding format (e.g., hex, base64, base58, Bech32) Transport and interpretation (e.g., in a DID Document, QR, message, or proof) This conflation limits flexibility and makes it harder to swap out encodings or types independently. That’s the architectural flaw: by embedding type info directly in the encoded string, you make cross-domain reuse brittle and harder to adapt to new contexts. In contrast, many systems (Bitcoin, Nostr, DNSSEC, etc.) keep type and encoding orthogonal. That enables layering, composability, and protocol re-use, exactly what the raw hex preference in did:nostr aims to preserve. > > -- manu > > -- > Manu Sporny - https://www.linkedin.com/in/manusporny/ > Founder/CEO - Digital Bazaar, Inc. > https://www.digitalbazaar.com/ > >
Received on Sunday, 3 August 2025 19:19:16 UTC