Add experimental WebRTC support to multiaddr

[tomaka]

cc @mxinden if you're interested
cc #1712

The payload of /certhash isn't documented in libp2p/specs#412.
I suspect that ultimately people will want to make /certhash super generic and future-proof and over-engineered and all (in case in the vague future it might eventually be used for something else, even though we all know that this will likely never happen), but for now I went with a fixed 32 bytes payload that is hexadecimal-encoded without the 0x prefix. The certificate hash is put as hexadecimal in the SDP packet, so an hexadecimal payload will make it a bit easier to debug if things work.

This is all marked as experimental- until we finish implementing it, so that there's no possible confusion with versions that are incompatible with each other and that kind of things.

[mergify]

Automatically approving tomaka's pull requests. This auto-approval will be removed once more maintainers are active.

[github-actions]

twiggy diff report

Difference in .wasm size before and after this pull request.

---

 Delta Bytes │ Item
─────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       +2574 ┊ <F as nom::internal::Parser<I,O,E>>::parse::h4238c4df4b8a7a6d
       -2284 ┊ <F as nom::internal::Parser<I,O,E>>::parse::h9c8613594a855ced
       +2166 ┊ smoldot::libp2p::multiaddr::ProtocolRef::from_str_parts::hd6845018a76ac9be
       -1783 ┊ smoldot::libp2p::multiaddr::ProtocolRef::from_str_parts::h502df8508dcbe761
       +1342 ┊ <smoldot::libp2p::multiaddr::ProtocolRef as core::fmt::Display>::fmt::h789d46a1f96b0823
       -1189 ┊ <smoldot::libp2p::multiaddr::ProtocolRef as core::fmt::Display>::fmt::h007b9cfa865301ad
        +923 ┊ smoldot::libp2p::multiaddr::ProtocolRef::as_bytes::h1f662594db2f0a7c
        -880 ┊ smoldot::libp2p::multiaddr::ProtocolRef::as_bytes::he29e540017c9d888
        +394 ┊ <&mut nom::combinator::ParserIterator<Input,Error,F> as core::iter::traits::iterator::Iterator>::next::hc5ba5890d1674a91
        -394 ┊ <&mut nom::combinator::ParserIterator<Input,Error,F> as core::iter::traits::iterator::Iterator>::next::hde7d393f33f41113
        -354 ┊ <F as nom::internal::Parser<I,O,E>>::parse::h1ab6e5f8477c224e
        -325 ┊ <&mut nom::combinator::ParserIterator<Input,Error,F> as core::iter::traits::iterator::Iterator>::next::haedc399748f6729e
        +296 ┊ <&mut nom::combinator::ParserIterator<Input,Error,F> as core::iter::traits::iterator::Iterator>::next::hc66e3b2c359f3494
        -294 ┊ core::iter::traits::iterator::Iterator::last::h76ecbef1631d6438
        +290 ┊ <F as nom::internal::Parser<I,O,E>>::parse::hee70a6656aba86d5
        +211 ┊ core::iter::traits::iterator::Iterator::last::h403f283364672c20
        +175 ┊ smoldot::libp2p::multiaddr::protocol::h55642c962adf662c
        -175 ┊ smoldot::libp2p::multiaddr::protocol::h9fb880c3390fb605
        +112 ┊ data[0]
         -63 ┊ <smoldot::libp2p::multiaddr::Multiaddr as core::str::traits::FromStr>::from_str::ha3047e9bbe9dbf60
         -24 ┊ ... and 7 more.
        +718 ┊ Σ [27 Total Rows]

[melekes]

👍

[mxinden]

I suspect that ultimately people will want to make /certhash super generic and future-proof and over-engineered and all (in case in the vague future it might eventually be used for something else, even though we all know that this will likely never happen), but for now I went with a fixed 32 bytes payload that is hexadecimal-encoded without the 0x prefix. The certificate hash is put as hexadecimal in the SDP packet, so an hexadecimal payload will make it a bit easier to debug if things work.

I would be in favor of being consistent with the way /certhash is encoded in the WebTransport specification. The current draft suggests:

a list of multihashes of the certificates

libp2p/specs#404

@tomaka would you consider a multihash as "super generic" already? 👼

[tomaka]

A browser client, in order to connect, must know specifically the SHA256 hash of the certificate.
In other words, all multiaddrs of the form .../webrtc/certhash/<hash> are undialable unless <hash> is SHA256.
Which means that the byte in the multihash that says "this multihash is SHA256" is redundant. And since a SHA256 hash is always 32 bytes, the length is also redundant.
So yes I would consider a multihash too generic.