Tracking issue: mplex deprecation

[marten-seemann]

Things left to do:

• turn mplex off by default ipfs/kubo#9958
• stop testing mplex test-plans#196
• archive https://github.com/libp2p/go-mplex
• remove it from go-libp2p transport suite: transport tests: remove mplex tests go-libp2p#2402
• mark it as deprecated in the specs
• blog post Detail the deprecation of mplex blog#106
• remove from docs.libp2p
• deprecate from js-libp2p

@achingbrain Anything left to do on the JS side?
@mxinden @thomaseizinger Anything left to do on the Rust side? Feel free to add to above list.

[Menduist]

Eth consensus still specifies mplex as a "must have" multiplexer: https://github.com/ethereum/consensus-specs/blob/9e50c74a372c0d8349764ef411b22cfa71f2a656/specs/phase0/p2p-interface.md?plain=1#L164

And some eth2 clients still don't have a prod-ready yamux (nimbus doesn't, last time I talked to lodestar they didn't, and I think teku doesn't)

edit: apparently jvm-libp2p barely supports yamux

[dapplion]

And some eth2 clients still don't have a prod-ready yamux (nimbus doesn't, last time I talked to lodestar they didn't, and I think teku doesn't)

Lodestar latest stable supports mplex only but we have a complete implementation of yamux in heavy testing for the last 1-2 months. Hopefully we can rollut soonish

[achingbrain]

Anything left to do on the JS side?

• Add a deprecation notice to the mplex readme
• Deprecate the mplex module on npm

People can still configure js-libp2p with mplex and continue to use it if they wish, they'll just get a warning when they do an npm install.

[marten-seemann]

Eth consensus still specifies mplex as a "must have" multiplexer: https://github.com/ethereum/consensus-specs/blob/9e50c74a372c0d8349764ef411b22cfa71f2a656/specs/phase0/p2p-interface.md?plain=1#L164

Thank you @Menduist, I wasn't aware. What would be the process to get that spec changed?

[Menduist]

The first step would be for every client to have yamux enabled by default (which requires stable support in their underlying libp2ps, and proper testing)

Once that is done & we are confident in all yamuxes, we can update the specs to remove mandatory support

[thomaseizinger]

@mxinden @thomaseizinger Anything left to do on the Rust side?

Nope. It is already "annoying" to use because you need to add a separate dependency.

A next step could be to remove it from the mono-repo and add it to a community maintained one for people that still want to use it.

[marten-seemann]

Kubo removed mplex support: ipfs/kubo#9958.

[BigLep]

Per ipfs/kubo#10069, Kubo is actually going to disable mplex by default for the next Kubo release and then followup with removing mplex in the next release.

I know the woes of mplex have been decried many times before. Is there a canonical place that we point to for explaining why not to use mplex. I think it would be good to link to that from this issue (and others like ipfs/kubo#10069)

[p-shahi]

Per ipfs/kubo#10069, Kubo is actually going to disable mplex by default for the next Kubo release and then followup with removing mplex in the next release.

I know the woes of mplex have been decried many times before. Is there a canonical place that we point to for explaining why not to use mplex. I think it would be good to link to that from this issue (and others like ipfs/kubo#10069)

When libp2p/blog#106 is done we can point users to this blog post. Afaik there's no other place other than https://docs.libp2p.io/concepts/multiplex/mplex/#drawbacks atm

[thomaseizinger]

Afaik there's no other place other than docs.libp2p.io/concepts/multiplex/mplex/#drawbacks atm

I guess an even better phrasing for this would be: "If you need a dedicated muxer, yamux should be used. Overall, QUIC should be preferred over TCP"?

[mxinden]

Is there a canonical place that we point to for explaining why not to use mplex.

Afaik there's no other place other than https://docs.libp2p.io/concepts/multiplex/mplex/#drawbacks atm

Other past discussion: #402

[p-shahi]

Afaik there's no other place other than docs.libp2p.io/concepts/multiplex/mplex/#drawbacks atm

I guess an even better phrasing for this would be: "If you need a dedicated muxer, yamux should be used. Overall, QUIC should be preferred over TCP"?

good point @thomaseizinger pushing change now