I'm testing interoperability between a smoldot dialer running in wasm/Chrome and a litep2p listener. Right now this is limited to connection establishment, noise handshake and ping behaviour in either direction. The only part that doesn't work is multistream-select negotiation on the outbound substream from litep2p to smoldot.

Due to the libp2p-webrtc specific protobuf framing and how network data is surfaced by str0m, there is a custom code path for handling multistream-select negotiation on webrtc connections. That code path does not use multistream_select::protocol::MessageIO by going through listener_select_proto() and therefore does not handle length prefixes in multistream-select messages correctly.

When smoldot is made aware of a newly opened inbound substream by calling MultiStream::add_substream(), it sends the multistream-select header right away, without waiting for any data to arrive from the dialer. The resulting message only contains the header, with a length prefix.

Once the protocol request message has been received from the dialer and the API user has accepted the protocol, the confirmation message is sent.

The Vec<u8> received from str0m in the ChannelData event still contains the length prefix, which causes the relevant comparisons in multistream_select::protocol::Message::decode() to fail for the header and the protocol confirmation.

When litep2p is the listener, the negotiation succeeds, because litep2p sends both header and protocol confirmation in one message, which multistream_select::protocol::Message::encode() treats as response to an ls command and adds length prefixes webrtc_encode_multistream_message() adds length prefixes.