Re: [Multiformats] Multiformats Considered Harmful

[Melvin Carvalho <[e-mail]>]

po 6. 11. 2023 v 15:07 odesílatel Manu Sporny <[e-mail]>
napsal:

> On Sun, Nov 5, 2023 at 5:09 PM Melvin Carvalho <[e-mail]>
> wrote:
> > I would like to draw attention to potentially new information with broad
> impact, specifically regarding the proposed deprecation of publicKeyPem and
> the adoption of multiformats.
>
> This is not new information, usage of `publicKeyPem` was deprecated a
> very long time ago... none of the modern Data Integrity cryptosuites
> use it. `publicKeyPem` also /has nothing to do with Multiformats/...
> it's a W3C Data Integrity thing, not a Multiformats thing.
>
> That said, it's easy to undeprecate it... you just need to see if the
> fediverse community cares -- they rolled it out in 2018 and haven't
> really touched it since. If they want to continue using it, they have
> not made that clear, but if they do, I expect the property will be
> undeprecated.
>

An inversion.  publicKeyPem is used by over 10 million accounts.
base58check is used by over 10 million accounts.  public keys in hex are
used by millions of accounts and software.

Why is the onus on these projects to adapt to multiformats and have the
things they use deprecated.


>
> > Moreover, the adoption of multiformats has seemingly overlooked
> compatibility with prevalent key formats such as bech32, which may
> inadvertently lead to a dichotomy of 'winners and losers' in the space,
> rather than fostering inclusivity.
>
> If you want a new key format, just write a spec and register it in the
> Multiformats registry.
>

This is an inversion, the registry, if it wants to be internet-wide and
universal, should include massive deployments

Additionally, the registry becomes a gate kept single point of failure


>
> > In light of these considerations, I urge the IETF to reflect on whether
> the move towards multiformats genuinely embodies the principles of a
> universal standard or if it rather represents a narrowing of scope to
> well-established implementations.
>
> We have had push-back from the IETF community regarding the
> registration of a large number of Multiformats. Part of the desire
> here is to have IETF have a more formal change control process over
> the registry.
>

Yet, it very much is a 'sacred' set of algorithms that favour a specific
cohort.  Even in this thread, there is a tension between adding well
deployed key formats, removing existing ones, and not having too many.


>
> > It is my view that this transition may not only be premature but also
> potentially detrimental to systems that have achieved substantial network
> effect over time.  See the issue below which proposes deprecating
> publicKeyPem (in use over 10 million accounts) for very complex
> multiformats alternative.
>
> Again, the deprecation of `publicKeyPem` has nothing to do with
> Multiformats. Deprecating it does not cause the systems that are
> deployed that are using it to fail or stop working. If the fediverse
> community wants to keep the property alive, they can just say that
> they intend to keep using it and we'll put it back into the spec
> (though, I expect objections from the JOSE community if we don't
> deprecate it).
>

I'm highlighting why this is problematic.  Either make a universal internet
wide system that covers the whole space, which could go at the IETF.  Or a
specific set of algorithms that cover your use cases, for example in the
IPFS standards area.

The problem arises with the workflow of saying, "we have a modern way of
representing a key" (a good thing!).  But then someone saying, two ways of
doing something is confusing, lets get rid of one.  Now a lot of things
break.  Ive seen it time and again, two things pitched as living side by
side, but then one eating another, and a small number of stakeholders make
the decision, at the expense of millions of deployed accounts.

This is probably a bad time to ask a favour, but I'd really ask just to
leave publicKeyHex in there.  It's used all over the place, and benefits
from a stable predicate.  Hex is great because you can just copy and paste
it, and everything knows how to speak hex.  Few things know how to speak
multiformats, and require an extra step to get back the key, plus a
lookup.  publicKeyHex is in use today in a lot of places.  I'm not raising
this to be awkward, I stated my view and hoped to live side by side, but I
am hitting these issues when trying to create implementations.  The
deprecation says not to make new implementations using the terms, but to
interoperate I have to.  And if you read through the issues, there are
calls to remove the terms.

Whatever happens to multiformats, please could you consider keeping terms
that are not multiformats that are in use, instead of deprecating or
removing them, this is standard best practice across the whole of linked
data in line with "COOL URIs dont change".


>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>