Date: 2022-10-20
Status: Accepted
Notes: Internal js-libp2p stakeholders have aligned on this roadmap. Please add any feedback or questions in:
https://github.com/libp2p/js-libp2p/issues/1438
We, the maintainers, are committed to upholding libp2p's shared core tenets and ensuring js-libp2p is: Secure, Stable, Specified, and Performant.
Roadmap items in this document were sourced in part from the overarching libp2p project roadmap.
This document consists of two sections: Milestones and the Appendix
Milestones is our best educated guess (not a hard commitment) around when we plan to ship the key features. Where possible projects are broken down into discrete sub-projects e.g. project "A" may contain two sub-projects: A.1 and A.2
A project is signified as "complete" once all of it's sub-projects are shipped.
The Appendix section describes a project's high-level motivation, goals, and lists sub-projects.
Each Appendix header is linked to a GitHub Epic. Latest information on progress can be found in the Epics and child issues.
The "Definition of Done" for projects/sub-projects that involve writing new protocols/ modify existing ones usually consist of the following:
- If a specification change is required:
- Spec is merged and classified as "Candidate Recommendation"
- (by virtue of the above) At least one major reference implementation exists
- 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.)
- Public documentation (on docs.libp2p.io) exists
Supporting projects (such as testing or benchmarking) may have different criteria.
As mentioned in our 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 and the testground/testground roadmap. Our major priorities in Q4’22 and Q1’23 are:
- interoperability testing (across implementations & versions and between transports, muxers, & security protocols)
- add a browser environment test harness to support testing browser features
- performance benchmark js-libp2p using Testground (create a benchmark suite to run in CI)
- test DHT Server Mode at scale (testbed of at least >20 nodes; ideally 100/1000+) in Testground
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 maintainers co-own these efforts with the go-libp2p, rust-libp2p, and Testground maintainers.
- ➡️ test-plans/Interop tests for all existing/developing transports
- ➡️ test-plans/Benchmarking using nix-builders
- B.4 🥊 Hole Punching
- 🎉 Estimated Project Completion
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.
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.
1. WebTransport
Implementation of WebTransport in js-libp2p. Allows for interoperability with go-libp2p.
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.
Even though this use case is made possible by webrtc-star and 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.
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% of the network was undialable.
Goal: Implement Decentralized Hole Punching in js-libp2p and bring it to parity with the Go and Rust implementations.
1. AutoNat
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.
Hole punching is more reliable with UDP (therefore QUIC) than TCP. This requires adding support for QUIC in js-libp2p. There is some work being done here to add support in node.js which we depend on.
Use DCUtR to synchronize hole punching
Why: Though we already expose per-component metrics in js-libp2p, the overhead of recording metrics is high (excessive object allocation per metric to record). This will be helpful to our users who record metrics on the order of thousands/second.
Goal: We make the lives of js-libp2p easier by adding an improved metrics API.
Create a ergonomic, generalized metrics recording interface which addresses current allocation overhead and duplication of information. Do not bloat the browser bundle with prom-client.