When using channels (e.g. `futures::channel::mpsc` or `std::sync::mpsc`) always use the bounded variant, never use the unbounded variant. When using a bounded channel, a slow consumer eventually slows down a fast producer once the channel bound is reached, ideally granting the slow consumer more system resources e.g. CPU time, keeping queues small and thus latencies low. When using an unbounded channel a fast producer continues being a fast producer, growing the channel buffer indefinitely, increasing latency until the illusion of unboundedness breaks and the system runs out of memory. One may use an unbounded channel if one enforces backpressure through an out-of-band mechanism, e.g. the consumer granting the producer send-tokens through a side-channel.
Central repository for work on libp2p
This repository is the central place for Rust development of the libp2p spec.
Getting started
-
Main documentation can be found on https://docs.rs/libp2p.
-
The examples folder contains small binaries showcasing the many protocols in this repository.
-
For security related issues please reach out to security@libp2p.io. Please do not file a public issue on GitHub.
-
To report bugs, suggest improvements or request new features please open a GitHub issue on this repository.
-
For rust-libp2p specific questions please use the GitHub Discussions forum https://github.com/libp2p/rust-libp2p/discussions.
-
For discussions and questions related to multiple libp2p implementations please use the libp2p Discourse forum https://discuss.libp2p.io.
-
For general project updates and discussions join the biweekly libp2p Community Calls.
Repository Structure
The main components of this repository are structured as follows:
-
core/
: The implementation oflibp2p-core
with itsTransport
andStreamMuxer
API on which almost all other crates depend. -
transports/
: Implementations of transport protocols (e.g. TCP) and protocol upgrades (e.g. for authenticated encryption, compression, ...) based on thelibp2p-core
Transport
API . -
muxers/
: Implementations of theStreamMuxer
interface oflibp2p-core
, e.g. (sub)stream multiplexing protocols on top of (typically TCP) connections. Multiplexing protocols are (mandatory)Transport
upgrades. -
swarm/
: The implementation oflibp2p-swarm
building onlibp2p-core
with the central interfacesNetworkBehaviour
andConnectionHandler
used to implement application protocols (seeprotocols/
). -
protocols/
: Implementations of application protocols based on thelibp2p-swarm
APIs. -
misc/
: Utility libraries. -
examples/
: Worked examples of built-in application protocols (seeprotocols/
) with commonTransport
configurations.
Community Guidelines
The libp2p project operates under the IPFS Code of Conduct.
tl;dr
- Be respectful.
- We're here to help: abuse@ipfs.io
- Abusive behavior is never tolerated.
- Violations of this code may result in swift and permanent expulsion from the IPFS [and libp2p] community.
- "Too long, didn't read" is not a valid excuse for not knowing what is in this document.
Maintainers
(In alphabetical order.)
- Elena Frank (@elenaf9)
- Max Inden (@mxinden)
- Thomas Eizinger (@thomaseizinger)
Notable users
(open a pull request if you want your project to be added here)
- https://github.com/paritytech/polkadot
- https://github.com/paritytech/substrate
- https://github.com/sigp/lighthouse
- https://github.com/golemfactory/golem-libp2p
- https://github.com/comit-network
- https://github.com/rs-ipfs/rust-ipfs
- https://github.com/marcopoloprotocol/marcopolo
- https://github.com/ChainSafe/forest
- https://github.com/ipfs-rust/ipfs-embed
- https://www.actyx.com/developers/
- https://github.com/starcoinorg/starcoin