libp2p's superpower is its modularity. Learn more in ProtoSchool's Introduction to libp2p (opens new window) tutorial.
# Peer-to-peer network applications
A peer-to-peer network (opens new window) is one in which the players, known as "peers", communicate with each other directly as equal participants. This is in direct contrast to the traditional client-server model (opens new window), where a privileged central server may provide services to many client programs on the network. These client programs usually do not communicate with each other; they communicate only with the central server.
Someone using Libp2p for the network layer of their peer-to-peer application is instantly freed up to focus on their own unique tasks, knowing that Libp2p handles a lot of tasks in a decentralized system (opens new window). At the same time, they can customize Libp2p regarding key elements like transport, identity, and security. Some applications using Libp2p are Filecoin (opens new window), Parity (opens new window), and OpenBazaar (opens new window).
# Features of Libp2p
Libp2p works with a lot of different addressing schemes in a consistent way. A multiaddress (abbreviated multiaddr (opens new window)) encodes multiple layers of addressing information into a single "future-proof" path structure. For example,
/ipv4/184.108.40.206/udp/162 indicates the use of the IPv4 protocol with the address 220.127.116.11, along with sending UDP packets to port 162.
The technology used to move your data from one machine to another. Transports are defined in terms of two core operations, listening and dialing. Listening means that you can accept incoming connections from other peers. Dialing is the process of opening an outgoing connection to a listening peer. One of Libp2p's core requirements is to be transport agnostic, meaning the decision of what transport protocol to use is up to an application's developer (who may decide to support many different transports at the same time).
Libp2p supports upgrading a transport connection into a securely encrypted channel. You can then trust the identity of the peer you're communicating with and that no third-party can read the conversation or alter it in-flight. The current default is TLS 1.3 (opens new window) as of IPFS 0.7. The previous default of SECIO (opens new window) is now deprecated and disabled by default (see this blog post (opens new window) for more information).
A Peer Identity (often written PeerId (opens new window)) is a unique reference to a specific peer on the peer-to-peer network. Each Libp2p peer has a private key, which it keeps secret from all other peers, and a corresponding public key, which is shared with other peers. The PeerId is a cryptographic hash (opens new window) of a peer's public key. PeerIds are encoded using the multihash (opens new window) format.
Peer Routing is the process of discovering peer addresses by using the knowledge of other peers. In a peer routing system, a peer can either give us the address we need if they have it or else send our inquiry to another peer who's more likely to have the answer. Peer Routing in Libp2p uses a distributed hash table (opens new window) to iteratively route requests closer to the desired PeerId using the Kademlia (opens new window) routing algorithm.
In Content discovery, you ask for some specific piece of data, but you don't care who sends it since you're able to verify its integrity. Libp2p provides a content routing interface (opens new window) for this purpose, with the primary stable implementation using the same Kademlia (opens new window)-based DHT as used in peer routing.
Network Address Translation (NAT) allows you to move traffic seamlessly between network boundaries. NAT maps an address from one address space to another. While NAT is usually transparent for outgoing connections, listening for incoming connections requires some configuration. Libp2p has the following main approaches to NAT traversal available: Automatic router configuration (opens new window), Hole punching (STUN) (opens new window), AutoNAT (opens new window), and Circuit Relay (TURN) (opens new window).
These are the protocols built with Libp2p itself, using core Libp2p abstractions like transport (opens new window), peer identity (opens new window), and addressing (opens new window). Each Libp2p protocol has a unique string identifier used in the protocol negotiation (opens new window) process when connections are first opened. The core Libp2p protocols are Ping (opens new window), Identify (opens new window), secio (opens new window), kad-dht (opens new window), and Circuit Relay (opens new window).
Often abbreviated as stream muxing, this allows multiple independent logical streams to all share a common underlying transport medium. Libp2p's stream multiplexer sits "above" the transport stack and allows many streams to flow over a single TCP port or other raw transport connection. The current stream multiplexing implementations are mplex (opens new window), yamux (opens new window), quic (opens new window), spdy (opens new window), and muxado (opens new window).
Often abbreviated as pub-sub, this is a system where peers congregate around topics they are interested in. Peers interested in a topic are said to be subscribed to that topic. Peers send messages to topics, which get delivered to all peers subscribed to the topic. Example uses of pub-sub are chat rooms and file sharing. For more detail and a discussion of other pub-sub designs, see the gossipsub specification (opens new window).
# Additional resources
- What is Libp2p? (opens new window)
- Introduction to Libp2p (opens new window)
- Getting started with Libp2p (opens new window)
- The Libp2p glossary (opens new window)
- The Libp2p specification (opens new window)
- ResNetLab on Tour - Content Routing (opens new window)
- ResNetLab on Tour - Content Exchange (opens new window)