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

ROADMAP.md

@@ -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 -->
+## Generic connection management
-  - [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)
 
-### 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 |
+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
-| Connectivity | Done   | Q4/2022           | https://github.com/libp2p/rust-libp2p/issues/2883 | https://github.com/libp2p/test-plans/issues/53 |            |
+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
+First draft is in https://github.com/libp2p/rust-libp2p/pull/2828
-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.
 
 ## 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.