List view
# The Vision Enhance the robustness and fault tolerance of the WebRTC protocol. WebRTC serves as an alternative to the WebSocket transport layer, enabling lightweight client connectivity. The goal is to establish seamless connectivity between lightweight clients (e.g., https://github.com/smol-dot/smoldot/issues/1806) and substrate-based chains over the WebRTC transport layer. # The Plan We need to focus on the following key areas: - Ensuring proper implementation of the specification and maintaining smoldot connectivity - Analyzing and optimizing memory usage to eliminate any potential memory leaks and reduce unnecessary cloning - Implementing backpressure handling within the WebRTC layer - Exposing detailed transport layer metrics - Expanding and improving our testing scenarios
Due by December 25, 2025•0/3 issues closed# The Vision Enhance the robustness and fault tolerance of the QUIC protocol. QUIC is a modern transport layer protocol that offers: - Connection establishment with a single RTT, compared to the three RTTs required by traditional TCP - Native encryption with TLS for secure connections - Built-in multiplexing for improved efficiency The goal is to make QUIC the default transport layer for substrate-based chains running litep2p. # The Plan To achieve this, we need to focus on the following: - Updating the Quinn dependency to the latest API to address performance issues and apply bug fixes - Analyzing memory usage to eliminate leaks and minimize unnecessary cloning - Exposing transport layer metrics for better monitoring and analysis
Due by June 1, 2027•0/1 issues closed# The Vision Enhance the performance and reliability of the litep2p Kademlia implementation to discover nodes faster. The objective is to close the performance gap between libp2p and litep2p in terms of peer discovery speed. Currently, litep2p is slower (3-4 times on synthetic benchmarks) at discovering peers compared to libp2p. # The Plan To achieve this, several improvements are required: - Refactor the Kademlia engine to transition to an event-driven implementation (cc https://github.com/paritytech/litep2p/pull/306) - Retain only reachable addresses in the DHT or utilize the transport manager to extract peer addresses - Return more than the current limit of 20 closest peers in response to queries - Provide intermediate KAD record responses, not just upon query completion, to fac
Due by July 1, 2028•0/1 issues closed# The Vision Improve the robustness and fault-tolerance of the litep2p crate and bring the crate to a higher level of maturity. The goal is to stabilize the litep2p and use it as the default backend of Substrate-based chains. ### The Plan To achieve this, we'll focus our efforts on: - Feature Completeness - Implement missing features (validate ping payloads, generate unique random ping payloads, ensure kad records TTL) - Robustness - Ensure core code logic does not panic upon unexpected/malicious user behaviors, panics, unwraps, undocumented expects, array indexing without length validation etc - Fix incorrect functionality and divergences from the [libp2p specification](https://github.com/libp2p/specs) - Repair bugs and limit the surface of race conditions - Maintenance: keep the code simple - Avoid code duplicates (transport layer) - Coherent APIs and errors - Adopt rust clippy and best practices - Improve and add documentation - Performance Improvements - Avoid unnecessary clones - Improve the query engine - Analyze memory and CPU consumption - Testing - increase code coverage by unit-testing sensitive components (multiselect / noise, kad etc) - improve our integration testing scenarios - add fuzzing - create a plan for continuous testing and triaging in our test stack and keep track of triage reports --- Corresponding tracking issue for more details: - https://github.com/paritytech/litep2p/issues/140
Overdue by 27 day(s)•Due by June 30, 2025•1/1 issues closed