# Leveraging libp2p to solve NAT traversal & replace TURN in Jami **URL:** \ **Category:** Product requests and ideas\ **Created:** [March 17, 2026, 4:43pm UTC](https://forum.jami.net/t/leveraging-libp2p-to-solve-nat-traversal-replace-turn-in-jami/5542 "2026-03-17T16:43:15Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![kda2210](https://forum.jami.net/user_avatar/forum.jami.net/kda2210/32/1493_2.png) [@kda2210](https://forum.jami.net/u/kda2210)\ **Post date:** [March 17, 2026, 4:43pm UTC](https://forum.jami.net/t/leveraging-libp2p-to-solve-nat-traversal-replace-turn-in-jami/5542/1 "2026-03-17T16:43:16Z")
Hello everyone, I recently wrote an article analyzing why Jami sometimes struggles in modern networks (especially with CGNAT and DPI), and suggested some architectural improvements: [Habr](https://habr.com/ru/articles/1010720). In the comments, someone mentioned **libp2p** – a modular toolkit for building P2P applications (used in IPFS, Ethereum). After reading about it, I was surprised to see that many of the features I proposed (like peer relaying instead of TURN, built-in QUIC support, advanced NAT traversal) already exist in libp2p out of the box. I’m not a developer, so I can’t judge how hard it would be to integrate, but it seems like libp2p could solve a lot of the network issues Jami faces today. Has the team ever considered using libp2p as a foundation, or borrowing some of its ideas (like Circuit Relay for decentralized TURN replacement)? I’d be happy to help test any experimental builds in difficult Russian networks (CGNAT, DPI) if that’s useful. Thanks for your work on Jami! ---
**Author:** ![ovari](https://forum.jami.net/letter_avatar_proxy/v4/letter/o/e274bd/32.png) [@ovari](https://forum.jami.net/u/ovari)\ **Post date:** [March 18, 2026, 8:49am UTC](https://forum.jami.net/t/leveraging-libp2p-to-solve-nat-traversal-replace-turn-in-jami/5542/2 "2026-03-18T08:49:34Z")
A commenter in your [Habr](https://habr.com/ru/articles/1010720) article mentioned another possible solution, the **Yggdrasil** network. > Yggdrasil is an _ **early-stage implementation** _ of a fully end-to-end encrypted IPv6 network. It is lightweight, self-arranging, supported on multiple platforms and allows pretty much any IPv6-capable application to communicate securely with other Yggdrasil nodes. Yggdrasil does not require you to have IPv6 Internet connectivity - it also works over IPv4. > > Yggdrasil is a new _ **experimental** _ compact routing scheme. It is designed to be a future-proof and decentralised alternative to the structured routing protocols commonly used today on the Internet, as well as an enabling technology for future large-scale mesh networks. Yggdrasil is: > > - **Scalable** > Supports large, complex or even Internet-scale topologies > - **Self-healing** > Network responds quickly to connection failures or mobility events > - **Encrypted** > Traffic sent across the network is always fully end-to-end encrypted > - **Peer-to-peer** > Works entirely ad-hoc by design with no built-in points of centralisation > - **Cross-platform** > Supported on Linux, macOS, Windows, iOS, Android and more > **[Yggdrasil Network](https://yggdrasil-network.github.io/)** > > End-to-end encrypted IPv6 networking to connect worlds > **[GitHub - yggdrasil-network/yggdrasil-go: An experiment in scalable routing as an encrypted...](https://github.com/yggdrasil-network/yggdrasil-go)** > > An experiment in scalable routing as an encrypted IPv6 overlay network Should this be added as an issue using the following guide? > **[Bug report guide — Jami documentation](https://docs.jami.net/user/bug-report-guide.html)** ---
**Author:** ![kda2210](https://forum.jami.net/user_avatar/forum.jami.net/kda2210/32/1493_2.png) [@kda2210](https://forum.jami.net/u/kda2210)\ **Post date:** [March 18, 2026, 9:28am UTC](https://forum.jami.net/t/leveraging-libp2p-to-solve-nat-traversal-replace-turn-in-jami/5542/3 "2026-03-18T09:28:58Z")
I understand the appeal of Yggdrasil as a quick solution. But my main interest, as I’ve said, is to make Jami a **self-sufficient and free tool** , independent of any external ‘overlays’. This is precisely why libp2p is so interesting to me — it embeds itself inside and becomes a part of Jami, rather than another layer. After all, if we are ready to tolerate external dependencies, why not just use Keet, which already has all of this implemented? But Keet is closed, while Jami is open. It is precisely this **openness and self-sufficiency** that is its main advantage, which we must preserve and strengthen, not dilute. ---
**Author:** ![kda2210](https://forum.jami.net/user_avatar/forum.jami.net/kda2210/32/1493_2.png) [@kda2210](https://forum.jami.net/u/kda2210)\ **Post date:** [March 18, 2026, 10:36am UTC](https://forum.jami.net/t/leveraging-libp2p-to-solve-nat-traversal-replace-turn-in-jami/5542/4 "2026-03-18T10:36:41Z")
I’ve created an official feature request on GitLab based on our discussion: [issue](https://git.jami.net/savoirfairelinux/jami-client-android/-/issues/1955). Everyone interested, please feel free to comment and upvote there to show your support!