You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- We strive to ensure that libp2p is reliable & secure for users & applications. We seek to minimize vulnerabilities and act quickly to address issues.
48
+
- Stability
49
+
- We do not break deployed features and maintain cross version compatibility across libp2p releases.
50
+
- Performance
51
+
- We aim to make libp2p as performant as possible and strive to ensure comparable performance to widely used protocols on the Internet. We avoid regressions and performance degradations in new releases.
52
+
34
53
### Sections
35
-
This document consists of two sections: [Milestones](#Milestones) and the [Roadmap Appendix](#Roadmap-Appendix)
54
+
This document consists of two sections: [Milestones](#️-milestones) and the [Appendix](#-appendix)
55
+
56
+
[Milestones](#️-milestones) is our best educated guess (not a hard commitment) around when we plan to ship the key features.
57
+
Where possible projects are broken down into discrete sub-projects e.g. project "A" may contain two sub-projects: A.1 and A.2
36
58
37
-
[Milestones](#Milestones) is our best educated guess (not a hard commitment) around when we plan to ship the key features.
38
-
Where possible we've broken down a project into discrete sub-projects e.g. project "A" (📺 Universal Browser Connectivity) contains three sub-projects and consists of A.1, A.2, and A.3
39
59
A project is signified as "complete" once all of it's sub-projects are shipped.
40
60
41
-
The [Roadmap Appendix](#Roadmap-Appendix) section describes each project in detail and lists its sub-projects (if applicable.) Here you can find the motivation for each project and goals.
61
+
The [Appendix](#-appendix) section describes a project's high-level motivation, goals, and lists sub-projects.
42
62
43
-
We've deep-linked each section header to it's corresponding GitHub Epic. Latest information on the progress of each project there can be found in the Epics and their child issues (as we will make regular updates.)
63
+
Each Appendix header is linked to a GitHub Epic. Latest information on progress can be found in the Epics and child issues.
44
64
45
65
### Done criteria
46
-
Our "Definition of Done" for projects/sub-projects that involve writing new protocols or modifications to existing ones will usually consist of the following:
47
-
-[ ] Spec is merged and classified as "Candidate Recommendation"
48
-
-[ ] (by virtue of the above) At least one major reference implementation exists
66
+
The "Definition of Done" for projects/sub-projects that involve writing new protocols/ modify existing ones usually consist of the following:
67
+
- If a specification change is required:
68
+
-[ ] Spec is merged and classified as "Candidate Recommendation"
69
+
-[ ] (by virtue of the above) At least one major reference implementation exists
49
70
-[ ] A well established testing criteria is met (defined at the outset of the project including but not limited to testing via Testground, compatibility tests with other implementations in the Release process, etc.)
50
71
-[ ] Public documentation (on docs.libp2p.io) exists
51
72
52
-
Others supporting projects (like testing or benchmarking) will have different criteria.
73
+
Supporting projects (such as testing or benchmarking) may have different criteria.
74
+
75
+
### Benchmarking and Testing
76
+
As mentioned in our [vision](#vision), performance and stability are core libp2p tenets. Rigorous benchmarking and testing help us uphold them. Related projects are listed in the [libp2p/test-plans Roadmap](https://github.com/libp2p/test-plans/pull/44). Our major priorities in Q4’22 and Q1’23 are:
77
+
-[interoperability testing](https://github.com/libp2p/test-plans/issues/53) (across implementations & versions and between transports, muxers, & security protocols)
78
+
-[add a browser environment test harness to support testing browser features](https://github.com/testground/testground/issues/1386)
79
+
- test DHT Server Mode at scale (testbed of at least >20 nodes; ideally 100/1000+) in Testground
80
+
- performance benchmark js-libp2p using Testground (create a benchmark suite to run in CI)
81
+
82
+
These projects are parallel workstreams, weighed equally with roadmap items in this document. Some efforts like interoperability testing have a higher priority than implementation projects. The js-libp2p co-owns these efforts with the go-libp2p, rust-libp2p, and Testground/IPDX teams.
- A.3 📺 Universal Browser Connectivity - **WebRTC for Browser to Browser**
110
+
### Up Next
111
+
-[A.3 📺 WebRTC: Browser to Browser](#3-webrtc-browser-to-browser)
83
112
84
-
## Roadmap Appendix
113
+
## 📖 Appendix
85
114
### A. 📺 Universal Browser Connectivity
86
115
<!--- TODO: Link to GitHub Epic -->
87
116
88
117
**Why**: A huge part of “the Web” is happening inside the browser. As a universal p2p networking stack, libp2p needs to be able to offer solutions for browser users.
89
118
90
119
**Goal**: js-libp2p supports both WebTransport and (libp2p-) WebRTC protocols, enabled by default. This allows connections between browsers and public nodes, and eventually between browsers and non-public nodes and in between browser nodes.
91
120
92
-
1.[WebTransport](https://github.com/libp2p/js-libp2p-webtransport/issues/1): Implementation of WebTransport in js-libp2p
93
-
2.[WebRTC for Browser to Server](https://github.com/little-bear-labs/js-libp2p-webrtc/pull/4): This will cover the browsers that don't support WebTransport (most notable is iOS Safari). This is getting close to finalized.
94
-
3. WebRTC for Browser to Browser: Even though this use case is made possible by [webrtc-star](https://github.com/libp2p/js-libp2p-webrtc-star) and [webrtc-direct](https://github.com/libp2p/js-libp2p-webrtc-direct) currently, they are a less than ideal solutions. Both libraries have shortcomings, aren't implemented in other languages, and don't employ newer libp2p advancements such as Circuit Relay v2, DCUtR, and authentication via Noise. Therefore, we want to support WebRTC Browser to Browser as a first class transport in js-libp2p and deprecate the previous libraries. This is beginning to be [specified here](https://github.com/libp2p/specs/pull/412).
Implementation of WebTransport in js-libp2p. Allows for interoperability with go-libp2p.
123
+
#### 2. [WebRTC: Browser to Server](https://github.com/little-bear-labs/js-libp2p-webrtc/pull/4)
124
+
Add support for WebRTC transport in js-libp2p, enabling browser connectivity with servers. This will cover the browsers that don't support WebTransport (most notable is iOS Safari). This is getting close to finalized.
125
+
#### 3. WebRTC: Browser to Browser
126
+
Even though this use case is made possible by [webrtc-star](https://github.com/libp2p/js-libp2p-webrtc-star) and [webrtc-direct](https://github.com/libp2p/js-libp2p-webrtc-direct) currently, they are a less than ideal solutions. Both libraries have shortcomings, aren't implemented in other languages, and don't employ newer libp2p advancements such as Circuit Relay v2, DCUtR, and authentication via Noise. Therefore, we want to support WebRTC Browser to Browser as a first class transport in js-libp2p and deprecate the previous libraries. A follow up to A.2 where we will begin the work to specify the semantics of browser to browser connectivity and then implement it in js-libp2p.
95
127
96
128
### B. 🥊 Decentralized Hole Punching
97
129
<!--- TODO: Link to GitHub Epic -->
98
130
**Why**: P2P networks can have a combination of both public and private nodes. While private nodes can dial nodes on the public Internet, they are unreachable from the outside as they are behind a NAT or a firewall. We need a mechanism to dial them. A [previous DHT crawl found that almost 63%](https://github.com/libp2p/specs/blob/master/ROADMAP.md#-hole-punching-on-tcp-and-quic) of the network was undialable. This project aims to implement Decentralized Hole Punching in js-libp2p and bring it to parity with the Go and Rust implementations.
99
131
100
132
**Goal**:
101
-
1.[AutoNat](https://github.com/libp2p/js-libp2p/issues/1005) - Determine whether a node is public or private (located behind a firewall or a NAT.) This is a dependency for enabling the DHT in server mode by default for projects like js-ipfs.
102
-
2.[Circuit Relay v2](https://github.com/libp2p/js-libp2p/issues/1029) - Connect to, request reservations, and establish a secure relay connection through discovered public relay node.
103
-
3. Add QUIC Transport - Hole punching is [more reliable with UDP](https://www.notion.so/pl-strflt/NAT-Hole-punching-Success-Rate-2022-09-29-Data-Analysis-8e72705ca3cc49ab983bc5e8792e3e98#5b76991da8d24736abd486aa93e85a97) (therefore QUIC) than TCP. This requires adding support for QUIC in js-libp2p. There is some work [being done here](https://github.com/nodejs/node/pull/44325) to add support in node.js which we depend on.
104
-
4. Hole Punching - Use [DCUtR](https://github.com/libp2p/specs/blob/master/relay/DCUtR.md) to synchronize hole punching
105
-
106
-
107
-
### C. 🧪 Future-proof Testing
108
-
<!--- TODO: Link to GitHub Epic -->
109
-
**Why**: JS support doesn't exist in Testground yet. In addition to the work to get generic JS test runners, we need support in Testground.
110
-
111
-
**Goal**:
112
-
1.[Browser Environment Test Harness](https://github.com/testground/testground/issues/1386): Add a test harness to support testing browser features within a browser environment.
113
-
2. Test DHT Server Mode at scale: Requires adding support for js-libp2p in Testground. Server mode is implemented but we need a way to ensure it works and to do that we need a very large network testbed (>20 node at least; ideally 100/1000+.)
Determine whether a node is public or private (located behind a firewall or a NAT.) This is a dependency for enabling the DHT in server mode by default for projects like js-ipfs.
Connect to, request reservations, and establish a secure relay connection through discovered public relay node.
137
+
#### 3. Add QUIC Transport
138
+
Hole punching is [more reliable with UDP](https://www.notion.so/pl-strflt/NAT-Hole-punching-Success-Rate-2022-09-29-Data-Analysis-8e72705ca3cc49ab983bc5e8792e3e98#5b76991da8d24736abd486aa93e85a97) (therefore QUIC) than TCP. This requires adding support for QUIC in js-libp2p. There is some work [being done here](https://github.com/nodejs/node/pull/44325) to add support in node.js which we depend on.
139
+
#### 4. Hole Punching
140
+
Use [DCUtR](https://github.com/libp2p/specs/blob/master/relay/DCUtR.md) to synchronize hole punching
141
+
142
+
### C. 🔮 Future-proof Observability
143
+
***Why*** We release new versions of js-libp2p and we should analyze/profile each version for regressions. Furthrmore, we already expose [per-component metrics](https://github.com/libp2p/js-libp2p/issues/1060) in js-libp2p, we can improve this by adding introspection.
144
+
145
+
***Goal***
146
+
For each js-libp2p release, we ensure transfer performance does not degrade. We can observe/get introspective data for a running js-libp2p instance.
147
+
Introduce an introspection protocol to js-libp2p, so we can hook into the [observer-toolkit](https://github.com/libp2p/observer-toolkit).
148
+
149
+
#### 1. Benchmark transfer performance in CI
150
+
Add [js-libp2p-transfer-performance](https://github.com/ipfs-shipyard/js-libp2p-transfer-performance) to a CI job to benchmark transfer times across releases.
151
+
#### 2. [Add introspection to js-libp2p](https://github.com/libp2p/js-libp2p-daemon/pull/45)
152
+
Add an introspection protocol for js-libp2p such that users of js-ipfs can utilize observer-toolkit to visualize introspection data.
153
+
154
+
## libp2p Project Roadmap
116
155
Roadmap items in this document were sourced from our the overarching libp2p project roadmap: https://github.com/libp2p/specs/blob/master/ROADMAP.md
0 commit comments