![require(esm) Backported to Node.js 20, Paving the Way for ESM-Only Packages](https://cdn.sanity.io/images/cgdhsj6q/production/be8ab80c8efa5907bc341c6fefe9aa20d239d890-1600x1097.png?w=400&fit=max&auto=format)
Security News
require(esm) Backported to Node.js 20, Paving the Way for ESM-Only Packages
require(esm) backported to Node.js 20, easing the transition to ESM-only packages and reducing complexity for developers as Node 18 nears end-of-life.
@libp2p/peer-store
Advanced tools
Stores information about peers libp2p knows on the network
$ npm i @libp2p/peer-store
Libp2p's PeerStore is responsible for keeping an updated register with the relevant information of the known peers. It should be the single source of truth for all peer data, where a subsystem can learn about peers' data and where someone can listen for updates. The PeerStore comprises four main components: addressBook
, keyBook
, protocolBook
and metadataBook
.
The PeerStore manages the high level operations on its inner books. Moreover, the PeerStore should be responsible for notifying interested parties of relevant events, through its Event Emitter.
Several libp2p subsystems will perform operations that might gather relevant information about peers.
identify-push
message to communicate protocol changes to all connected peers, so that their PeerStore can be updated with the updated protocols.peer
event with the information of the discovered peer and this information will be added to the PeerStore by libp2p.multiaddr
, and no prior knowledge of the peer. If the node is able to establish a connection with the peer, it and its multiaddr is added to the PeerStore.KeyBook
.peer
event in the same way Peer Discovery does.When data in the PeerStore is updated the PeerStore will emit events based on the changes, to allow applications and other subsystems to take action on those changes. Any subsystem interested in these notifications should subscribe the PeerStore events
.
peer
event, so that interested parties can leverage this peer and establish a connection with it.change:protocols
event.multiaddrs
of a peer change, the PeerStore emits a change:multiaddrs
event.The PeerStore wraps four main components: addressBook
, keyBook
, protocolBook
and metadataBook
. Moreover, it provides a high level API for those components, as well as data events.
The addressBook
keeps the known multiaddrs of a peer. The multiaddrs of each peer may change over time and the Address Book must account for this.
Map<string, Address>
A peerId.toString()
identifier mapping to a Address
object, which should have the following structure:
{
multiaddr: <Multiaddr>
}
The keyBook
tracks the public keys of the peers by keeping their PeerId
.
Map<string, PeerId
A peerId.toString()
identifier mapping to a PeerId
of the peer. This instance contains the peer public key.
The protoBook
holds the identifiers of the protocols supported by each peer. The protocols supported by each peer are dynamic and will change over time.
Map<string, Set<string>>
A peerId.toString()
identifier mapping to a Set
of protocol identifier strings.
The metadataBook
keeps track of the known metadata of a peer. Its metadata is stored in a key value fashion, where a key identifier (string
) represents a metadata value (Uint8Array
).
Map<string, Map<string, Uint8Array>>
A peerId.toString()
identifier mapping to the peer metadata Map.
For the complete API documentation, you should check the API.md.
Access to its underlying books:
peerStore.addressBook.*
peerStore.keyBook.*
peerStore.metadataBook.*
peerStore.protoBook.*
peer
- emitted when a new peer is added.change:multiaadrs
- emitted when a known peer has a different set of multiaddrs.change:protocols
- emitted when a known peer supports a different set of protocols.change:pubkey
- emitted when a peer's public key is known.change:metadata
- emitted when known metadata of a peer changes.The data stored in the PeerStore can be persisted if configured appropriately. Keeping a record of the peers already discovered by the peer, as well as their known data aims to improve the efficiency of peers joining the network after being offline.
The libp2p node will need to receive a datastore, in order to persist this data across restarts. A datastore stores its data in a key-value fashion. As a result, we need coherent keys so that we do not overwrite data.
The PeerStore should not continuously update the datastore whenever data is changed. Instead, it should only store new data after reaching a certain threshold of "dirty" peers, as well as when the node is stopped, in order to batch writes to the datastore.
The peer id will be appended to the datastore key for each data namespace. The namespaces were defined as follows:
AddressBook
All the known peer addresses are stored with a key pattern as follows:
/peers/addrs/<b32 peer id no padding>
ProtoBook
All the known peer protocols are stored with a key pattern as follows:
/peers/protos/<b32 peer id no padding>
KeyBook
All public keys are stored under the following pattern:
/peers/keys/<b32 peer id no padding>
MetadataBook
Metadata is stored under the following key pattern:
/peers/metadata/<b32 peer id no padding>/<key>
Licensed under either of
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.
FAQs
Stores information about peers libp2p knows on the network
The npm package @libp2p/peer-store receives a total of 23,308 weekly downloads. As such, @libp2p/peer-store popularity was classified as popular.
We found that @libp2p/peer-store demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
require(esm) backported to Node.js 20, easing the transition to ESM-only packages and reducing complexity for developers as Node 18 nears end-of-life.
Security News
PyPI now supports iOS and Android wheels, making it easier for Python developers to distribute mobile packages.
Security News
Create React App is officially deprecated due to React 19 issues and lack of maintenance—developers should switch to Vite or other modern alternatives.