js-libp2p
js-libp2p copied to clipboard
libp2p
[feature request] Yamux support
Since there is no placeholder repository and no corresponding issue in this repo yet, I decided to create one here.
There is Yamux implementation in TypeScript at https://github.com/th-ch/yamux-js, it must be possible to create js-libp2p-yamux on top of it and make Yamux the go to implementation across Go/Rust/JS.
I don't have time and experience to do it right now, but if no one takes it, I might eventually write js-libp2p-yamux myself.
Maintainer of go-libp2p here 👋
This would be super valuable for the entire libp2p ecosystem. mplex is a terrible muxer, yet we've been keeping support for it, just because JS didn't have support for any other muxer.
Do we have any data on how spec-compliant / reliable https://github.com/th-ch/yamux-js is? The repo doesn't have many stars or users, so there might be some bugs lurking in the code. We might need to be prepared to submit a few fixes to that repo.
I think https://github.com/th-ch/yamux-js is a good start, but honestly, I would rather fork it, convert it to use Uint8Array (instead of Buffer) to be in line with the rest of js-libp2p (and for the smaller bundle in browser) and export js-libp2p compliant muxer interface.
@BigLep Since there is quite some work on #1166 should I pause this and focus on this issue instead? Seems like this is a lot more straightforward and higher priority.
@mpetrunic : thanks for raising. I started a public Discord thread on priorities here with my thoughts: https://discord.com/channels/806902334369824788/949091153247084605/949091166694027294 . We can also discuss more tomorrow during js-libp2p triage.
Triage note:
- done: researched https://github.com/th-ch/yamux-js - identified gaps around working with streams
- next: implementing gaps + migrating forked yamux-js to async/iter
2022-05-03 conversation: for testing this work against a go-libp2p implementation, it would be easiest if https://github.com/libp2p/go-libp2p-daemon/issues/266 was handled.
@wemeetagain : I know it's been discussed at js-libp2p triage, but since various folks are watching this issue, can you provide an update on how this is going? Is there any milestones or checkpoints here or a sense of timing? Thanks.
I've been busy with many competing priorities, I'm sorry.
I've pushed the latest progress here: https://github.com/ChainSafe/js-libp2p-yamux
I'd estimate its ~30% complete. The following is implemented:
- basic scaffolding of the muxer, management of streams
- frame decoding pipeline
- frame type handling
- stream closing / reseting
I'm working towards passing compliance tests, which would be a minimally working muxer that allows creation/deletion of streams and sending/receiving data within them. Then after, adding handling of window updates.
I'll continue to work on this, I should have 8+hrs to contribute this week. But if this becomes a critical blocker, feel free to PR to the repo or fork and continue forward. I'll happily merge additions and merge forks back into this repo and continue from there.
It's now passing the js-libp2p stream-muxer compliance tests.
I'll now be working on handling of window updates and additional features for parity with go-libp2p's implementation.
2022-06-07 conversation:
Done criteria:
- Implement the spec
- Interop test with go
- Certain features of go implementation (per muxer: limits on number of streams, number of in-progress incoming streams, number of in-progress outgoing stream)
@wemeetagain will create a PR for the implementation and then followup with the interop tests and resource limiting.
Draft PR open here: https://github.com/ChainSafe/js-libp2p-yamux/pull/2