This roadmap document contains the themes upon which maintainer effort will be concentrated on in 2024/25.
js-libp2p is deployed in many production environments so to take adoption to the next level we want to really double down on helping these users get the best out of their deployments.
Deploying a public bootstrapper is a great test of the capacity of js-libp2p since it will need to maintain several thousand simultaneous connections and service many DHT RPC requests. Comprehensive metrics and logging will also give us insight into real world usage patterns that can further direct performance optimisations.
- Deploy a bootstrap server that acts as an entry point to the network for DHT clients
- Ship it in the default config of majority libp2p/IPFS implementations
- Publish a dashboard showing usage statistics
Having a view on the internal workings of a js-libp2p node is essential to debugging implementation problems as well as user misconfigurations.
- Add the missing metrics types, e.g. Histograms, Summaries, etc
- Implement metrics consistently across transports
The js-libp2p-devtools plugin is an invaluable resource for debugging a running libp2p node running @libp2p/devtools-metrics.
- Finish UX improvements
- Publish to browser extension stores
- Add DHT capability detection
- Publish as standalone electron app to connect to Node.js/electron/react-native processes using
@libp2p/devtools-metrics
JavaScript is a poor choice of language in which to perform computationally expensive operations. Conveniently the ones we need to do (hashing, signing, verification) are largely implemented in native modules or as part of web browser APIs.
- Profile and benchmark CPU usage
- Use this to drive further optimizations in resource usage
- Documentation refresh - ensure all guides are up to date and follow current best practices
- Revamp getting started guides
- Focus on use cases
- Browser vs Node.js
- Public server vs behind NAT
- Focus on use cases
- Create additional self-directed learning in the style of @libp2p/protocol-adventure
- @libp2p/services-adventure
- @libp2p/dht-adventure
- @libp2p/pubsub-adventure
- @libp2p/peer-discovery-adventure
- Link the adventure modules into a syllabus
- Publish browser based versions using protoschool or https://tutorialkit.dev/
Browsers remain the single most challenging environment in which to deploy truly decentralized applications and most of the issues are related to the poor connectivity options presented to browsers by the rest of the network.
IP Shipyard have recently acquired the ability to create wildcard ACME certificates under the libp2p.direct
domain. This feature is being enabled in ipfs/kubo#10521
JS should implement a similar extension to the @libp2p/websocket
transport to allow config-free SSL encryption.
When a browser connects to a WebSocket listener they can only connect over TLS. We then apply noise encryption as well which means everything is encrypted twice which is inefficient.
We should be able to use the noise handshake mechanism to ensure the remote has the private key corresponding to it's public key, then use the browser's TLS implementation to prevent eavesdropping.
The specification is in progress the milestone is to ship a POC.
There's a decent chance the Node.js QUIC implementation is not going to be exposed to userland, but we need this to have compatibility with other libp2p implementations.
https://github.com/ChainSafe/js-libp2p-quic is in-progress to add QUIC support via a native module that uses the Rust implementation.
A long-lived PR is open that adds WebTransport support via the @fails-components/webtransport module, however it's blocked on spec incompatibilities.
We can either resolve these incompatibilities, implement WebTransport on top of https://github.com/ChainSafe/js-libp2p-quic, or perhaps Node.js will finally ship HTTP3 support and WebTransport, whichever is most expedient.
Another long-lived PR adds support for a WebRTC Direct listener to Node.js.
It's currently blocked on a number of PRs that require the input of upstream maintainers (see linked issues in #2583). We will continue to encourage the maintainers of these libraries to give feedback and ultimately merge those PRs but we may need to publish forks in the interim.