Refactoring the libp2p Test Framework: A Fresh Start

The libp2p Foundation — Wed, 28 Jan 2026 00:00:00 +0000

Why a Complete Rewrite?</a></h2>
The original test framework was built with TypeScript, Docker Compose, and various npm dependencies. While functional, it presented several challenges:</p>

Complex dependency chains</strong>: Node.js, npm, and Python dependencies created friction for contributors and a perpetual dependency maintenance headache</li>
Platform inconsistencies</strong>: Tests behaved differently across Linux, macOS, and Windows</li>
Limited reproducibility</strong>: Recreating test failures was difficult without considerable effort</li>
Rigid test selection</strong>: Running specific subsets of tests required manual configuration</li>
Slow iteration cycles</strong>: The build and test pipeline was optimized for CI, not local development</li> </ul>
More importantly, 2026 marks a pivotal year for libp2p research efforts focused on scaling and optimization. As we push the boundaries of what's possible with peer-to-peer networking, we need a test framework that can keep pace. Researchers investigating new transport protocols, scaling strategies, and exploring AI-driven dynamic protocols require fast feedback loops, reproducible experiments, and the ability to quickly iterate on implementations across multiple languages. The old framework simply couldn't support the velocity and rigor that this research demands.</p>
We set out to address these issues with a clear set of goals.</p>
The 10 Primary Goals</a></h2>
1. Cross-Platform Support</a></h3>
The new framework runs natively on Linux, macOS, and Windows (via WSL). We've eliminated platform-specific code paths and ensured consistent behavior across all environments. A developer on macOS can reproduce the exact test that failed in CI on Linux.</p>
2. Minimal Dependencies</a></h3>
We reduced dependencies to the essentials:</p>

Bash 4.0+</strong> (for associative arrays and modern shell features)</li>
Docker 20.10+</strong> with Docker Compose v2</li>
yq 4.0+</strong> (for YAML processing)</li>
Git 2.0+</strong></li> </ul>
No Node.js. No npm. No Python. No pip. Just standard tools available on any development machine.</p>
3. Reproducible Testing in CI/CD and Local Environments</a></h3>
The framework is optimized for both CI pipelines and local development. You can run the same commands locally that CI runs, with identical results. Quick feedback loops enable faster iteration. The snapshot capability supports capturing the entire test setup—including inputs, docker images, and environment variables—into a downloadable artifact that can be unpacked locally and re-run with a single command, fully reproducing the exact same test pass that was executed on the CI/CD infrastructure. This local reproducibility greatly increases the velocity of developers debugging tests and fixing compatibility issues. It also helps with optimization work by recreating the same conditions locally that led to the measured results in the CI/CD environment.</p>
4. Follow CI/CD and Programming Conventions</a></h3>
We adhere to standard patterns: clear exit codes, structured logging to stderr, machine-readable output to stdout, and conventional command-line arguments. The barrier to entry is low for anyone familiar with shell scripting.</p>
5. Code Reusability via Shared Library</a></h3>
The `lib/</code> directory contains 19 reusable shell scripts (~4,000+ lines) that provide common functionality:</p>`
`Filter engine</strong> with alias expansion and negation</li> Image building</strong> for GitHub, local, and browser sources</li> Caching</strong> with content-addressed keys</li> Test execution</strong> coordination with Redis</li>`Output formatting</strong> for consistent terminal UI</li> </ul> Each test suite (perf, transport, hole-punch) imports these libraries, ensuring consistency and reducing duplication.</p> 6. Aggressive Caching</a></h3> Three levels of caching dramatically improve performance:</p> Cache Type</th> Miss</th> Hit</th> Speedup</th></tr></thead> Test matrix</td> 2-5s</td> 50-200ms</td> 10-100x</td></tr> GitHub snapshots</td> 5-30s</td> 1-2s</td> 5-15x</td></tr> Docker images</td> 30-300s</td> 0.1s</td> 300-3000x</td></tr> </tbody></table> The test matrix cache uses a content-addressed key computed from images.yaml</code> and all filter parameters. Change a filter, get a new key. Same filters, same cached matrix.</p> 7. Fine-Grained Filtering</a></h3> The two-stage filtering model provides precise control:</p> Stage 1 (SELECT)</strong>: Narrow from the complete list</p> ./run.sh</span> --impl-select</span> "~rust|~go"</span> # Only rust and go implementations</span></span></code></pre> Stage 2 (IGNORE)</strong>: Remove from selected set</p> ./run.sh</span> --impl-ignore</span> "experimental"</span> # Exclude experimental versions</span></span></code></pre> Filter dimensions include:</p> --impl-select/ignore</code>: Filter implementations</li> --transport-select/ignore</code>: Filter transports (tcp, quic-v1, ws, etc.)</li> --secure-select/ignore</code>: Filter secure channels (noise, tls)</li> --muxer-select/ignore</code>: Filter muxers (yamux, mplex)</li> --test-select/ignore</code>: Filter by test name pattern</li> </ul> Aliases make common patterns easy:</p> ./run.sh</span> --impl-select</span> "~rust"</span> # Expands to rust-v0.56|rust-v0.55|rust-v0.54|...</span></span> ./run.sh</span> --impl-ignore</span> "!~rust"</span> # Everything NOT matching rust (negation)</span></span></code></pre>8. YAML Configuration with Comments</a></h3> All configuration uses YAML files with extensive comments:</p> images.yaml</strong>: Implementation definitions with versions, transports, and sources</li> inputs.yaml</strong>: Auto-generated capture of all test parameters</li> test-matrix.yaml</strong>: Generated test combinations with metadata</li> </ul> Human-readable configuration lowers the barrier to understanding and modification.</p> 9. Local and Remote Test Applications with Patching</a></h3> Testing local changes doesn't require forking repositories. The patching strategy lets you:</p> Clone an implementation locally</li> Make your changes</li> Generate a patch file</li> Reference it in images.yaml</code></li> </ol> The framework downloads the upstream snapshot, applies your patch, and builds the image. See our Local Testing Strategies</a> guide for details.</p> 10. Docker for Arbitrary Network Layouts</a></h3> Each test suite uses Docker to create isolated, reproducible network environments:</p> Transport tests</strong>: Simple dialer/listener on a shared network</li> Performance tests</strong>: Controlled environment for accurate measurements</li> Hole-punch tests</strong>: Complex topology with NAT routers, relay servers, and isolated LANs</li> </ul> The hole-punch tests create five containers per test with three networks, simulating realistic NAT traversal scenarios.</p> What Changed: By the Numbers</a></h2> Between commits f58b7472</code> and d6e5bea1</code>:</p> 196 commits</strong> of focused development</li> 284 files</strong> changed</li> +73,488 insertions</strong>, -49,912 deletions</strong></li> 11 new documentation files</strong> (~6,000+ lines)</li> Migration from TypeScript to ~4,000+ lines</strong> of shared bash libraries</li> </ul> The result is a simpler, more maintainable codebase that's easier to understand and extend.</p> Test Suites</a></h2> Performance Benchmarking (perf/</code>)</a></h3> Measures the overhead that libp2p introduces:</p> Upload throughput</strong> (bytes/second)</li> Download throughput</strong> (bytes/second)</li> Latency</strong> with statistical distribution (min, q1, median, q3, max, outliers)</li> </ul> Baseline tests against iperf, raw QUIC, and HTTPS establish reference points for measuring libp2p overhead.</p> Transport Interoperability (transport/</code>)</a></h3> Verifies cross-implementation compatibility:</p> Dial success/failure</strong></li> Handshake latency</strong></li> Ping latency</strong></li> </ul> Tests run in parallel (default: CPU core count) for fast feedback on large test matrices.</p> Hole-Punch NAT Traversal (hole-punch/</code>)</a></h3> Tests the DCUtR protocol for establishing direct connections through NAT:</p> Realistic network topology with NAT routers</li> Relay server coordination</li> Direct connection verification</li> </ul> Each test gets unique subnets calculated from the test key, enabling parallel execution without network conflicts.</p> Implementation Coverage</a></h2> The test suite covers implementations in:</p> Rust</strong> (rust-libp2p)</li> Go</strong> (go-libp2p)</li> JavaScript</strong> (js-libp2p v1.x, v2.x, v3.x)</li> Python</strong> (py-libp2p)</li> Nim</strong> (nim-libp2p)</li> JVM</strong> (jvm-libp2p)</li> C</strong> (c-libp2p)</li> .NET</strong> (dotnet-libp2p)</li> Zig</strong> (zig-libp2p)</li> Browsers</strong> (via WebRTC and WebTransport)</li> </ul> With 40+ implementation variations across different versions and configurations.</p> Getting Started</a></h2> Check Dependencies</a></h3> cd</span> perf</span></span> ./run.sh</span> --check-deps</span></span></code></pre>List Available Implementations</a></h3> ./run.sh</span> --list-images</span></span></code></pre>Preview Test Selection</a></h3> ./run.sh</span> --impl-select</span> "~rust"</span> --list-tests</span></span></code></pre>Run Tests</a></h3> # Performance tests with rust implementations</span></span> cd</span> perf</span></span> ./run.sh</span> --impl-select</span> "~rust"</span> --iterations 5</span></span> </span> # Transport interoperability</span></span> cd</span> transport</span></span> ./run.sh</span> --impl-select</span> "~rust|~go"</span></span> </span> # Hole-punch tests</span></span> cd</span> hole-punch</span></span> ./run.sh</span> --impl-select</span> "~rust"</span></span></code></pre>Create Reproducible Snapshots</a></h3> ./run.sh</span> --impl-select</span> "~rust"</span> --snapshot</span></span></code></pre> The snapshot captures everything needed to reproduce the test run.</p> Reproducibility with inputs.yaml</a></h2> Every test run generates an inputs.yaml</code> file capturing:</p> All command-line arguments</li> Environment variables</li> Filter settings</li> Test-specific parameters</li> </ul> To reproduce a previous run:</p> cp</span> /srv/cache/test-run/perf-abc12345/inputs.yaml ./</span></span> ./run.sh</span></span></code></pre> The framework reads inputs.yaml</code> at startup and applies the same configuration.</p> Future Work</a></h2> Remote host testing</strong> via Docker Swarm for real network conditions</li> Additional test suites</strong> for other protocols</li> Improved reporting</strong> with historical comparisons</li> Community contributions</strong> welcome for new implementations</li> </ul> Resources</a></h2> test-plans repository</a></li> Local Testing Strategies</a> - Installation, filtering, and patching</li> Write a Performance Test Application</a></li> Write a Transport Test Application</a></li> Write a Hole-Punch Test Application</a></li> </ul> We believe this rewrite significantly improves the developer experience for testing libp2p implementations. The combination of cross-platform support, powerful filtering, reproducibility, and comprehensive documentation makes it easier than ever to ensure your libp2p implementation works correctly with the rest of the ecosystem.</p> Try it out, and let us know what you think!</p> Announcing the release of go-libp2p v0.47 The libp2p Foundation — Sun, 25 Jan 2026 00:00:00 +0000 go-libp2p v0.47</code> has just shipped.</p> A relatively small release. The main changes are dependency updates and a couple of bug fixes. #3435</a> changes autonatv2 reachability logic, which should be a net win for most users.</p> What's Changed</a></h2> fix(autonatv2): secondary addrs inherit reachability from primary by @lidel</a> in #3435</a></li> Update simnet by @MarcoPolo</a> in #3449</a></li> mod tidy test-plans package by @MarcoPolo in #3450</li> fix(basic_host): stream.Close() blocks indefinitely on unresponsive peers by @lidel</a> in #3448</a></li> fix: handle error from mh.Sum in IDFromPublicKey by @MozirDmitriy</a> in #3437</a></li> update webtransport-go to v0.10.0 and quic-go to v0.59.0 by @marten-seemann</a> in #3452</a></li> rcmgr: expose resource limits to Prometheus by @sneaxhuh</a> in #3433</a></li> </ul> New Contributors</a></h2> @MozirDmitriy</a> made their first contribution in #3437</a></li> @sneaxhuh</a> made their first contribution in #3433</a></li> </ul> Full Changelog:</strong> v0.46.0...v0.47.0</a></p> Announcing the tag of py-libp2p v0.5.0 The libp2p Foundation — Sun, 21 Dec 2025 00:00:00 +0000 py-libp2p v0.5.0</code> has just shipped.</p> What's Changed</a></h2> Full Changelog:</strong> v0.4.0...v0.5.0</a></p> Announcing the release of js-libp2p v3.0.0 The libp2p Foundation — Tue, 30 Sep 2025 00:00:00 +0000 libp2p@3.x.x</code> has just shipped, representing our once-yearly roll-up of breaking changes.</p> Let's find out what's changed and why, and how you can upgrade your project to the latest and greatest.</p> What's new?</a></h2> Streams as EventTargets</a></h3> Prior to v3, streams were streaming iterables. This convention has not been adopted outside the libp2p project, which raises the bar for new developers, and leans heavily on promises which can introduce surprising latency to simple operations.</p> As of v3, streams have become EventTargets. These follow a familiar pattern where you attach event listeners for incoming message events and write data synchronously.</p> import</span> { createLibp2p }</span> from</span> 'libp2p'</span></span> import</span> { peerIdFromString }</span> from</span> '@libp2p/peer-id'</span></span> </span> const</span> node</span> = await</span> createLibp2p</span>()</span></span> const</span> peer</span> =</span> peerIdFromString</span>(</span>'123Foo...'</span>)</span></span> const</span> stream</span> = await</span> node.</span>dialProtocol</span>(peer,</span> '/my-protocol/1.0.0'</span>, {</span></span> signal: AbortSignal.</span>timeout</span>(</span>5_000</span>)</span></span> })</span></span> </span> // register a listener for incoming data</span></span> stream.</span>addEventListener</span>(</span>'message'</span>, (</span>evt</span>)</span> =></span> {</span></span> console.</span>info</span>(</span>new</span> TextDecoder</span>().</span>decode</span>(evt.data.</span>subarray</span>()))</span></span> })</span></span> </span> // send some data</span></span> stream.</span>send</span>(</span>new</span> TextEncoder</span>().</span>encode</span>(</span>'hello world'</span>))</span></span></code></pre> Synchronous streams have shown a small increase in throughput and more predictable behavior.</p> Write back pressure</a></h3> Streams can apply back pressure by their .send()</code> method returning false. Once this returns false, the sender should wait for a 'drain'</code> event before continuing:</p> for</span> (</span>const</span> buf</span> of</span> bufs) {</span></span> if</span> (</span>!</span>stream.</span>send</span>(buf)) {</span></span> await</span> pEvent</span>(stream,</span> 'drain'</span>, {</span></span> rejectionEvents: [</span>'close'</span>]</span></span> })</span></span> }</span></span> }</span></span></code></pre>Other improvements</a></h3> Better TypeScript types</li> Improved error handling</li> Performance optimizations</li> </ul> Check out the migration guide</a> for detailed upgrade instructions.</p> Announcing the release of rust-libp2p v0.56 The libp2p Foundation — Sat, 28 Jun 2025 00:00:00 +0000 rust-libp2p v0.56</code> has just shipped.</p> See individual changelogs</a> for details.</p> What's new?</a></h2> Notably, we've removed support for async-std</code> in all crates, as async-std</code> has been discontinued</a>. Users should switch to using tokio instead. For now, we've kept the abstractions for supporting alternative runtimes, although not all parts may be public. Please open an issue if you are planning to support a custom runtime and run into any issues with that..</p> Thanks to everyone who contributed to the release!</p> Announcing AutoTLS: Bridging the Gap Between libp2p and the Web The libp2p Foundation — Thu, 13 Feb 2025 00:00:00 +0000 Interplanetary Shipyard</a> is excited to announce AutoTLS</a>, a new service that automates the issuance of Let's Encrypt wildcard TLS certificates for libp2p nodes.</p> This is a major leap for the libp2p ecosystem, as it allows connectivity between browsers and libp2p nodes using Secure WebSockets, opening up a new class of use cases for libp2p that were previously cumbersome.</p> This blog post explores the use-cases for AutoTLS, challenges of browser-node connectivity, how AutoTLS works, and how it fits into the libp2p project and the browser ecosystem.</p> If you're interested in trying it out, we have an example with go-libp2p and js-libp2p:</p> AutoTLS example for go-libp2p</a></li> AutoTLS example for js-libp2p</a></li> </ul> If you prefer a turn-key implementation:</p> IPFS Kubo</a> >= 0.33: Opt-in via AutoTLS.Enabled</code> configuration flag</a></li> IPFS Desktop</a> >= 0.41: enabled by default</li> Helia</a> >= 5.2.0: enabled by default</li> </ul> Use-cases for AutoTLS</a></h2> Browser-node connectivity is foundational to any libp2p based network or application looking to expand its user base, through web-based clients. Since the libp2p ecosystem exhibits a wide range of network topologies, we've identified a few use-cases that benefit from AutoTLS.</p> The core idea is that AutoTLS enables reliable browser-based clients to connect to libp2p nodes, regardless of the network topology; which improves resilience and opens up a window to more capable browser clients.</p> Blockchains using libp2p, such as Ethereum, Celestia, and Filecoin, could integrate AutoTLS and improve access to chain state for browser-based light clients</a> and wallets. This would promote client-side transaction and state verification.</p> </p> Though it remains to be seen how practical browser-based light clients will be, we're already seeing interest in AutoTLS from the community. For example, AutoTLS has already proven to be instrumental for the Celestia Lumina client implementation</a>, a Rust implementation of Celestia's data availability node, which compiles to WASM. When running in a browser</a>, it can reliably connect to more capable bridge and full Celestia nodes with TLS certificates issued by AutoTLS. What's more, the ProbeLab team</a> has integrated AutoTLS into Ants Watch</a>, which monitors the Celestia DHT, and already have insight into the distribution</a> of browser-based Lumina clients in the network.</p> Another example, which also served as the initial catalyst for AutoTLS, is to enable direct browser retrieval from IPFS nodes, without needing intermediary gateways. The Service Worker Gateway</a> supports discovery and retrieval from AutoTLS-enabled IPFS nodes.</p> With that in mind, let's explore the challenges of browser-node connectivity.</p> Why is browser-node connectivity hard?</a></h2> Historically, the Web relied solely on unencrypted HTTP as the default transport, undermining user privacy and exposing users to MITM attacks. With the advent of TLS, HTTPS, and automated Certificate Authorities like Let's Encrypt, encryption is now the norm. So much so that Chrome warns users "Not secure"</a> when they're visiting a site over an unencrypted HTTP connection, or produce "mixed-content" errors when a page tries to fetch unencrypted subresources.</p> </p> In libp2p, all connections are encrypted</a> by default, using either Noise or TLS.</p> For as long as libp2p has existed, browser-node connectivity has been a challenge. Browsers do not consider libp2p's encryption layer for WebSocket connections as part of "Secure Context</a>", leaving us with browser-negotiated TLS encryption as the only viable option.</p> Up until recently, configuring a libp2p node to be connectable from browsers required additional effort, as node operators had to own and manually configure a domain name and obtain a TLS certificate signed by a certificate authority (CA).</p> Recent investments in WebTransport</a> and WebRTC</a> helped circumvent this problem, by removing the need for CA-signed TLS certificate, but they have their own drawbacks outlined below.</p> Experience has shown that WebSockets are still the most common and reliable way to establish a bidirectional streaming connection from a browser. That's not to say that WebSockets are perfect. Most notably, in libp2p, Secure WebSockets require 5 round trips to establish a connection</a>, no support for backpressure on streams (except for WebSocketStream</code> in Chrome</a>), and Secure WebSockets in libp2p require double encryption</a>, which is inefficient.</p> By comparison, WebTransport requires 3 round trips</a>, which is why we believe WebTransport is well positioned to be the recommended transport for browser-node connectivity, alas, only once WebTransport is stable and widely supported by browsers.</p> How AutoTLS works</a></h2> With AutoTLS, the end result is:</p> Your libp2p node, identified by a PeerID</a>, has a wild card certificate for .<PeerID>.libp2p.direct</code>.</li> The authoritative DNS server of libp2p.direct</code> (part of the AutoTLS service) maps DNS names to your libp2p node's IP addresses statelessly.</li> </ol> Note:</strong> <PeerID></code> is base36 encoded</a> to keep the DNS label length under 63 characters (RFC 1034</a>).</p> </blockquote> With that in mind, let's track back how AutoTLS works starting with Let's Encrypt and ACME.</p> Let's Encrypt and ACME</a></h3> Let's Encrypt is a free, automated, and open certificate authority (CA) service. To obtain a certificate, you need to prove that you control the domain name using a protocol called ACME</a>, which defines a set of challenges that you need to pass to prove that you control the domain name.</p> For example, to obtain a wildcard certificate for .<PeerID>.libp2p.direct</code>, you need to prove that you control the domain name by setting a TXT record at _acme-challenge.<PeerID>.libp2p.direct</code> with a value that matches the ACME challenge.</p> AutoTLS components</a></h3> AutoTLS has two main components:</p> registration.libp2p.direct</code>: An ACME DNS-01 challenge broker that authenticates PeerIDs, verifies your node is reachable on the address you provided, and sets the _acme-challenge.<PeerID>.libp2p.direct</code> TXT record for the ACME challenge.</li> libp2p.direct</code>: Authoritative DNS server that maps DNS names to the libp2p node's IP addresses statelessly</strong> (without needing to persist any state about the node's IP addresses).</li> </ol> AutoTLS DNS-01 challenge broker</a></h3> To kick-start the AutoTLS process, your libp2p node requests a TLS certificate for .<PeerID>.libp2p.direct</code> from Let's Encrypt. To which Let's Encrypt responds with a challenge to prove it controls that domain.</li> Your libp2p node then calls the AutoTLS DNS-01 challenge broker (registration.libp2p.direct</code>) with the ACME challenge token and your libp2p node's multiaddrs.</li> The DNS-01 challenge broker authenticates your PeerID, verifies your network reachability and sets the TXT DNS record for the ACME challenge</a> at _acme-challenge.<PeerID>.libp2p.direct</code>.</li> Once that TXT DNS record is set, your node notifies Let's Encrypt that the challenge is complete, validates the challenge, and issues a TLS certificate for .<PeerID>.libp2p.direct</code>.</li> </ol> The following diagram illustrates the AutoTLS DNS-01 challenge broker in action:</p> </p> AutoTLS DNS server</a></h3> The second part of the AutoTLS service is the authoritative DNS server for libp2p.direct</code>.</p> Its main role is to map DNS names to the libp2p node's IP addresses statelessly. For example, 203-0-113-1.<peerID>.libp2p.direct</code> resolves to the A record with the IP 203.0.113.1</code>.</p> The trick here is that the IP address is encoded in the DNS name</strong>. Dots are substituted with dashes to ensure the TLS certificate remains valid. The benefit of this approach is that whenever a libp2p node's IP address changes, it's resolvable without coordination. This keeps the DNS server stateless and simple to operate.</p> </p> Bringing it all together</a></h2> Once a libp2p node has a TLS certificate for *.<PeerID>.libp2p.direct</code>, it will typically announce a matching Secure WebSocket address via the identify protocol.</p> The multiaddr for a libp2p node with libp2p.direct</code> TLS certificate looks like this (/p2p/PeerID</code> suffix omitted for brevity):</p> /ip4/145.40.89.101/tcp/4002/tls/sni/145-40-89-101.k51qzi5uqu5dj0wvrbb8keygfyxe2v0fi1qbqz4pl3zzozle7oaqhf97mqazo4.libp2p.direct/ws</code></p> Note:</strong> Another valid shorter representation of the multiaddr is /dns4/145-40-89-101.k51qzi5uqu5dj0wvrbb8keygfyxe2v0fi1qbqz4pl3zzozle7oaqhf97mqazo4.libp2p.direct/tcp/4002/tls/ws</code>, but it requires a DNS lookup to resolve the IP address. In theory, avoiding the DNS lookup is a performance win, but in practice, browsers don't let you manually set the SNI hostname for a WebSocket connection, so the browser WebSocket API requires the DNS name for the Secure WebSocket connection.</p> </blockquote> This multiaddr can be dialed from any browser with js-libp2p</code>. You can see this in action with the Helia Identify Tool</a></p> What about other browser transports?</a></h3> Solving the problem of browser-node connectivity has been a goal for the libp2p project. In recent years, libp2p introduced support for both WebTransport</a> and WebRTC</a> to solve this problem with varying degrees of success.</p> While these transports have their own strengths and weaknesses, they all share the same goal: enabling browser-node connectivity.</p> WebTransport</a></h3> Two years ago, the libp2p project bet on the promise of WebTransport</a> and it's been a bumpy road.</p> WebTransport has a lot of promise. It's a modern browser protocol based on QUIC (which we already heavily rely on in libp2p), which allows bidirectional streaming communication with many modern improvements over WebSockets. Most notably:</p> 3 round trips to establish a connection.</li> Support of authentication using certificate hashes eliminates the need for CA-signed certificates and a domain.</li> </ul> However, the WebTransport specification is still in draft, and browsers have a number of open bugs and issues</a>, that we've been working with the browser vendors to address. As such, browser compatibility breaks as soon as the interoperability target changes.</p> While we still believe in the longer term promise of WebTransport, we've reoriented our immediate priorities to WebRTC-Direct (which is now available) and Secure WebSockets with AutoTLS. Nonetheless, we continue to work with browser vendors and standard bodies to get WebTransport in libp2p to a stable and interoperable state.</p> WebRTC</a></h3> WebRTC-Direct</a> is a libp2p approach using WebRTC to allow browser-to-node communication. It's unique in that it doesn't require SDP</a> signaling, and saves round trips by constructing the SDP from the information in the webrtc-direct multiaddr (a technique called "SDP munging"). Moreover, WebRTC doesn't require a domain name and CA-signed TLS certificate.</p> However, there are a number of drawbacks to WebRTC:</p> WebRTC is not supported in Service Workers</a>.</li> Chrome limits the number of WebRTC connections per window to 500</a> after which it will prevent establishing new connections.</li> </ul> Origins vs. PeerIDs</a></h2> The Web security model is anchored to domain names (origins). Moreover, browsers require TLS certificates to be signed by a certificate authority (CA) to ensure that the entity requesting a certificate owns the domain name. The role of certificate authorities is to verify that the entity requesting a certificate owns the domain name.</p> On the other hand, libp2p's security model is anchored to PeerIDs: unique identifiers derived from public keys generated by the libp2p node. Unlike CA-signed TLS certificates, PeerIDs can permissionlessly be generated.</p> The AutoTLS broker instance at libp2p.direct</code> bridges both worlds while complying with their respective security requirements. The domain was added to https://publicsuffix.org/ and functions as an eTLD</a>, granting each peer its own Origin at {PeerID}.libp2p.direct</code>.</p> The AutoTLS registration API ensures that only the owner of the private key for a PeerID can request a TLS certificate. Beyond that, the API is used quarterly upon certificate renewal. Secrets never leave the end user's machine. And each end user is responsible for the security of their certificates, and revocation is limited to peer-specific subdomains.</p> Working towards a better Web platform</a></h2> A key theme running through this initiative is the challenge of advancing the Web platform to be both more secure and more open. This includes working with browser vendors and Igalia</a> towards the resolution of various issues with WebTransport, WebRTC, etc.</p> If you'd like to support our work, please reach out to us at contact [AT] ipshipyard.com</code>, and check out the in-web-browsers</a> repository where we're tracking these efforts.</p> When Not</em> to use AutoTLS</a></h2> AutoTLS is designed for production use with Web browsers and should not be used in:</p> Testing/Development</strong>: Unnecessary for local or non-production setups.</li> CI Systems</strong>: Temporary instances waste certificates and may hit rate limits.</li> Non-Public Nodes</strong>: If your node is not publicly dialable (e.g., behind a firewall without port forwarding or UPnP) it won't benefit from /tls/ws</code> transport.</li> Private Networks (PNETs)</strong>: AutoTLS is not compatible with libp2p PNET.</li> </ul> Conclusion</a></h2> Our long-standing goal at Interplanetary Shipyard</a> is building a more resilient and participatory internet through decentralization, and we believe that the Web platform plays an important role in this. We built AutoTLS and run registration.libp2p.direct</code> as a public good service for the libp2p ecosystem. Admittedly, it may seem paradoxical that a centralized public good service like AutoTLS could help the Web become more decentralized. But the reality is that AutoTLS is a necessary step to this end, as well as being lean, open source</a>, and built on open standards.</p> In the long term, WebTransport with self-signed certificates is positioned to become the recommended transport for browser-node connectivity. However, until WebTransport is production ready</a>, AutoTLS and Secure WebSockets are the best way to enable browser-node connectivity.</p> AutoTLS is an opt-in feature and can be enabled in:</p> Kubo</a> >= 0.33.</li> IPFS Desktop</a> >= 0.41.</li> Helia</a> >= 5.2.0.</li> js-libp2p</a> for Node.js.</li> go-libp2p</a>.</li> </ul> To see code examples of how to use AutoTLS with js-libp2p and go-libp2p, check out the following repositories:</p> GO: go-libp2p/examples/autotls</a></li> JS: js-libp2p-example-auto-tls</a></li> </ul> Try it out and let us know what you think!</p> Announcing the release of rust-libp2p v0.55 The libp2p Foundation — Wed, 15 Jan 2025 00:00:00 +0000 rust-libp2p v0.55</code> has just shipped.</p> See individual changelogs</a> for details.</p> Thanks to everyone who contributed to it! ❤️</p> Introduction to libp2p Community Meetings The libp2p Foundation — Mon, 29 Apr 2024 00:00:00 +0000 The libp2p Community is growing a little bit every day since the creation of the libp2p Foundation and the independence of the libp2p Project back in January of 2024.</p> One such improvement was the centralization of the libp2p Community Calendar to one location: lu.ma/libp2p</a>.</p> This blog post covers all of the current community meetings you will find on the calendar as well as outline how you can organize your own and get it promoted alongside the other libp2p meetings.</p> The Current Calendar</a></h2> Check out the libp2p community calendar</a> and add it to your calendar to stay up to date with all the meetings.</p> Starting a New Meeting</a></h2> The libp2p Community operates on a "2 + you" rule for meetings. If you and two other people would like to start a meeting, let me know and I will help you organize it, list it on the libp2p calendar, announce it on our social media feeds and all of our chat channels.</p> Find me (@dhuseby) on any of our chat rooms</a> and let me know so I can help get it organized.</p> Current Meetings</a></h2> libp2p Community Call</a></h3> This is our main community-wide meeting where we discuss project updates, upcoming events, and community news.</p> go-libp2p Meeting</a></h3> Regular meetings for the Go implementation of libp2p.</p> rust-libp2p Meeting</a></h3> Regular meetings for the Rust implementation of libp2p.</p> nim-libp2p Meeting</a></h3> Regular meetings for the Nim implementation of libp2p.</p> js-libp2p Meeting</a></h3> Regular meetings for the JavaScript implementation of libp2p.</p> libp2p Specifications Meeting</a></h3> Meetings to discuss and develop libp2p specifications.</p> Check the calendar</a> for specific times and dates!</p> Announcing libp2p-rPGF-1, the first libp2p project RetroPGF Round! The libp2p Foundation — Mon, 08 Apr 2024 00:00:00 +0000 Today, the libp2p project is excited to announce the first ever</strong> libp2p retroactive public goods funding round, libp2p-rPGF-1!</p> The libp2p project is partnering with Gitcoin to retroactively award $125,000 USD worth of OP, recognize impact, and further empower contributors to libp2p.</p> libp2p will be using a portion of its Optimism rPGF round 3 rewards to contribute back to the broader ecosystem!</p> libp2p is a public good which powers much of the decentralized web, including projects like Ethereum, Filecoin, Optimism, Polkadot, and more! Moreover, libp2p's success as a project is the result of a vast panoply of communities, collaborators, and organizations building together.</p> However, these efforts are often unrecognized and unrewarded since markets can fail to adequately fund public goods. By embracing RetroPGF, libp2p seeks to bridge that funding gap.</p> The Process</a></h2> The rounds follow the Optimism template:</p> Badgeholders selection</li> Nominations/Application submissions</li> Voting by badgeholders</li> Publish voting results</li> Distribute rewards/funding</li> Retrospective to improve future rounds</li> </ol> Categories</a></h2> Anyone can nominate a project that has achieved impact in the past 12 months in one of the following categories:</p> Software & Dependencies</li> Infrastructure, Tooling, & Utilities</li> Education, Outreach, and Applications</li> Research & Development</li> Other</li> </ul> This round aims to disburse $125,000 USD worth of OP, with plans to grow in the future.</p> We would like to thank the participants & sponsors for pushing the ecosystem forward and helping bootstrap public goods funding into the libp2p project!</p> libp2p Day at ETHDenver 2024 Recap The libp2p Foundation — Thu, 14 Mar 2024 00:00:00 +0000 Last month on February 29th, 2024, the libp2p community came together in Denver, Colorado to hold the first libp2p Day in 2024 alongside the ETHDenver conference.</p> SWOT Analysis</a></h3> At the end of the day we had our first "Strengths, Weaknesses, Opportunities and Threats" (SWOT) session of 2024. The highlights:</p> Strengths</strong></p> Our community has expanded to include at least 5 implementations used in production</li> Several independent communities based around the different implementations</li> There is some funding to sustain the project going forward</li> </ul> Weaknesses</strong></p> Learning libp2p is still somewhat difficult</li> </ul> Opportunities</strong></p> Focus funding on creation of new learning materials</li> Make libp2p into the go-to library for distributed systems researchers</li> Focus on mobile optimization</li> </ul> Threats</strong></p> Continued funding is always going to be a threat to the health of the community</li> </ul> Talks</a></h2> We had a great event with 12 different sessions focusing on topics such as public goods funding, probing p2p networks, synchronization protocols in blockchains, designing peer-to-peer social networks and others.</p> Highlighted Talks</a></h3> Funding and Project update by Juan Benet</a></h4> </iframe> </div> Revolutionizing Data Governance with libp2p by TechieTeee</a></h4> </iframe> </div> Probing libp2p Networks with Filecoin Station by Miroslav Bajtoš</a></h4> </iframe> </div> Programming Peer-to-Peer Scenarios with Aqua</a></h4> </iframe> </div> Gitcoin and Open Source Funding Mechanism by Sov from Gitcoin</a></h4> </iframe> </div> Full Playlist</a></h3> Watch the full playlist of talks from libp2p Day at ETHDenver 2024 on YouTube</a>.</p> rust-libp2p in the Browser with WebRTC! The libp2p Foundation — Wed, 21 Feb 2024 00:00:00 +0000 We are excited to announce that rust-libp2p running in the browser can now establish WebRTC connections. Before now, WebRTC was only available on the server in rust-libp2p, but after months of coding and reviews, it is available on both the server and in the browser.</p> Why WebRTC for rust-libp2p?</a></h2> Easier node operation</a></h3> Modern browsers require served connections to use TLS. In the case of WebSockets, certificates need to be signed by a Certificate Authority, meaning you need to set up DNS and Let's Encrypt. These steps create a barrier to entry.</p> With WebRTC, we can use self-signed certificates, removing the need for domain names and trusted Certificate Authorities!</p> Imagine being able to write a web app in Rust that connects to a Rust node running on your desktop at home, without having to set up DNS, Let's Encrypt, or any external server infrastructure!</p> Improved connectivity</a></h3> WebRTC also allows connecting two browsers directly. With the ease of setting up a libp2p WebRTC server, anyone can set up their own signalling server or use one embedded into a Rust application!</p> Benefits of Full Stack rust-libp2p</a></h2> Now that we have rust-libp2p over WebRTC on both server and browser, we can share code between the two layers! Writing isomorphic code speeds up development and makes reviews and debugging easier.</p> How does libp2p use WebRTC?</a></h2> Data Channels</a></h3> WebRTC's flagship purpose is connecting media (audio and video). However, there is also a powerful data channel API which allows exchanging data streams. This is what libp2p uses at the transport layer.</p> Breaking down the stack</a></h3> The browser provides WebRTC through the Web API</li> wasm-bindgen</code> provides bindings through web-sys</code></li> rust-libp2p wraps these bindings to implement a WebRTC Transport</li> This Transport is available for applications (Kademlia, Gossipsub, etc.)</li> Finally, Rust code is compiled to WebAssembly and runs in the browser</li> </ul> Demo</a></h2> There is a full stack example in the repo</a> that runs a local server, compiles browser code to WebAssembly, and demonstrates pinging back and forth.</p> What's next?</a></h2> Now that we have browser to server connections, the next step is browser to browser connections using the WebRTC circuit relay pattern. Stay tuned for updates!</p> Announcing the release of js-libp2p v1.0.0 The libp2p Foundation — Tue, 12 Dec 2023 00:00:00 +0000 js-libp2p has been used in production for many years in IPFS and Ethereum, as well as a wide variety of other ecosystems. Today, we're excited to announce the release of js-libp2p v1.0.0</a>!</p> What's new?</a></h2> Smart Dialing</a></h3> One of the major inefficiencies we recognized was how we dialed peers, particularly in the browser. Smart dialing is a dialing strategy that is more aware of the network topology and the reachability of the multiaddrs it is dialing. This has led to a significant reduction in the number of dials made and failed dials.</p> Circuit Relay v2</a></h3> Circuit relay was introduced as a means to establish connectivity between libp2p nodes that wouldn't otherwise be able to establish a direct connection. Circuit Relay v2 has significant improvements over v1, including support for resource reservation and limitations on durations and data caps.</p> NAT Hole punching with DCUtR</a></h3> The libp2p DCUtR (Direct Connection Upgrade through Relay) is a protocol for establishing direct connections between nodes through hole punching, without a signaling server. Implementing this in js-libp2p has benefitted browser nodes significantly.</p> WebRTC Private-to-Private Connectivity</a></h3> Currently js-libp2p is the only implementation that supports private-to-private browser connectivity using WebRTC. This allows direct peer-to-peer connectivity within the browser regardless of whether nodes are located behind NATs/Firewalls.</p> WebTransport</a></h3> WebTransport is a new web standard built on top of QUIC that allows establishing WebTransport connections to servers that only have self-signed certificates.</p> Performance Improvements</a></h2> Reducing latency</a></h3> We've made an 80%+ improvement in the time it takes to establish a connection between two js-libp2p nodes.</p> </p> Increasing throughput</a></h3> Currently js-libp2p has the highest throughput of any of the libp2p implementations, averaging 2.06GB/s on both uploads and downloads!</p> </p> Reducing Dependencies</a></h3> We reduced the bundle size by over 40% by removing modules that are tangential for many use cases.</p> Developer Experience Improvements</a></h2> Monorepo Setup</a></h3> The js-libp2p ecosystem once consisted of over 81 repositories! We consolidated all of the repositories into a single monorepo.</p> Modernization of Tooling</a></h3> We've completely re-written our codebase in TypeScript and standardized our modules through ESM.</p> Documentation Improvements</a></h3> We've introduced tools to automate and validate our docs, including a JS-docs based documentation generator and architectural diagrams.</p> What's next?</a></h2> React Native Support</li> QUIC support</li> Improved documentation</li> Improved observability and metrics</li> </ul> Resources and how you can contribute</a></h2> js-libp2p Discussions</a></li> Slack - the libp2p-implementers channel</a></li> libp2p Specifications</a></li> </ul> Thank you for reading!</p> HTTP-P2P, HTTP with more Ps The libp2p Foundation — Wed, 20 Sep 2023 00:00:00 +0000 We're introducing a new experimental API in go-libp2p, enabling developers to utilize libp2p with the well-known semantics of HTTP. This isn't a special flavor of HTTP; it's standard HTTP, but enhanced with libp2p.</p> Developers can now benefit from HTTP intermediaries such as CDN caching and layer 7 load balancing. This allows developers to create HTTP applications that operate over NATs and tap into libp2p's diverse transport options.</p> Use Cases</a></h3> Fetch content from peers over the IPFS Path Gateway protocol, regardless of whether they're a CDN, R2 bucket, random server, laptop, or browser</li> HTTP Edge compute nodes can behave as peers in the libp2p network</li> Simple HTTP clients like curl can participate in the libp2p network</li> Browsers can make secure HTTP requests using WebTransport or WebRTC</li> Operators can use layer 7 load balancing with projects like Envoy</li> Port existing HTTP applications like Mastodon or Gitea to a p2p environment</li> </ul> Technical details</a></h2> This new API implements the libp2p+HTTP spec with three main features:</p> A new HTTP Transport</a></h3> A libp2p node can now listen on an HTTP transport and advertise its address as a multiaddr ending in /tls/http</code> (or /https</code>). The HTTP transport lives alongside other transports (tcp+tls+yamux, QUIC, WebRTC, etc.).</p> HTTP Semantics</a></h3> HTTP semantics are the abstract form of HTTP, defined by RFC 9110. We can use WebTransport, WebRTC, or a hole-punched QUIC connection to make an HTTP request, allowing developers to create applications using familiar HTTP tools in a p2p setting.</p> .well-known/libp2p</a></h3> This solves protocol discovery in a p2p setting. A node provides information about supported protocols at the /.well-known/libp2p</code> resource. For example:</p> {</span>"/hello/1"</span>:{</span>"path"</span>:</span>"/hello-path/"</span>}}</span></span></code></pre> We're hoping to get early feedback as the API solidifies. Please try it out and let us know what you think in the go-libp2p Discussions forum</a>.</p> Adding a QUIC API for Go's standard library TLS package The libp2p Foundation — Wed, 13 Sep 2023 00:00:00 +0000 QUIC is becoming the most important transport in libp2p. For example, QUIC accounts for 80-90% of the connections made to PL-run bootstrappers participating in the public IPFS DHT.</p> quic-go</a> is a QUIC implementation written in pure Go that is used in go-libp2p, Caddy, Adguard, syncthing, and many other projects.</p> QUIC and TLS 1.3</a></h2> All QUIC connections use TLS 1.3 to encrypt messages. However, due to running on top of UDP, QUIC's interactions with the TLS stack differs from how TLS over TCP functions.</p> When QUIC was standardized, it became necessary for TLS stacks to expose new APIs. For the longest time, Go's crypto/tls lacked an API for this purpose. The quic-go project had to fork crypto/tls to add the required APIs.</p> This meant:</p> Extra effort every time a new Go version was released</li> Security fixes in crypto/tls required updating quic-go</li> Lack of forwards-compatibility with future Go versions</li> </ul> Solving the Problem</a></h2> To tackle this situation, we joined forces with Filippo Valsorda, who maintains crypto/tls. Filippo is sponsored by Protocol Labs for his remarkable open-source work.</p> Our first joint endeavor established an API for crypto/tls that enables QUIC implementations to use it. After long discussions, we arrived at a much cleaner proposal than our homegrown qtls API.</p> 0-RTT Support</a></h2> 0-RTT allows clients to resume connections and send encrypted data in the first packet. Adding support for 0-RTT was a large endeavor requiring coordination between the TLS and QUIC stacks.</p> The server typically encrypts transport parameters and stores them in the session ticket. When the client restores the session, it sends the session ticket allowing the server to restore parameters without persisting them.</p> Current Status</a></h2> After an intense period of collaboration, we are thrilled to have all these changes included in Go 1.21. The implementation was performed by Damien Neil and Filippo Valsorda.</p> The changes have been released in quic-go v0.37 and go-libp2p v0.30. We anticipate that these changes will work seamlessly once users update their dependencies and compiler version.</p> Testing all the libp2ps The libp2p Foundation — Wed, 23 Aug 2023 00:00:00 +0000 There are many implementations</a> of libp2p with varying degrees of feature completeness. Each implementation has transports, secure channels, and muxers that they support. How do we make sure that each implementation can communicate with every other implementation? And how do we check that they can communicate over each supported combination?</p> In this post I'll cover how we test every implementation on every strategy, on many versions, and highlight some open problems that you can contribute to.</p> Testing connectivity interoperability is as simple as starting up two libp2p nodes and having them ping each other. The difficulty arises in how we make a reproducible environment for every implementation and connection strategy.</p> The first attempt used Testground, but it was too complicated and slow for what we wanted to do. The next attempt used Docker's compose directly with some TypeScript to help generate the compose files. This was much easier to build.</p> Problems to solve</a></h2> Compose handles spinning up the test environment, but there were still problems to solve:</p> How do we define this test environment?</li> How do we share the listener's address to the dialer?</li> How do we build each implementation?</li> </ol> We solved the first problem with Sqlite. The problem of finding all combinations of implementations and parameters is equivalent to a Join operation.</p> The second problem we solved using Redis as a synchronization point. The listener pushes its address to Redis, and the dialer blocks until it can read it.</p> For building implementations, we use Makefiles and Docker container images with caching in S3.</p> Coverage</a></h2> Right now, the system tests 6 different libp2p implementations and runs about 1700 tests. The tests are also run on each PR in Go, Rust, JS, Nim, and Zig libp2p.</p> </p> See the latest full run at the GitHub Actions page</a>.</p> Impact realized so far</a></h2> The system has already helped catch several bugs:</p> quic-go wrong cipher selection</li> Interop failure with Firefox WebRTC</li> zig-libp2p multistream-select issue</li> Interop issue with Yamux between rust-libp2p and js-libp2p</li> Wrong default Noise handshake pattern</li> </ul> It has also validated big code changes like the new WebTransport transport for rust-libp2p in Wasm.</p> Next steps</a></h2> There's still room for improvement, especially in making tests faster. The biggest optimization would be reducing the Docker overhead.</p> Beyond basic connectivity, we want to add tests for mDNS and test interoperability of libp2p protocols like Kademlia, GossipSub, and more.</p> Are you working on a libp2p implementation? Check out the test-plans README</a> for specifics on how to implement these tests.</p> Metrics in go-libp2p The libp2p Foundation — Tue, 15 Aug 2023 00:00:00 +0000 go-libp2p is the core networking component for many go-based implementations like Kubo (IPFS), Lotus (Filecoin), and Prysm (Ethereum Beacon Chain).</p> We've added instrumentation to collect metrics from various components, which have already helped debug nuanced issues and develop features.</p> Check out the public dashboards</a> to see metrics from different libp2p components in production.</p> Why Prometheus?</a></h2> We chose Prometheus over OpenCensus and OpenTelemetry because:</p> OpenCensus creates a lot of allocations, leading to increased GC pressure</li> OpenTelemetry's metrics API is still unstable</li> Prometheus is performant (zero-alloc) and ubiquitous</li> </ul> We also added ready-to-use Grafana dashboards.</p> How to Enable Metrics</a></h2> Metrics are enabled by default since go-libp2p v0.26.0. Just setup a Prometheus exporter:</p> func</span> main</span>() {</span></span> http.</span>Handle</span>(</span>"/metrics"</span>, promhttp.</span>Handler</span>())</span></span> go func</span>() {</span></span> http.</span>ListenAndServe</span>(</span>":2112"</span>,</span> nil</span>)</span></span> }()</span></span> </span> host, err</span> :=</span> libp2p.</span>New</span>()</span></span> // ...</span></span> }</span></span></code></pre> Point your Prometheus instance to scrape from :2112/metrics</code>.</p> Discovering Available Metrics</a></h3> go-libp2p provides metrics and Grafana dashboards for all major subsystems. Check the dashboards directory</a> for available Grafana dashboards.</p> To discover metrics, type libp2p_(libp2p-package-name)_</code> in the Prometheus UI and find available metrics from autocomplete.</p> </p> Impact</a></h2> These metrics have already helped us:</p> Debug AutoNAT issues</li> Optimize the Resource Manager</li> Improve connection handling</li> </ul> We encourage users to deploy these dashboards and share feedback!</p> libp2p at IPFS þing 2023 Recap The libp2p Foundation — Thu, 11 May 2023 00:00:00 +0000 Last month, April 15th - 19th 2023, the IPFS community came together in Brussels, Belgium for IPFS þing 2023</a>.</p> The libp2p users and contributors community came out to meet up once again, interface with the broader IPFS community, and share all of the great accomplishments and new work going on in the libp2p project.</p> Over the course of five days the libp2p community gave 6 different talks on recent developments and finished strong with a workshop where participants built their own peer-to-peer chat application.</p> Goals</a></h2> The goals of the libp2p contributors attending IPFS þing 2023 were to:</p> Build excitement by demonstrating the Universal Connectivity application</li> Give updates on performance, dealing with non-uniform network topology, interoperability improvements, and lowering barriers to libp2p compatibility</li> Reconnect with community contributors and build up the greater libp2p community</li> </ol> Recap of Talks</a></h2> Connecting Everything, Everywhere, All at Once with libp2p</a></h3> Max Inden (rust-libp2p maintainer)</p> </iframe> </div> Max's talk about the Universal Connectivity demonstrator app broke the record for the most people involved! The live demo showed a go-libp2p node talking to a rust-libp2p node talking to a laptop talking to js-libp2p browsers using a variety of transports including QUIC, WebRTC Direct, WebRTC, and WebTransport.</p> libp2p Performance</a></h3> Max Inden & Marco Munizaga</p> </iframe> </div> Watch Max and Marco describe how libp2p maintainers think about and measure performance, plus learn about some optimizations in the latest versions.</p> The Incredible Benefits of libp2p + HTTP</a></h3> Marten Seemann & Marco Munizaga</p> </iframe> </div> Marten and Marco demonstrated using js-libp2p and service workers to intercept normal HTTP calls in the browser and re-route them over libp2p connections.</p> How to Build Your Own Compatible libp2p Stack from Scratch</a></h3> Marten Seemann & Marco Munizaga</p> </iframe> </div> Marten and Marco showed how simple it is to create a compatible libp2p stack out of a QUIC library, the libp2p TLS extension and some code for peer ID encoding.</p> Enabling More Applications to Join the libp2p DHT Ecosystem</a></h3> Gui Michel (Research Engineer at Protocol Labs)</p> </iframe> </div> This talk covered improvements to the DHT to enable more applications to participate.</p> Workshop: Build Your Own p2p Chat</a></h2> Participants built their own peer-to-peer chat application leveraging the same technology as the Universal Connectivity demonstrator project. It was a great hands-on experience for everyone!</p> go-libp2p in 2022 The libp2p Foundation — Mon, 13 Feb 2023 00:00:00 +0000 We are excited to share with you all the progress that has been made on go-libp2p</a> in 2022. It has been a year full of exciting new features, code organization, and a growing team of talented contributors.</p> Throughout the year, we released seven updates to go-libp2p ranging from v0.18.0</a> to v0.24.0</a>, with a number of patch releases in between. In total, we had 21 contributors</a> to the project in 2022.</p> New Features</a></h2> Transport Protocols</a></h3> WebTransport</a></h4> One of the most exciting developments of the year was the release of the WebTransport protocol in v0.23.0</a>. WebTransport enables browser-to-server connectivity in go-libp2p when paired with a peer running js-libp2p-webtransport in the browser.</p> To learn more about this exciting feature, check out our blog post on WebTransport in libp2p</a> and the WebTransport documentation</a>.</p> WebRTC (Browser to Server)</a></h4> In addition to WebTransport, the go-libp2p team also began work on enabling the WebRTC transport, in partnership with Little Bear Labs. This new transport allows for connectivity between go-libp2p server nodes and js-libp2p browser nodes.</p> QUIC Versions</a></h4> We also made developments to the existing QUIC implementation in go-libp2p. In v0.24.0</a>, go-libp2p changed to properly distinguish between QUIC versions (in their multiaddresses) and changed the default dial behavior to prefer the new QUIC version.</p> DoS Protection & Resource Management</a></h3> We added the Resource Manager component</a> in v0.18.0</a>. This feature allows developers to configure limits on connections, streams, and memory usage.</p> Faster Handshakes</a></h3> In v0.24.0</a>, go-libp2p added optimized muxer selection via TLS' ALPN extension and Noise extensions. This resulted in saving one round trip during connection establishment.</p> AutoRelay discovers Circuit Relay v2</a></h3> In v0.19.0</a>, we enabled AutoRelay to discover nodes running Circuit Relay v2, improving the overall performance and reliability of the network.</p> Project Improvements</a></h2> Interoperability Testing</a></h3> We began a concerted effort to improve interoperability between go-libp2p and libp2p implementations in other languages. The details can be seen in the shared libp2p/test-plans Roadmap</a>.</p> Monorepo Consolidation</a></h3> go-libp2p is a monorepo as of the v0.22.0 release</a>.</strong> This improvement makes changes and improvements across go-libp2p much easier.</p> Plans for 2023</a></h2> Key areas of focus:</p> Interoperability and end-to-end testing</li> Expanding seamless browser connectivity</li> Adding support for libp2p + HTTP</li> Optimizing performance</li> Better observability with metrics</li> </ul> Resources and how you can help contribute</a></h2> We always welcome contributions from the community! Check out any of these help wanted/good first issues</a> to start contributing.</p> Thank you for reading!</p> WebRTC (Browser-to-Server) in libp2p The libp2p Foundation — Mon, 06 Feb 2023 00:00:00 +0000 This is the second entry in the Universal Browser Connectivity series on how libp2p achieves browser connectivity. Read about WebTransport in the first post</a>.</p> Overview</a></h2> The libp2p project</a> supports many transport protocols across a variety of implementations. These transport protocols enable applications using libp2p to run as server nodes (on a personal laptop or in a datacenter) or as browser nodes (inside a Web browser).</p> Historically, libp2p has bridged these runtime environments with different node connectivity options in varying degrees:</p> server node to server node via TCP and QUIC</li> browser node to public server node via WebSockets and, more recently, WebTransport</a></li> browser node to browser node (via less than ideal solutions)</li> </ul> Today our focus is on advancements in the browser to public server</strong> use case...</p> We're excited to present a new paradigm for browser-to-server connectivity and announce, native support for WebRTC now exists in libp2p across three implementations!</strong></p> Acknowledgements</a></h3> We would like to recognize and express our gratitude to Little Bear Labs</a> and Parity Technologies</a> for their contributions to the development of the WebRTC specification</a> and implementation in libp2p.</p> WebRTC in the browser</a></h2> WebRTC, or Web Real-Time Communication, is a set of standards that enables peer-to-peer connections between browsers, clients, and servers and the exchange of audio, video, and data in real-time. It is built directly into modern browsers and is straightforward to use via its API.</p> While WebRTC handles audio, video, and data traffic, we're just going to focus on the data aspect because that's the API leveraged in libp2p WebRTC.</p> In most cases, peers directly connect to other peers, improving privacy and requiring fewer hops than on a relay. Peers connect via an RTCPeerConnection</a> interface. Once connected, RTCDataChannels</a> can be added to the connection to send and receive binary data.</p> WebRTC in libp2p</a></h2> </p> Connecting from a browser to a public server in the WebRTC implementation in libp2p has some similarities but differs in several ways. Many of the features supported in the WebRTC standard, such as video, audio, and centralized STUN and Turn servers, are not needed in libp2p. The primary WebRTC component that libp2p leverages is the RTCDataChannels.</p> Server Setup</a></h3> To prepare for a connection from the browser, the server:</p> Generates a self-signed TLS certificate.</li> Listens on a UDP port for incoming STUN packets.</li> </ol> Browser Connection</a></h3> To initiate a connection, the browser:</p> Assembles the multiaddress of the server, which is either known upfront or discovered.</li> Creates an RTCPeerConnection.</li> Generates the server's Answer SDP using the components in the multiaddress.</li> Modifies the SDP, or "munges" it, to include an auto-generated ufrag and password, as well as the server's IP and port.</li> Creates an Offer SDP and modifies it with the same values.</li> Sets the Offer and Answer SDP on the browser, which triggers the sending of STUN packets to the server.</li> </ol> Server Response</a></h3> The server responds by creating the browser's Offer SDP using the values in the STUN Binding Request.</p> DTLS Handshake</a></h3> The browser and server then engage in a DTLS handshake to open a DTLS connection that WebRTC can run SCTP on top of. A Noise handshake</a> is initiated by the server using the fingerprints in the SDP as input to the prologue data, and completed by the browser over the Data Channel.</p> Once the DTLS and Noise handshakes are complete, DTLS-encrypted SCTP data is ready to be exchanged over the UDP socket.</p> 💡</span> Unlike standard WebRTC, signaling is completely removed in libp2p browser-to-server communication, and Signal Channels are not needed. Removing signaling results in fewer roundtrips to establish a Data Channel and reduces complexity. </div> </div> Multiaddress</a></h3> The multiaddress of a WebRTC address begins like a standard UDP address, but adds three additional protocols: webrtc</code>, hash</code>, and p2p</code>.</p> /ip4/1.2.3.4/udp/1234/webrtc/certhash/<hash>/p2p/<peer-id></span></span></code></pre> webrtc</code>: the name of this transport</li> hash</code>: the multihash of the certificate used in the DTLS handshake</li> p2p</code>: the peer-id of the libp2p node (optional)</li> </ul> Benefits</a></h3> Self-signed Certificate</a></h4> WebRTC enables browsers to connect to public libp2p nodes without the nodes requiring a TLS certificate in the browser's certificate chain. WebRTC allows the server to use a self-signed TLS certificate, eliminating the need for additional services like DNS and Let's Encrypt.</p> Broad support</a></h4> WebRTC has been supported in Chrome since 2012, and support has since been added to all evergreen browsers. This makes WebRTC widely available and easy to implement in libp2p.</p> Limitations</a></h3> Setup and configuration</a></h4> WebRTC is a complex set of technologies that requires extensive server setup and configuration. While libraries like Pion and webrtc-rs abstract away this functionality, the additional complexity introduced and the configuration fine-tuning required can be a drawback for some users.</p> Extensive Roundtrips</a></h4> Another limitation is the 6 roundtrips required before data is exchanged. This may make other transports, such as WebTransport, more appealing where the browser supports it.</p> Usage</a></h3> The complexity of WebRTC is abstracted in the libp2p implementations, making it easy to swap in WebRTC as the transport. In the JavaScript implementation, for example, all you need to do is initialize with:</p> import</span> { webRTC }</span> from</span> 'js-libp2p-webrtc'</span></span> </span> const</span> node</span> = await</span> createLibp2p</span>({</span></span> transports: [</span>webRTC</span>()],</span></span> connectionEncryption: [()</span> =></span> new</span> Noise</span>()],</span></span> });</span></span></code></pre>Alternative transports</a></h2> WebRTC is just one option for connecting browsers to libp2p nodes. libp2p supports a variety of transports, and choosing the right one for your use case is an important consideration. The libp2p connectivity guide</a> was designed to help developers consider the available options.</p> WebSocket</a></h3> The WebSocket protocol allows for the opening of a two-way socket between a browser and a server over TCP. One limitation of WebSocket is the number of roundtrips required to establish a connection—up to six roundtrips. Additionally, WebSocket requires the server to have a trusted TLS certificate using TCP, unlike WebRTC which can use a self-signed certificate.</p> WebTransport</a></h3> WebTransport</a> is the new kid on the block for communication in the browser. WebTransport has many of the same benefits as WebRTC, such as fast, secure, and multiplexed connections, without requiring servers to implement the stack. Additionally, WebTransport requires fewer roundtrips to establish a connection than WebRTC, making it the preferred choice when supported.</p> Currently, it is only implemented in Chrome and is still under development. Until WebTransport is supported by all major browsers, WebRTC can serve as a good fallback option.</p> Can I use WebRTC now?</a></h2> Yes, you can use libp2p-webrtc in the Rust</a> and JavaScript</a> implementations! The Go</a> implementation is also available.</p> For how to use WebRTC browser-to-server, you can take a look at the examples in the js-libp2p-webrtc repo</a>.</p> What's next?</a></h2> WebRTC offers the capability for browsers to connect to browsers. The WebRTC browser-to-browser connectivity spec</a> has been authored and development is underway.</p> Resources and how you can help contribute</a></h2> WebRTC Docs</a></li> WebRTC Connectivity</a></li> WebRTC Spec</a></li> </ul> If you would like to contribute, please connect with the libp2p maintainers</a>.</p> Thank you for reading!</p> rust-libp2p in 2022 The libp2p Foundation — Thu, 12 Jan 2023 00:00:00 +0000 The rust-libp2p</a> project has made significant strides in 2022, with numerous technical advancements and improvements to the project itself. This is the work of many across various organizations including Protocol Labs, Parity Technologies, Sigma Prime, Iroh, Actyx and Little Bear Labs.</p> Technical Highlights</a></h2> Decentralized Hole Punching</a></h3> We started the year with the release of the various components needed for hole punching. We added the Circuit Relay v2 protocol, DCUtR protocol and AutoNAT protocol. These features were all included together in rust-libp2p v0.43.0</a> released in February.</p> New Transports</a></h3> Over the year we worked on two new transports: WebRTC (browser-to-server) and QUIC, which we both released towards the end of the year as alpha/experimental features.</p> Our implementation of WebRTC enables browsers to connect to rust-libp2p based servers without those servers needing to have signed TLS certificates. QUIC is a better libp2p transport than the combination of TCP+Noise+Yamux in almost every dimension.</p> User Experience Improvements</a></h3> We tackled many smaller improvements including naming consistency across crates, refactoring of event handlers, deprecation of event-based PollParameters</code>, rework of Rust feature flags, and removal of listener streams in favor of polling transports directly.</p> DoS Protection</a></h3> rust-libp2p saw a lot of DoS protection improvements in 2022. We enforce various limits and prioritize local work over new incoming work from a remote across the many layers.</p> Metrics and Observability</a></h3> We introduced a metric crate for rust-libp2p exposing Prometheus metrics, e.g. the time to establish a connection or the protocols supported by peers.</p> Meta - Improvements to the Project</a></h2> The core rust-libp2p maintainer team grew from two engineers to four. Beyond the core maintainers, a total of 36 people contributed to rust-libp2p's master</code> branch in 2022.</p> Automation</a></h3> We invested heavily into rust-libp2p's automation including mergify, cargo-semver-checks</code>, conventional commits, and refactored CI job structure.</p> Interoperability</a></h3> As of September 2022, we continuously test that the various versions of go-libp2p and rust-libp2p can connect.</p> In 2022 we published 9 releases of the main libp2p</code> crate and a total of 268 releases across the workspace.</p> What's Next?</a></h2> Check out the rust-libp2p project roadmap</a> for planned developments including improved WASM support, WebRTC browser-to-browser, and WebTransport.</p> libp2p & Ethereum (the Merge) The libp2p Foundation — Fri, 06 Jan 2023 00:00:00 +0000 If you've kept up with developments in Web3, you've likely heard of the Paris upgrade</a>, more widely known as The Merge</a>, on the Ethereum network.</p> You may be wondering... why is the libp2p blog writing about Ethereum and the Merge?</p> Well, as a result of the Merge, we're excited to share that:</p> libp2p is integrated into the Ethereum network!</strong></p> A Brief History of libp2p</a></h2> Protocol Labs first developed libp2p as a networking library inside of IPFS. At the outset, their code and repositories were coupled. However, Protocol Labs soon realized libp2p's potential and utility beyond IPFS, and project maintainers split the two codebases apart.</p> As a result, the libp2p project saw tremendous growth and adoption. Besides IPFS and Filecoin, libp2p is relied on by networks like Polkadot, Polygon, Mina, Celestia, Flow, and many more.</p> The Merge</a></h2> Ethereum's genesis occurred on July 30, 2015 as a part of a milestone called Frontier. The most recent (and arguably the most anticipated) upgrade was Paris, a.k.a. The Merge, executed on September 15, 2022.</p> The Merge encompassed major changes:</p> Upgrading the consensus mechanism</strong> - Transitioning to proof-of-stake, away from proof-of-work</li> Reducing network energy consumption by 99.95%</strong></li> Integrating libp2p</strong> into the mainnet's networking layer</li> </ol> How libp2p was integrated into Ethereum</a></h2> In the early days of Ethereum and libp2p, libp2p didn't exist when Ethereum was first developed, so it never got a chance to be evaluated and/or adopted.</p> Prior to the Merge, Ethereum solely used devp2p, a dedicated networking stack. Though there were talks between the Ethereum and IPFS/libp2p communities to have one solution instead of two, the timing didn't work.</p> Early Days (2016-2017)</a></h3> At Devcon 2, David Dias from Protocol Labs gave a talk titled "libp2p ❤ devp2p: IPFS and Ethereum Networking". He gave an overview of libp2p and demonstrated running the EVM in a browser connecting to a go-ethereum node using libp2p.</p> </p> The Integration</a></h3> The integration of libp2p into Ethereum came through the new consensus layer (beacon chain) that powers proof-of-stake. Beacon nodes use libp2p for peer discovery, establishing connections, and exchanging messages.</p> This is the work of many across various organizations including the Ethereum Foundation, Prysmatic Labs, Sigma Prime, ChainSafe, Status.im, and Protocol Labs.</p> How Ethereum Beacon Nodes use libp2p</a></h2> Beacon nodes use libp2p in several ways:</p> Peer Discovery</strong>: Using discv5 for discovery and libp2p for connections</li> GossipSub</strong>: For propagating blocks and attestations</li> Request/Response</strong>: For syncing and specific data requests</li> </ul> Conclusion</a></h2> The integration of libp2p into Ethereum represents years of collaboration between the communities. It demonstrates the power of open-source development and the value of modular, reusable networking libraries.</p> We're excited about this milestone and look forward to continued collaboration with the Ethereum community!</p> WebTransport in libp2p The libp2p Foundation — Mon, 19 Dec 2022 00:00:00 +0000 This is the first entry in a series of posts on how libp2p achieves browser connectivity.</p> Overview</a></h2> Seamless browser connectivity is a crucial goal of the libp2p project</a>. Over many years, libp2p has made many strides to realize that vision. Today, we are proud to announce a significant milestone that puts us much closer to that aim:</p> libp2p now supports the new, bleeding-edge WebTransport protocol!</strong></p> In this article, we:</p> Introduce WebTransport</li> Show what it means for apps and how you can use it today</li> Explain its advantages over existing solutions</li> Give you a deep dive into how it works</li> Describe the current state of WebTransport (specs and implementations)</li> </ul> What is WebTransport?</a></h2> At a high level, WebTransport</a> is a new transport protocol</a> and Web API</a> currently under development by both the Internet Engineering Task Force (IETF)</a> and the World Wide Web Consortium (W3C)</a>.</p> WebTransport is developing to meet these goals</a>:</p> Enable low latency communication between browsers and servers (efficiently transfer data and decrease travel time from browser to server).</li> Have an API that supports different protocols and use cases (e.g., reliable/unreliable and ordered/unordered data transmission, client-server and peer-to-peer architectures, transmitting audio/video media as well as generic data).</li> Have the same security properties as current solutions (e.g., WebSocket over TLS.)</li> </ul> With these goals in mind, WebTransport seeks to address a multitude of use cases, including browser gaming, live streaming, multimedia applications, and more.</p> WebSocket: The old solution and its challenges</a></h2> Before we delve deeper, let's reflect on the history of browser connectivity in libp2p. How did libp2p browser nodes connect to server nodes before the advent of WebTransport, and what challenges existed when bridging browsers to the libp2p ecosystem?</p> Browsers dial TCP</a> connections (for HTTP 1.1 and HTTP/2) and QUIC</a> connections (for HTTP/3) all the time. However, there's no way to just</em> dial a TCP or QUIC connection and use it for things other than HTTP.</p> This posed a problem when integrating browser applications with libp2p. libp2p is built on top of a bidirectional, asynchronous stream abstraction, whereas HTTP is a stateless, unidirectional, synchronous request-response protocol.</p> Therefore, for the longest time, the only way to connect a libp2p client running in the browser to the rest of the network was using the somewhat dated WebSocket protocol</a>.</p> WebSocket has multiple drawbacks:</p> Slow time to connect</strong>: It takes six network roundtrips until the libp2p connection is finally established because of the steps involved in establishing a WebSocket connection.</li> Inefficiency</strong>: We're double-encrypting the data: The first time, it's encrypted on the outer (HTTPS) connection, and then again by the libp2p security protocol.</li> Increased latency</strong>: There's no native stream multiplexing in WebSocket, and each internal stream can suffer from head-of-line blocking.</li> </ul> In practice, a different obstacle prevented WebSocket from achieving widespread deployment in libp2p. When a browser connects to a website, in practically all cases, it does so via HTTPS. This means that the server needs a valid TLS certificate signed by a Certificate Authority like Let's Encrypt.</p> However, most libp2p nodes don't have such a certificate. This is because libp2p nodes constitute a decentralized peer-to-peer network where participants can run nodes on home laptops or browsers and join or leave the network at will. Most nodes don't even possess a domain name.</p> Meet WebTransport</a></h2> Thankfully, WebTransport addresses almost all of the pain points when using WebSocket!</p> Conceptually, WebTransport is similar to WebSocket, although it's a new protocol on the wire. The browser can "upgrade" an HTTP/2 or an HTTP/3 connection to a WebTransport session</strong>. HTTP/3 runs on top of QUIC. A WebTransport session over HTTP/3 allows both endpoints to open (very thinly wrapped) QUIC streams to each other. This enables WebTransport to take advantage of QUIC's offerings:</p> Speedy time to connect using a fast handshake (just one network roundtrip)</li> Native stream multiplexing without head-of-line blocking</li> Advanced loss recovery and congestion control</li> Low latency communication and unordered and unreliable delivery of data</li> </ul> Certificate Hash Verification</a></h3> The most critical change for our peer-to-peer use case is the new verification option. The WebTransport browser API allows for two distinct modes:</p> Verification of the TLS certificate chain</strong>: This is precisely what the browser does when checking the certificate for any website it connects to.</li> Verification of the TLS certificate hash</strong>: The browser will trust the server if the hash of the certificate used during the handshake matches its expected hash.</li> </ol> Option (2) allows us to use WebTransport on any</em> libp2p node without manual configuration!</p> It works because when setting up a WebTransport server, the libp2p node will generate a self-signed TLS certificate and calculate the certificate hash. It then advertises the following multiaddress</a> to the network:</p> /ip4/1.2.3.4/udp/4001/quic/webtransport/certhash/<hash></code></p> The certhash</code> component of the multiaddress tells the browser the certificate hash, allowing it to establish the WebTransport connection successfully.</p> Deep dive: How WebTransport works</a></h3> The browser dials a regular HTTP/3 connection to the server, verifying the certificate either by its chain of trust or by the certificate's hash.</li> The browser sends an Extended CONNECT</code> request on an HTTP/3 stream, requesting establishing a WebTransport session. If the server sends a 200</code> HTTP status, the WebTransport session is successfully established.</li> </ol> </p> Both sides can now open streams (both bidirectional and unidirectional) and send (unreliable) HTTP datagrams.</p> In libp2p, we still need to verify the libp2p peer IDs, so we're not entirely done yet. The browser opens a new WebTransport stream and starts a Noise</a> handshake. This is the same handshake we use to secure connections on top of TCP in libp2p.</p> Therefore, setting up a WebTransport connection in libp2p takes no more than three network roundtrips</strong>. Compare that to the six roundtrips we needed for WebSocket!</p> Limitations</a></h3> WebTransport does not support browser-to-browser connectivity. To meet this need, libp2p implementations are adding support for WebRTC browser-to-server connectivity and browser-to-browser connectivity.</p> What's the current state of WebTransport, and where is it supported?</a></h2> State of Specifications</a></h3> The IETF specification of the protocol itself is still in the draft stage with ongoing revisions. The libp2p specification is here: libp2p WebTransport spec</a>.</p> State in Browsers</a></h3> Currently, WebTransport support is limited to Chromium browsers. See the Can I Use? page for more details</a>.</p> State in libp2p implementations</a></h3> WebTransport is supported in two libp2p implementations as an experimental feature:</p> go-libp2p as of v0.23.0</li> js-libp2p through the js-libp2p-webtransport npm package</li> </ul> </iframe> </div> Can I use this right now?</a></h2> Yes, please! WebTransport already works between browsers and servers in applications powered by go-libp2p and js-libp2p.</p> What use cases does this unlock?</a></h3> Enable browser nodes (or light clients) as "full" peers in a decentralized network</li> Enable browser extension crypto wallets to submit transactions directly to the blockchain</li> Get data from the DHT by directly connecting to a DHT server node</li> Upload to Filecoin directly from the browser</li> Enable decentralized peer-to-peer video streaming as a dapp</li> </ul> Resources and How you can help contribute</a></h2> Documentation on WebTransport</a></li> Connectivity site section on the protocol</a></li> Specification on WebTransport</a></li> </ul> If you would like to contribute, please connect with the libp2p maintainers</a>.</p> Thank you for reading!</p> libp2p Day 2022 Recap The libp2p Foundation — Tue, 22 Nov 2022 00:00:00 +0000 Last month, on October 30th 2022, libp2p users and contributors gathered together for the first ever libp2p Day!</p> The day included talks from maintainers, contributors, community members, and users. Topics included latest libp2p updates, preview of future roadmap items, bleeding-edge demos on browser connectivity using new transport protocols, and much more.</p> Speakers shared new, exciting developments built on libp2p and represented organizations like Little Bear Labs, ChainSafe Systems, Status.im, Gather, Quiet, Pyrsia, Satellite.im, and Protocol Labs.</p> In the larger context, libp2p Day was hosted at IPFS Camp 2022</a> as a part of a diverse lineup.</p> Goals</a></h3> The goals of libp2p Day were to:</p> Share updates on libp2p and highlight new developments through demos</li> Gather the libp2p ecosystem, give a spotlight to projects building on libp2p, and energize the community</li> Empower newcomers and existing users to become contributors and spec authors</li> </ol> Key Takeaways</a></h3> Browser Connectivity Unlocked</a></h4> First-class support for WebTransport enables libp2p nodes running in the browser to connect directly with peers on a host machine. WebRTC browser-to-server has also made significant progress.</p> Check out the new libp2p connectivity guide</a>.</p> libp2p Interoperability</a></h4> The libp2p ecosystem continues to flourish with several implementations, each with its own set of supported features. libp2p teams are focusing on testing interoperability.</p> Demand for libp2p + HTTP</a></h4> With the growing demand for libp2p + HTTP, the team has started drafting an HTTP specification.</p> Recap of talks</a></h2> Intro to libp2p: helping with real world application problems</a></h3> Max Inden (rust-libp2p maintainer, Software Engineer at Protocol Labs)</p> </iframe> </div> Max introduced libp2p covering transport protocols, secure channels, multiplexing mechanisms, how libp2p traverses NATs, discovers peers, uses Kademlia for peer-to-peer routing, and GossipSub for pub/sub messaging.</p> For all the talk recordings, visit the IPFS Camp 2022 archive</a>.</p>

libp2p - A modular network stack

libp2p Annual Report 2025

Announcing the release of nim-libp2p v1.15.2

Refactoring the libp2p Test Framework: A Fresh Start

Announcing the release of go-libp2p v0.47

Announcing the tag of py-libp2p v0.5.0

Announcing the release of js-libp2p v3.0.0

Announcing the release of rust-libp2p v0.56

Announcing AutoTLS: Bridging the Gap Between libp2p and the Web

Announcing the release of rust-libp2p v0.55

Introduction to libp2p Community Meetings

Announcing libp2p-rPGF-1, the first libp2p project RetroPGF Round!

The Process</a></h2> The rounds follow the Optimism template:</p> Badgeholders selection</li> Nominations/Application submissions</li> Voting by badgeholders</li> Publish voting results</li> Distribute rewards/funding</li>

libp2p Day at ETHDenver 2024 Recap

rust-libp2p in the Browser with WebRTC!

Announcing the release of js-libp2p v1.0.0

What's next?</a></h2> React Native Support</li> QUIC support</li> Improved documentation</li>

HTTP-P2P, HTTP with more Ps

Adding a QUIC API for Go's standard library TLS package

Testing all the libp2ps

Problems to solve</a></h2> Compose handles spinning up the test environment, but there were still problems to solve:</p> How do we define this test environment?</li> How do we share the listener's address to the dialer?</li>

Impact realized so far</a></h2> The system has already helped catch several bugs:</p> quic-go wrong cipher selection</li> Interop failure with Firefox WebRTC</li> zig-libp2p multistream-select issue</li> Interop issue with Yamux between rust-libp2p and js-libp2p</li>

Metrics in go-libp2p

Why Prometheus?</a></h2> We chose Prometheus over OpenCensus and OpenTelemetry because:</p> OpenCensus creates a lot of allocations, leading to increased GC pressure</li> OpenTelemetry's metrics API is still unstable</li>

libp2p at IPFS þing 2023 Recap