# Introduction [libp2p](https://libp2p.io/) is a modular network stack that evolved out of [IPFS](https://ipfs.io/) to become an independent project. In order to explain why libp2p is such an important piece of the decentralized web, we need to take a few steps back and understand where it came from. libp2p's initial implementation began inside of IPFS, a peer-to-peer file sharing system. Let's start by exploring the networking problems that IPFS was built to tackle. # Web 2.0 We've grown to love the internet and use it in many aspects of our everyday lives, for studying, connecting with friends and family, shopping, managing our finances, and much more. We've become dependent on the internet to a point where we really need it to be reliable and safe, but that's not really the case in this day and age. We've all experienced connectivity issues, and we also feel that our identity and data are not safe across the multiple online services that we use daily. For example, if you want to send a photo to a friend that lives in the same street, the number of service providers the photo passes through is too high: your phone will capture the image and send it through the network until it reaches the application servers (possibly overseas); the server will then store the photo in a database, analyze it for facial recognition to suggest tagging friends in the picture, and send a notification to your friend's device; and finally your friend will check the notification and load the photo from the overseas database. There are so many things that can go wrong in this scenario, and the truth is, you probably didn't want the photo to be stored in some far away database which you can't delete. You just wanted to share your photo directly with your friend. # Location Addressing vs Content Addressing A lot of the issues that we face come from using a location addressing approach to find the content the user is looking for, and serving it from that address. For example, we expect our libp2p logo to be available at https://proto.school/tutorial-assets/T0009L01-libp2p-logo.svg, but what if the server of this website is down? What if the DNS server is down? What if the image was converted to a PNG file and so the new location is `T0009L01-libp2p-logo.png`? What if you are in a country that has blocked the `proto.school` domain? All of these issues are common ones and are caused by location addressing, where we try to find the content we need by its location. [IPFS](https://ipfs.io/), however, approaches this problem in a different way by using content addressing instead. If we know the CID (Content IDentifier) of our libp2p logo instead of its location, we can simply ask the network who has the image with this CID. The advantages in this approach are very appealing since they solve all the other issues previously mentioned, but to get it right there are other problems that need to be tackled first, specifically within networking. # Networks are complex To have a web powered by "Content Addressing", we need to redesign and re-imagine how computer networks work. Networks are very complex systems that have their own rules and restrictions, and so when designing these systems, we need to take into account a lot of situations and use cases: - **Firewalls**: You might have a firewall installed in your laptop that blocks or restricts specific connections. - **NAT**: Your home WiFi router with NAT (Network Address Translation), which translates your local IP address of your laptop to a single IP address that networks outside your home can connect to. - **High latency networks**: These networks have very slow connections and leave users waiting a long time to see their content. - **Reliability**: There are many networks scattered around the world, and more often than not, a lot of users encounter slow networks that don't have robust systems in place to offer good connectivity to users. Connections drop frequently and users are left with a subpar network system that doesn't serve the users as it should. - **Roaming**: Mobile addressing is another situation where we need to guarantee that the users' devices remain uniquely discoverable when navigating through different networks across the world. Currently they work in a distributed system that requires a lot of coordination points and connections, but the best solution would be a decentralized one. - **Censorship**: In the current state of the web, blocking a website at a specific website domain is relatively easy to do if you are a governmental entity. This is useful to block illegal activity, but becomes a problem when, for example, an authoritarian regime wants to remove access to resources from its population. - **Runtimes with different properties**: There are numerous types of runtimes around, such as IoT (Internet of Things) devices (Raspberry Pi, Arduino, etc) which are gaining a lot of adoption. Because they're built with limited resources, their runtimes often use different protocols that make a lot of assumptions about their runtime. - **Innovation is very slow**: Even the most successful companies with a lot of resources can take decades to develop and deploy new protocols. - **Data Privacy**: Consumers have become increasingly concerned lately about the growing number of companies that do not respect users' privacy. Ouch, this is a long list! But these are the issues that IPFS had to solve in order to create successful P2P (Peer-to-Peer) communications. The truth is, as we will see in the next lesson, IPFS is not the first project to try and solve these issues and create a P2P network.

# The current problem with P2P protocols Peer-to-peer (P2P) networks were envisioned from the very conception of the internet as a way to create resilient networks that would function even if peers disconnected from the network due to major natural or human disasters, allowing people to continue to communicate. P2P networks can be used for a variety of use cases, from video calls (eg Skype) to file sharing (eg IPFS, Gnutella, KaZaA, eMule, and BitTorrent). # Reinventing the wheel One of the main challenges that all apps with P2P connections have to solve is discoverability: how can two or more peers find each other and share information? In the past, each P2P app has tackled this problem (among many others) and implemented their own solutions with different ideas and approaches customized to their individual use case. IPFS searched for inspiration in current and past networking applications and research to try and improve its P2P system. There were plenty of scientific papers from the world of academia that provided ideas on how to solve some of these issues, but while research yielded preliminary results, it lacked code implementations that could be used and adapted. Code implementations of existing P2P systems were really hard to find, and where they did exist, they were often hard to re-use or re-purpose due to: - Poor or non-existent documentation - Restrictive licensing or no license to be found - Very old code with the last update more than a decade ago - No point of contact (no maintainer available to reach) - Closed source (private) code - Deprecated products - No specifications provided - No friendly API exposed - Implementations too tightly coupled with a specific use case - Not upgradable with future protocols So in the end, every time P2P protocols were needed, developers would solve the same challenges again and again from scratch because the P2P protocols already embedded in software packages weren't extractable and reusable. One would think that this was a problem of the past. The open-source community has evolved over the years and built a robust ecosystem that provides thousands of open-source software packages that include a thorough battery of test suites, good documentation, and friendly APIs. But unfortunately, no good P2P protocol implementation had appeared that solved all of the presented issues across a variety of use cases. Historically, companies that produced products like Skype or BitTorrent created their own protocols to support them. Those protocols made a lot of assumptions about the environments they'd run in and the needs they'd meet, making them incredibly hard to upgrade or adapt to new environments. # The solution Of course the answer to all of these problems was a shiny new protocol that solved all of these problems once and for all! Well... not exactly. ![https://proto.school/tutorial-assets/T0009L02-standards-comic-xkcd.png](https://proto.school/tutorial-assets/T0009L02-standards-comic-xkcd.png) There had to be a better way. Seeing that the main issue was interoperability, the IPFS team envisioned a better way to integrate all current solutions and provide a platform that facilitated innovation. A new modular system that would enable future solutions to be seamlessly integrated into the networking stack. **Enter libp2p**

libp2p is the networking stack of IPFS, but extracted away from IPFS, becoming a first class project and a dependency of IPFS itself. ![https://proto.school/tutorial-assets/T0009L03-libp2p-ipfs-animation.gif](https://proto.school/tutorial-assets/T0009L03-libp2p-ipfs-animation.gif) This way, libp2p is able to grow further without being attached specifically to IPFS, gaining its own ecosystem and community. IPFS simply becomes one of the many users of libp2p. This way each project can solely focus on their own objectives: - IPFS is more focused on **content addressing**, i.e., finding, fetching and authenticating any piece of content in the web. - libp2p is more focused on **process addressing**, i.e., finding, connecting and authenticating any data transfer processes in the network. Finding, connecting and authenticating any process in the network is a bold claim to make. So how has libp2p done it? The answer is **modularity**. ## Modularity ![https://proto.school/tutorial-assets/T0009L03-libp2p-logo-animation.gif](https://proto.school/tutorial-assets/T0009L03-libp2p-logo-animation.gif) libp2p has identified specific pieces that can makeup a network stack: ![https://i.imgur.com/FyAoCBJ.png](https://i.imgur.com/FyAoCBJ.png) For the purpose of this tutorial, you don't need to understand what all of these pieces are, but it's important to understand how many components there are to consider when building a network stack. If you want to learn more about these individual components, you can check out the [Concepts](https://docs.libp2p.io/concepts/) page in libp2p's documentation. A user can choose the specific pieces they need and compose their own configuration, tailored for their use cases. All of those pieces have very well defined **interfaces** that enable interoperability and easy upgrades, creating a future-proof networking stack. ![https://proto.school/tutorial-assets/T0009L03-libp2p-interfaces.png](https://proto.school/tutorial-assets/T0009L03-libp2p-interfaces.png) By providing consistent interfaces, libp2p enables the creation of an ecosystem of interoperable modules. Think of the interfaces as the studs on the top of your LEGO bricks and connection points underneath them... LEGO can create an endless variety of new pieces that will fit together perfectly, so long as they all use the same method to stick together. Let's compare it to furniture shopping. Sure, you can spend long weeks searching for the perfect couch you like that will fit your living room perfectly, but in the end, it's still not exactly as you wanted it to be. What if instead, you could go to an online store that allowed you to order your own couch, set up with exactly the colors you materials you wanted. This couch company has identified the basic building blocks that make up a couch (1-seater, 2-seater or 3-seater? With or without chaise lounge? Velvet, fiber or leather?), and has provided a web service that allows customers to customize the couch they want. No matter what pieces you choose, they're designed to fit together perfectly. And if you change your mind a month later, you can swap out the fabric or add an extra seat, no problem. This is the modularity that libp2p provides. It has formalized networking's building blocks into interfaces (Transport, Discovery, etc) so that they can be implemented in different ways (TCP, UDP, etc). For example, let's look at the Transport interface. Transports are a collection of foundational protocols that define how data is transferred. Even within this one module, there are many decisions to make, such as how many bytes are sent with each chunk of data, whether they should be verified for integrity individually or all at once, etc. ![https://proto.school/tutorial-assets/T0009L03-libp2p-interface-transport.png](https://proto.school/tutorial-assets/T0009L03-libp2p-interface-transport.png) We can see seven modules that implement the transport interface. So if we want to switch the transport protocol from *TCP* to *WebSockets* we can do that easily by simply switching from `js-libp2p-tcp` to `js-libp2p-websockets`. If we're missing a module that needs to be implemented, we can create the module and its interface ourselves and use the test suite provided with the interface to validate its implementation. Accordingly, you could plug in our own `libp2p-mail` transport like any other available libp2p transport.

# Architecture So where does libp2p fit into the current web? The web is built on a complex system of networking protocols, some of which are familiar to end users, like HTTP and ethernet, and some of which are only familiar to networking specialists. Usually, we look at the **OSI Model (Open Systems Interconnection Model)** to understand which layer a protocol tries to tackle. ![https://proto.school/tutorial-assets/T0009L04-osi-model.png](https://proto.school/tutorial-assets/T0009L04-osi-model.png) But the truth is, the `OSI Model` as well as the `TCP/IP Model` are just conceptual models. The actual implementations in the current web do not follow these models exactly, and are much less tidy, e.g. the `TCP/IP Protocol Suite` shown above. In the end, these models have some shortcomings: - Actions are repeated through multiple layers (repeated work) because data can go through authentication multiple times or discovery multiple times; it's very inefficient! - Information is hidden between layers, missing significant improvement opportunities, and some protocols have been created with these opportunities in mind by trying to put together as many layers as possible into a single protocol module, such as the [QUIC](https://www.chromium.org/quic) protocol. libp2p set out to do something different when it became apparent that following these rigid conceptual models was not ideal - others were already breaking them. By allowing users to select and configure just the pieces of a network stack that they need, libp2p has created a new way to maintain and upgrade applications with a secure, reliable, and modular network stack.

libp2p has multiple implementations and they all interop with each other. At the time of writing, libp2p has 7 native implementations: ![https://i.imgur.com/yy1eJ9L.png](https://i.imgur.com/yy1eJ9L.png) # Browser Support The JavaScript implementation of libp2p works in browsers and mobile browsers too! This is very important because it enables applications to run libp2p on the desktop and mobile devices as well. ![https://proto.school/tutorial-assets/T0009L05-libp2p-browser.png](https://proto.school/tutorial-assets/T0009L05-libp2p-browser.png) As a modular networking stack, libp2p is designed to be able to suit a variety of project needs. The configuration of libp2p is a key part of its structure. It enables you to use exactly the features you need, and only what you need. For example, it can configure libp2p modules such as `libp2p-tcp` and `libp2p-websockets`. And you only need to change a few lines of code in the libp2p configuration to go from the `NodeJs` version to the browser version. Let's take a look at what a `NodeJs` libp2p configuration would look like, using `js-libp2p` version `0.30`: ```js 'use strict' const TCP = require('libp2p-tcp') const MulticastDNS = require('libp2p-mdns') const WS = require('libp2p-websockets') const WebSocketStar = require('libp2p-websocket-star') const Bootstrap = require('libp2p-bootstrap') const KadDHT = require('libp2p-kad-dht') const Multiplex = require('libp2p-mplex') const { NOISE } = require('libp2p-noise') const libp2p = require('libp2p') const defaultsDeep = require('@nodeutils/defaults-deep') const defaultConfiguration = { modules: { transport: [TCP, WS, WebSocketStar], streamMuxer: [Multiplex], connEncryption: [NOISE], peerDiscovery: [MulticastDNS, Bootstrap, WebSocketStar.discovery], dht: KadDHT }, config: { peerDiscovery: { mdns: { enabled: true }, bootstrap: { enabled: true }, websocketStar: { enabled: true } }, dht: { kBucketSize: 20 } } } module.exports = async (options) => ( libp2p.create(defaultsDeep(options, defaultConfiguration)) ) ``` The first part imports all the necessary libp2p modules that make up this network stack. The second part is the libp2p node configuration where we add the different modules for each part of the network. In this configuration we are using `transport`, `streamMuxer`, and `connEncryption`, which are required for all libp2p nodes, as well as the optional `peerDiscovery` and `dht` modules. For this code to run in the browser, which [doesn't support TCP transports](https://github.com/libp2p/js-libp2p/blob/master/doc/CONFIGURATION.md#transport), we only need to change the `transport` protocols and `peerDiscovery` protocols in our libp2p configuration. No other changes in the application are required! ![https://proto.school/tutorial-assets/T0009L05-libp2p-configuration-diff-node.png](https://proto.school/tutorial-assets/T0009L05-libp2p-configuration-diff-node.png "`TCP` and `WebSockets` in `transport`; `MulticastDNS` in `peerDiscovery`") ![https://proto.school/tutorial-assets/T0009L05-libp2p-configuration-diff-browser.png](https://proto.school/tutorial-assets/T0009L05-libp2p-configuration-diff-browser.png "`WebSockets` and `WebRTC` in `transport`; `WebRTC` derived discovery ") In this example, we only had to change very few lines of code to configure a libp2p node that runs in the browser. The simplicity of editing configurations to adapt to new environments is one of the key advantages of libp2p.

# Applications using libp2p There are a lot of services using libp2p at the moment, for applications including file storage, video streaming, crypto wallets, dev tools, and blockchains. Here we list some examples, but the list continues to grow as you read this. ![https://i.imgur.com/czafqRf.png](https://i.imgur.com/czafqRf.png) IPFS uses libp2p extensively, so all other services depending on IPFS indirectly use libp2p as well. # Resources Ready to learn more? There are plenty of additional resources to explore, both in ProtoSchool and beyond. Here are some of our favorites: [**libp2p Website**](https://libp2p.io/) Explore libp2p's native implementations, videos of conference talks, specifications, and documentation. [**libp2p Documentation**](https://docs.libp2p.io/) Dig deeper into libp2p's concepts and modules on its docs site, which includes a glossary and code examples across Go, JavaScript, and Rust implementations. [**Introduction to libp2p**](https://www.youtube.com/watch?v=CRe_oDtfRLw) Watch the talk from David Dias that heavily inspired this tutorial, in which he explains we need libp2p, how it works, and what its future objectives are. [**js-libp2p Code Examples**](https://github.com/libp2p/js-libp2p/tree/master/examples) Explore libp2p code examples in JavaScript, indluding a chat app, browser, encrypted communications, peer and content routing, and more. [**Getting started with js-libp2p**](https://github.com/libp2p/js-libp2p/blob/master/doc/GETTING_STARTED.md) Walk through the process of setting up a fully functional js-libp2p node using JavaScript. 🚀 [**js-libp2p Configuration**](https://github.com/libp2p/js-libp2p/blob/master/doc/CONFIGURATION.md) Learn how to configure js-libp2p for your particular project. [**go-libp2p Code Examples**](https://github.com/libp2p/go-libp2p-examples) Explore libp2p code examples in the Go programming language, including a chat app, a basic getting started echo client and server example, and more.