Tracking issue: mplex deprecation
marten-seemann opened this issue · 12 comments
Things left to do:
- ipfs/kubo#9958
- libp2p/test-plans#196
- archive https://github.com/libp2p/go-mplex
- remove it from go-libp2p transport suite: libp2p/go-libp2p#2402
- mark it as deprecated in the specs
- blog post libp2p/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.
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
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
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.
Eth consensus still specifies
mplexas 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?
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
@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.
Kubo removed mplex support: ipfs/kubo#9958.
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)
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
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"?
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
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