define a string representation for unparsable multiaddresses

[marten-seemann]

When introducing and rolling out new types, we might encounter multiaddresses that we don't understand yet. We should define a string representation so people can pass them around in JSON (for example).

One option would be to use multibase (and assuming you're using a multibase that your peer understands):

/unparsable/<multibase encoded bytes>

[MarcoPolo]

We should probably specify that we should only serialize to a small set of multibases (e.g. only base32). Otherwise, we'll have the same problem here where I can serialize it using baseN and someone else trying to parse that string may not know baseN.

As long as producers (serializers) are strict in what they emit and consumers (deserializers/parsers) are lax (accept any known multibase) we can upgrade the small set of supported multibases. Although, my initial guess is that we probably will not expand the initial set for a while.

[aschmahmann]

a small set of multibases

There's some prior art for doing this in multiaddrs with certhashes and with libp2p peerIDs https://github.com/libp2p/specs/blob/5393c21c4f9038f2ad1cbeac3edf3d0d2c540f39/webrtc/webrtc-direct.md?plain=1#L37-L41 and https://github.com/libp2p/specs/blob/6b3d2630bb495a7a76d9d615b51212d56039c3ea/peer-ids/peer-ids.md?plain=1#L218-L221.

No particularly strong opinions on which ones should be in the MUST or SHOULD set, although I'd certainly consider using ones already in use by other multiaddr components.

[achingbrain]

We should encode the protocol code somehow as well, otherwise we'll only be able to round-trip the component value.

e.g. the protocol table has no entry for code number 123, so if we encounter that in a binary encoded multiaddr it would be:

/unparsable-123/base32-data

[achingbrain]

we'll only be able to round-trip the component value

Actually we can't even do that since we don't know if the value of an unknown protocol is fixed length, omitted or varint-encoded 🙄