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.