Re: New Work Item Proposal: Data Integrity BIP340 Cryptosuite

Hi Melvin, Jaromil,
Thanks for sharing your thoughts on the use of Multibase and Multikey in
identity infrastructure. While I understand your concerns about
compatibility with existing ecosystems, I believe some of your objections
overlook the broader goals of interoperability and standardization.

Using raw hex as a primary identifier might work in isolated ecosystems
like Bitcoin or Nostr, but it breaks down at the interoperability layer.
Hex strings lack essential metadata, there’s no way to determine curve type
and encoding format. That ambiguity is exactly why Multibase and Multikey
exist. It’s not rational to claim that encoding prefixes fragment
ecosystems when the opposite is true: they enable different systems to
understand each other. Multibase and Multikey unify representations by
explicitly declaring what they are, avoiding implicit assumptions about
curve types or encoding formats.

Manu already outlined a very clear and simple migration strategy: prepend a
deterministic header to existing keys. This doesn’t “break” existing
systems; it simply adds a tiny layer of semantic clarity. You can strip the
prefix if needed locally. But rejecting that entirely because it's not
exactly the same character-for-character string ignores the realities.

Saying "we must preserve raw hex or nothing works" suggests an
unwillingness to adapt even when a backward-compatible pathway is provided.
That’s not a sustainable or forward-looking position in a multi-protocol
internet.

Jaromil, add your point about making prefixes optional and criticizing
prefix semantics. Optionality leads to ambiguity. Ambiguity breaks
deterministic parsing. You mention that Zenroom defines encoding elsewhere,
great, but the rest of the ecosystem can’t be expected to hardcode
per-library assumptions. That’s exactly what standardized, self-describing
encoding solves.

Best,
Filip
https://github.com/filip26


On Sun, Aug 3, 2025 at 9:51 AM Jaromil <jaromil@dyne.org> wrote:

>
> I second Mervin's concerns about multibase and multikey. The imposed use
> of encoding identifiers is really awkward both for systems that have
> settled their format, as well systems like Zenroom where the encoding is
> specified elsewhere.
>
> It would really make sense to make it optional all across the ecosystem.
> Most important, all multi* encodings should have a way to deterministally
> signal themselves: right now they mix their own prefix with raw encodings,
> which I consider a design flaw.
>
> ciao
>
>
>