github
/
go-libp2p
mirror of https://github.com/libp2p/go-libp2p.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
4991 Commits
812 Branches
264 Tags
85 MiB
 
 
Tree: c48e78f073
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'c48e78f073'
${ noResults }
go-libp2p/ROADMAP.md

12 KiB
Raw Blame History

go-libp2p roadmap Q4’22/Q1’23 

Date: 2022-10-20
Status: Accepted
Notes: Internal go-libp2p stakeholders have aligned on this roadmap. Please add any feedback or questions in:
https://github.com/libp2p/go-libp2p/issues/1806

Table of Contents

About the Roadmap

Vision

We, the maintainers, are committed to upholding libp2p's shared core tenets and ensuring go-libp2p is: Secure, Stable, Specified, and Performant.

Roadmap items in this document were sourced in part from the overarching libp2p project roadmap.

Sections

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.

Done criteria

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.

Benchmarking and Testing

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:

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 go-libp2p maintainers co-own these efforts with the js-libp2p, rust-libp2p, and Testground maintainers.

Click here to see the shared Q4’22/Q1’23 testing and benchmarking priorities.

🛣️ Milestones

2022

Early Q4 (October)

Mid Q4 (November)

End of Q4 (December)

2023

Early Q1 (January)

Mid Q1 (February)

End of Q1 (March)

Up Next

📖 Appendix

Projects are listed in descending priority.

A. 📺 Universal Browser Connectivity

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: go-libp2p ships with up-to-date WebTransport and (libp2p-) WebRTC implementations, enabled by default. This allows connections between browsers and public nodes, browsers and non-public nodes, as well as two browsers.

1. WebRTC: Browser to Server

Add support for WebRTC transport in go-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.

2. WebRTC: Browser to Browser

A follow up to A.1 where we will begin the work to specify the semantics of browser to browser connectivity and then implement it in go-libp2p.

3. WebTransport: Update to new draft versions

As the protocol is still under development by IETF and W3C, the go-libp2p implementation needs to follow. We have a dependency on Chrome to support the new draft version of WebTransport protocol. To stay up to date, we will have to move as soon as Chrome ships supports the new draft version.

B. ⚡️ Handshakes at the Speed of Light

Why: Historically, libp2p has been very wasteful when it comes to round trips spent during connection establishment. This is slowing down our users, especially their TTFB (time to first byte) metrics.

Goal: go-libp2p optimizes its handshake latency up to the point where only increasing the speed of light would lead to further speedups. In particular, this means:

1. Early Muxer Negotiation

Cutting off the 1 RTT wasted on muxer negotiation

2. Adding security protocol

Cutting off the 1 RTT wasted on security protocol negotiation by including the security protocol in the multiaddr

3. 0.5 RTT data optimization

Using 0.5-RTT data (for TLS) / a Noise Extension to ship the list of Identify protocols, cutting of 1 RTT that many protocols spend waiting on IdentifyWait

C. 🧠 Smart Dialing

Why: Having a large list of transports to pick from is great. Having an advanced stack that can dial all of them is even greater. But dialing all of them at the same time wastes our, the network’s and the peer’s resources.

Goal: When given a list of multiaddrs of a peer, go-libp2p is smart enough to pick the address that results in the most performant connection (for example, preferring QUIC over TCP), while also picking the address such that maximizes the likelihood of a successful handshake.

1. Happy Eyeballs

Implement some kind of “Happy-Eyeballs” style prioritization among all supported transports

2. QUIC Blackhole detector

Detection of blackholes, especially relevant to detect UDP (QUIC) blackholing

3. RTT estimation

Estimation of the expected RTT of a connection based on two nodes’ IP addresses, so that Happy Eyeballs Timeouts can be set dynamically

D. 📊 Comprehensive Metrics

Why: For far too long, go-libp2p has been a black box. This has hurt us many times, by allowing trivial bugs to go undetected for a long time (example). Having metrics will allow us to track the impact of performance improvements we make over time.

Goal: Export a wider set of metrics across go-libp2p components and enable node operators to monitor their nodes in production. Optionally provide a sample Grafana dashboard similar to the resource manager dashboard.

How: This will look similar to how we already expose resource manager metrics. Metrics can be added incrementally for libp2p’s components. First milestone is having metrics for the swarm.

E. 📢 Judicious Address Advertisements

Why: A node that advertises lots of addresses hurts itself. Other nodes will have to try dialing a lot of addresses before they find one that actually works, dramatically increasing handshake latencies.

Goal: Nodes only advertise addresses that they are actually reachable at.

How: Unfortunately, the AutoNAT protocol can’t be used to probe the reachability of any particular address (especially due to a bug in the go-libp2p implementation deployed years ago). Most likely, we need a second version of the AutoNAT protocol.

Related discussion: https://github.com/libp2p/go-libp2p/issues/1480