forked from libp2p/rust-libp2p
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Roadmap.md: Discuss the near term future of rust-libp2p
Here is my (@mxinden) proposal for a roadmap for the next 6 months for the rust-libp2p maintainers (@elenaf9, @thomaseizinger, @jxs and @mxinden) working on the rust-libp2p project. (rust-)libp2p is an open source and open community project. Thus: - I want to make sure we listen to the community and align our work accordingly. I invite **everyone** to leave feedback here. - The below is only planning work for the maintainers, not the community. Folks from the community may suggest and pick up work not prioritized (e.g. [Kademlia efficient querying](#kademlia-efficient-querying)) nor mentioned on this roadmap and we (maintainers) should be supporting them as best as we can. I consider this more of a short-lived document, enabling everyone working and using rust-libp2p to discuss and eventually align on a common mission, making prioritization explicit. Once done, it will likely be outdated quickly and thus I suggest never actualy merge it. In my eyes, continued project management is better done via GitHub issues and thus all the information here should eventually make it into the corresponding GitHub issues if not already the case. Also see: - [libp2p roadmap](https://github.com/libp2p/specs/blob/master/ROADMAP.md) - [go-libp2p roadmap](libp2p/go-libp2p#1784) The items in this roadmap are ordered by importance where I define importance as: - Enable others to build with rust-libp2p before building components ourself. - e.g.[cross behaviour communication](#cross-behaviour-communication) over[Kademlia client mode](#kademlia-client-mode) where the former enables the latter - Invest into tools that enable us to work more efficiently - e.g.[Testground](#testground-abstraction) and [release process](#release-process) - Better do one thing well than many things close to right. - e.g. deprioritize [BitSwap implementation](#bitswap-implementation) and continue on [QUIC](#quic-support) even once first ieration is merged. That does not imply that we won't support community members implementing it. - Improve existing components before introducing new ones. - e.g.[Kademlia client mode](#kademlia-client-mode) before [WebTransport](#webtransport) I am curious what folks think and again encourage everyone to share their thoughts.
- Loading branch information
Showing
1 changed file
with
273 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,273 @@ | ||
| # rust-libp2p Roadmap | ||
|
|
||
| <!-- markdown-toc start - Don't edit this section. Run M-x markdown-toc-refresh-toc --> | ||
| **Table of Contents** | ||
|
|
||
| - [rust-libp2p Roadmap](#rust-libp2p-roadmap) | ||
| - [Testground abstraction](#testground-abstraction) | ||
| - [TLS support](#tls-support) | ||
| - [QUIC support](#quic-support) | ||
| - [WebRTC support (browser-to-server)](#webrtc-support-browser-to-server) | ||
| - [Release process](#release-process) | ||
| - [Refactor event handling in `Swarm`](#refactor-event-handling-in-swarm) | ||
| - [Cross Behaviour communication](#cross-behaviour-communication) | ||
| - [swarm/handler: Decouple ConnectionHandler from {In,Out}boundUpgrade #2863](#swarmhandler-decouple-connectionhandler-from-inoutboundupgrade-2863) | ||
| - [Generic connection management](#generic-connection-management) | ||
| - [Kademlia efficient querying](#kademlia-efficient-querying) | ||
| - [Kademlia client mode](#kademlia-client-mode) | ||
| - [Hole punching](#hole-punching) | ||
| - [Streaming response protocol aka. the ultimate escape hatch](#streaming-response-protocol-aka-the-ultimate-escape-hatch) | ||
| - [Improved WASM support](#improved-wasm-support) | ||
| - [Muxer handshake optimization](#muxer-handshake-optimization) | ||
| - [Bitswap implementation](#bitswap-implementation) | ||
| - [WebTransport](#webtransport) | ||
|
|
||
| <!-- markdown-toc end --> | ||
|
|
||
| ## Testground abstraction | ||
|
|
||
| Status: todo | ||
|
|
||
| Tracking: https://github.com/libp2p/test-plans/pull/49#issuecomment-1267175415 | ||
|
|
||
| Dependencies: | ||
|
|
||
| Dependents: | ||
|
|
||
| - [QUIC](#quic-support) | ||
| - [WebRTC](#webrtc-support-browser-to-server) | ||
|
|
||
| We now have the infrastructure to run cross-implementation and cross-version compatilibilty tests | ||
| via https://github.com/libp2p/test-plans and Testground. This setup is rather bare-bone, i.e. today | ||
| it only runs a single TCP test. Long term we need to come up with the abstractions to test many | ||
| dimensions, e.g. implementations (Go, JS, Rust, Nim), version, transport, ... . | ||
|
|
||
| This will enable us to test QUIC and WebRTC against rust-libp2p itself as well as js-libp2p and | ||
| go-libp2p. | ||
|
|
||
| ## TLS support | ||
|
|
||
| Status: In progress | ||
|
|
||
| Tracking: https://github.com/libp2p/rust-libp2p/pull/2945 | ||
|
|
||
| Dependencies: | ||
|
|
||
| Dependents: | ||
| - [QUIC](#quic-support) | ||
|
|
||
| This allows us to secure both TCP and QUIC connections using TLS. This is a requirement for QUIC | ||
| support. Running TLS on top of TCP is a nice to have, since we already have noise. | ||
|
|
||
| ## QUIC support | ||
|
|
||
| Status: In progress | ||
|
|
||
| Tracking: https://github.com/libp2p/rust-libp2p/issues/2883 | ||
|
|
||
| Dependencies: | ||
| - [TLS](#tls-support) | ||
| - [Testground](#testground) | ||
|
|
||
| Dependents: | ||
|
|
||
| QUIC has been on the roadmap for a long time. It enables various performance improvements as well as | ||
| higher hole punching success rates. We are close to finishing a first version with | ||
| https://github.com/libp2p/rust-libp2p/pull/2289. Long term there is lots more to do, see tracking | ||
| issue https://github.com/libp2p/rust-libp2p/issues/2883. | ||
|
|
||
| ## WebRTC support (browser-to-server) | ||
|
|
||
| Status: In progress | ||
|
|
||
| Tracking: https://github.com/libp2p/specs/pull/412 | ||
|
|
||
| Dependencies: | ||
| - [TLS](#tls-support) | ||
| - [Testground](#testground) | ||
|
|
||
| Dependents: | ||
|
|
||
| We are currently implementing WebRTC for **browser-to-server** connectivity in | ||
| https://github.com/libp2p/rust-libp2p/pull/2622. More specifically the server side. This will enable | ||
| browser nodes to connect to rust-libp2p nodes where the latter only have self-signed TLS | ||
| certificates. See https://github.com/libp2p/specs/pull/412 for in-depth motivation. | ||
|
|
||
| Long term we should enable rust-libp2p running in the browser via WASM to use the browser's WebRTC | ||
| stack. Though that should only happen after improved WASM support, see below. | ||
|
|
||
| ## Release process | ||
|
|
||
| Status: todo | ||
|
|
||
| Tracking: https://github.com/libp2p/rust-libp2p/issues/2902 | ||
|
|
||
| Dependencies: | ||
|
|
||
| Dependents: | ||
|
|
||
| I think we are doing a decent job at releasing often. That said, automating this will free up | ||
| contributor time (less work on PRs), maintainer time (less work on releases) and overall increase | ||
| release frequency (better for users). | ||
|
|
||
| ## Refactor event handling in `Swarm` | ||
|
|
||
| Status: In progress | ||
|
|
||
| Tracking: https://github.com/libp2p/rust-libp2p/issues/2832 | ||
|
|
||
| Dependencies: | ||
|
|
||
| Dependents: | ||
|
|
||
| - [Cross behaviour communication](#cross-behaviour-communication) | ||
|
|
||
| More specifically replace the `inject_*` methods on `NetworkBehaviour` and `ConnectionHandler` with | ||
| consolidated `on_*_event` handlers. See https://github.com/libp2p/rust-libp2p/issues/2832 and | ||
| https://github.com/libp2p/rust-libp2p/pull/2867 for details. | ||
|
|
||
| While a rather small change, this will make using rust-libp2p easier. In my eyes this is a | ||
| requirement for generic connection management and cross behaviour communication as either would | ||
| otherwise introduce too much complexity. | ||
|
|
||
| ## Cross Behaviour communication | ||
|
|
||
| Status: todo | ||
|
|
||
| Tracking: https://github.com/libp2p/rust-libp2p/issues/2680 | ||
|
|
||
| Dependencies: | ||
|
|
||
| - [Refactor event handling](#refactor-event-handling-in-swarm) | ||
|
|
||
| Dependents: | ||
|
|
||
| - [Kademlia client mode](#kademlia-client-mode) | ||
|
|
||
| ## swarm/handler: Decouple ConnectionHandler from {In,Out}boundUpgrade #2863 | ||
|
|
||
| Status: todo | ||
|
|
||
| Tracking: https://github.com/libp2p/rust-libp2p/issues/2863 | ||
|
|
||
| Dependencies: | ||
|
|
||
| Dependents: | ||
|
|
||
| I think this will simplify existing implementations and lower the learning curve required to get | ||
| started with rust-libp2p. | ||
|
|
||
| ## Generic connection management | ||
|
|
||
| See https://github.com/libp2p/rust-libp2p/issues/2824 for motivation. Given that this will enable | ||
| downstream users to easier integrate with rust-libp2p, I think this counts as a "improving existing | ||
| components" over "introducing a new component". | ||
|
|
||
| First draft is in https://github.com/libp2p/rust-libp2p/pull/2828 | ||
|
|
||
| ## Kademlia efficient querying | ||
|
|
||
| Status: in progress | ||
|
|
||
| Tracking: https://github.com/libp2p/rust-libp2p/pull/2712 | ||
|
|
||
| Dependencies: | ||
|
|
||
| Dependents: | ||
|
|
||
| Users of rust-libp2p like [iroh](https://github.com/n0-computer/iroh) need this for low latency usage of `libp2p-kad`. | ||
|
|
||
| ## Kademlia client mode | ||
|
|
||
| Status: todo | ||
|
|
||
| Tracking: https://github.com/libp2p/rust-libp2p/issues/2032 | ||
|
|
||
| Dependencies: | ||
|
|
||
| - [Cross behaviour communication](#cross-behaviour-communication) | ||
|
|
||
| Dependents: | ||
|
|
||
| ## Hole punching | ||
|
|
||
| Status: todo | ||
|
|
||
| Dependencies: | ||
|
|
||
| Dependents: | ||
|
|
||
| We released hole punching support with [rust-libp2p | ||
| `v0.43.0`](https://github.com/libp2p/rust-libp2p/releases/tag/v0.43.0), see also | ||
| https://github.com/libp2p/rust-libp2p/issues/2052. We are currently collecting data via the | ||
| [punchr](https://github.com/dennis-tra/punchr) project on the hole punching success rate. See also | ||
| [call for | ||
| action](https://discuss.libp2p.io/t/decentralized-nat-hole-punching-measurement-campaign/1616) in | ||
| case you want to help. Based on this data we will likely find many optimizations we can do to our | ||
| hole punching stack. | ||
|
|
||
| ## Streaming response protocol aka. the ultimate escape hatch | ||
|
|
||
| Status: todo | ||
|
|
||
| Tracking: https://github.com/libp2p/rust-libp2p/issues/2657 | ||
|
|
||
| rust-libp2p is very opinionated on how to write peer-to-peer protocols. There are many good reasons | ||
| for this, and I think we should not change directions here. That said, the ultimate escape hatch - | ||
| allowing users to create a stream and do whatever they want with it - will make it easier for | ||
| newcomers to get started. | ||
|
|
||
| ## Improved WASM support | ||
|
|
||
| Status: todo | ||
|
|
||
| Tracking: https://github.com/libp2p/rust-libp2p/issues/2617 | ||
|
|
||
| Dependencies: | ||
|
|
||
| Dependents: | ||
|
|
||
| - WebRTC browser-to-browser and browser side | ||
|
|
||
| This opens rust-libp2p to hole new set of use-cases. | ||
|
|
||
| ## Muxer handshake optimization | ||
|
|
||
| Status: todo | ||
|
|
||
| Tracking: https://github.com/libp2p/rust-libp2p/issues/2994 | ||
|
|
||
| I suggest we do not prioritize this. On the performance end, investing into QUIC support seems like | ||
| the better bet. Long term this is a wonderful improvement, likely very much appreciated by users | ||
| though not thus far demanded. | ||
|
|
||
| ## Bitswap implementation | ||
|
|
||
| Status: todo | ||
|
|
||
| Tracking: https://github.com/libp2p/rust-libp2p/issues/2632 | ||
|
|
||
| I think this is a common component that many users need to build peer-to-peer applications. In | ||
| addition, it is very performance critical and thus likely challenges many of our existing designs in | ||
| rust-libp2p. | ||
|
|
||
| I would prioritize it below [Muxer handshake optimization](#muxer-handshake-optimization) following | ||
| the convention of improving existing components over introducing new ones. Users have and can | ||
| implement their own implementations and are thus not blocked on the rust-libp2p project. | ||
|
|
||
| ## WebTransport | ||
|
|
||
| Status: todo | ||
|
|
||
| Tracking: https://github.com/libp2p/rust-libp2p/issues/2993 | ||
|
|
||
| Dependencies: | ||
|
|
||
| - [QUIC](#quic-support) | ||
|
|
||
| Dependents: | ||
|
|
||
| A WebTransport implementation in rust-libp2p will enable browsers to connect to rust-libp2p nodes | ||
| where the latter only have a self-signed TLS certificate. Compared to WebRTC, this would likely be | ||
| more performant. It is dependent on QUIC support in rust-libp2p. Given that we will support WebRTC | ||
| (browser-to-server) this is not a high priority. |