fluencelabs/rust-libp2p
1
0
Fork 0
mirror of https://github.com/fluencelabs/rust-libp2p synced 2025-06-27 08:41:36 +00:00
Code Issues Projects Releases Wiki Activity

docs(roadmap): Update done projects and reprioritize (#3467)

Browse Source
This commit is contained in:
Max Inden
2023-02-19 18:40:32 +01:00
committed by GitHub
parent 57b6605e71
commit 0f4930f92b
1 changed files with 57 additions and 94 deletions
Download Patch File Download Diff File Expand all files Collapse all files

151
ROADMAP.md
View File

@ -1,4 +1,4 @@
# rust-libp2p Roadmap <!-- omit in toc -->
# rust-libp2p Roadmap
Below is a high level roadmap for the rust-libp2p project. Items are ordered by priority (high to
low).
@ -8,45 +8,17 @@ This is a living document. Input is always welcome e.g. via GitHub issues or pul
This is the roadmap of the Rust implementation of libp2p. See also the [general libp2p project
roadmap](https://github.com/libp2p/specs/blob/master/ROADMAP.md).
## Table of Contents <!-- omit in toc -->
- [QUIC support](#quic-support)
- [WebRTC support (browser-to-server)](#webrtc-support-browser-to-server)
- [Cross Behaviour communication](#cross-behaviour-communication)
- [Generic connection management](#generic-connection-management)
- [Kademlia efficient querying](#kademlia-efficient-querying)
- [Kademlia client mode](#kademlia-client-mode)
- [Optimize Hole punching](#optimize-hole-punching)
- [Streaming response protocol aka. the ultimate escape hatch](#streaming-response-protocol-aka-the-ultimate-escape-hatch)
- [WebRTC support (browser-to-browser)](#webrtc-support-browser-to-browser)
- [Improved Wasm support](#improved-wasm-support)
- [Handshake optimizations](#handshake-optimizations)
- [Bitswap implementation](#bitswap-implementation)
- [WebTransport](#webtransport)
## Generic connection management
### Alpha QUIC support
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
|----------------------|-------------|-------------------|---------------------------------------------------|--------------|------------|
| Developer Ergonomics | in progress | Q1/2023 | https://github.com/libp2p/rust-libp2p/issues/2824 | | |
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
|--------------|--------|-------------------|---------------------------------------------------|------------------------------------------------|------------|
| Connectivity | Done | Q4/2022 | https://github.com/libp2p/rust-libp2p/issues/2883 | https://github.com/libp2p/test-plans/issues/53 | |
Today connection management functionality in rust-libp2p is limited. Building abstractions on top is
cumbersome and inefficient. See https://github.com/libp2p/rust-libp2p/issues/2824. Making connection
management generic allows users to build advanced and efficient abstractions on top of rust-libp2p
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.
## WebRTC support (browser-to-server)
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
|--------------|--------|-------------------|------------------------------------------|------------------------------------------------|-------------------------------------------------------------------|
| Connectivity | Done | Q4/2022 | https://github.com/libp2p/specs/pull/412 | https://github.com/libp2p/test-plans/pull/100 | [WebRTC (browser-to-browser)](#webrtc-support-browser-to-browser) |
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.
First draft is in https://github.com/libp2p/rust-libp2p/pull/2828
## Cross Behaviour communication
@ -65,36 +37,6 @@ protocols) between `NetworkBehaviour` implementations.
Long term we might consider a generic approach for `NetworkBehaviours` to exchange data. Though that
would deserve its own roadmap item.
## Generic connection management
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
|----------------------|--------|-------------------|---------------------------------------------------|--------------|------------|
| Developer Ergonomics | todo | Q1/2023 | https://github.com/libp2p/rust-libp2p/issues/2824 | | |
Today connection management functionality in rust-libp2p is limited. Building abstractions on top is
cumbersome and inefficient. See https://github.com/libp2p/rust-libp2p/issues/2824. Making connection
management generic allows users to build advanced and efficient abstractions on top of rust-libp2p
First draft is in https://github.com/libp2p/rust-libp2p/pull/2828
## QUIC - evaluate and move to quinn
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
|--------------|--------|-------------------|---------------------------------------------------|--------------|------------|
| Connectivity | todo | Q1/2023 | https://github.com/libp2p/rust-libp2p/issues/2883 | | |
We added alpha support for QUIC in Q4/2022 wrapping `quinn-proto`. Evaluate using `quinn` directly, replacing the wrapper.
## Kademlia efficient querying
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
|--------------|-------------|-------------------|-------------------------------------------------|--------------|------------|
| Optimization | done | Q1/2023 | https://github.com/libp2p/rust-libp2p/pull/2712 | | |
Users of rust-libp2p like [iroh](https://github.com/n0-computer/iroh) need this for low latency
usage of `libp2p-kad`. The rust-libp2p maintainers can pick this up unless iroh folks finish the
work before that.
## Kademlia client mode
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
@ -104,11 +46,19 @@ work before that.
Kademlia client mode will enhance routing table health and thus have a positive impact on all
Kademlia operations.
## QUIC - evaluate and move to quinn
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
|--------------|--------|-------------------|---------------------------------------------------|--------------|------------|
| Connectivity | todo | Q2/2023 | https://github.com/libp2p/rust-libp2p/issues/2883 | | |
We added alpha support for QUIC in Q4/2022 wrapping `quinn-proto`. Evaluate using `quinn` directly, replacing the wrapper.
## Optimize Hole punching
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
|--------------|--------|-------------------|----------|--------------|------------|
| Optimization | todo | Q1/2023 | | | |
| Optimization | todo | Q2/2023 | | | |
We released hole punching support with [rust-libp2p
`v0.43.0`](https://github.com/libp2p/rust-libp2p/releases/tag/v0.43.0), see also
@ -119,22 +69,11 @@ action](https://discuss.libp2p.io/t/decentralized-nat-hole-punching-measurement-
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
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
|----------------------|--------|-------------------|---------------------------------------------------|--------------|------------|
| Developer ergonomics | todo | Q1/2023 | 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
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
|----------------------|--------|-------------------|---------------------------------------------------|--------------|----------------------------------------------|
| Developer ergonomics | todo | Q2/2023 | https://github.com/libp2p/rust-libp2p/issues/2617 | | [WebRTC](#webrtc-support-browser-to-browser) |
| Developer ergonomics | todo | Q3/2023 | https://github.com/libp2p/rust-libp2p/issues/2617 | | [WebRTC](#webrtc-support-browser-to-browser) |
The project supports Wasm already today, though the developer experience is cumbersome at best.
Properly supporting Wasm opens rust-libp2p to a whole new set of use-cases. I would love for this to
@ -146,25 +85,12 @@ argue that that demand follows this roadmap item and not the other way round.)
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
|--------------|--------|-------------------|--------------------------------------------|-------------------------------------------------------------------------------------------|------------|
| Connectivity | todo | Q2/2023 | https://github.com/libp2p/specs/issues/475 | [Improved WASM support](#improved-wasm-support), https://github.com/libp2p/specs/pull/497 | |
| Connectivity | todo | Q3/2023 | https://github.com/libp2p/specs/issues/475 | [Improved WASM support](#improved-wasm-support), https://github.com/libp2p/specs/pull/497 | |
Once WebRTC for browser-to-server is complete, we can begin work on **browser-to-browser** and complete the WebRTC connectivity story.
We need to improve rust-libp2p's WASM story first.
## Handshake optimizations
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
|--------------|--------|-------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------|--------------|------------|
| Optimization | todo | Q2/2023 | Security protocol in multiaddr https://github.com/libp2p/specs/pull/353 and early muxer negotiation https://github.com/libp2p/rust-libp2p/issues/2994 | | |
Short term, investing into rust-libp2p's QUIC support will likely give us a larger performance win,
thus neither of the two optimizations is planned for 2022. While great to have, it has not been
requested from any rust-libp2p users.
Long term, given that this will give us a great performance gain, we should definitely tackle it. It
also allows us to catch up and thus be consistent with go-libp2p.
## WebTransport
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
@ -175,3 +101,40 @@ A WebTransport implementation in rust-libp2p will enable browsers to connect to
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.
## Done
### Alpha QUIC support
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
|--------------|--------|-------------------|---------------------------------------------------|------------------------------------------------|------------|
| Connectivity | Done | Q4/2022 | https://github.com/libp2p/rust-libp2p/issues/2883 | https://github.com/libp2p/test-plans/issues/53 | |
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.
### WebRTC support (browser-to-server)
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
|--------------|--------|-------------------|------------------------------------------|------------------------------------------------|-------------------------------------------------------------------|
| Connectivity | Done | Q4/2022 | https://github.com/libp2p/specs/pull/412 | https://github.com/libp2p/test-plans/pull/100 | [WebRTC (browser-to-browser)](#webrtc-support-browser-to-browser) |
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.
### Kademlia efficient querying
| Category | Status | Target Completion | Tracking | Dependencies | Dependents |
|--------------|-------------|-------------------|-------------------------------------------------|--------------|------------|
| Optimization | done | Q1/2023 | https://github.com/libp2p/rust-libp2p/pull/2712 | | |
Users of rust-libp2p like [iroh](https://github.com/n0-computer/iroh) need this for low latency
usage of `libp2p-kad`. The rust-libp2p maintainers can pick this up unless iroh folks finish the
work before that.