Skip to content

v0.28.0

Compare
Choose a tag to compare
@jacobheun jacobheun released this 05 Jun 13:32
5299995

🔦 Highlights

📜 Improved PeerStore towards v2

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 data updates.

The initial design of the PeerStore (formerly known as peer-book) was not implemented with some functionalities in mind that we plan to land over the next releases, so that node connectivity and connection management are improved.

The PeerStore will now comprise four main components: addressBook, keyBook, protoBook and metadataBook. With this separation of concerns, libp2p now provides a PeerStore API so that known data of a peer can be easily added and a persistence layer, in order to enable faster connectivity on subsequent node starts, since it will not to discover the stored peers one more time to establish a connection with them.

With this revamp of the PeerStore, the building blocks for the PeerStore v2 are created. As a result, we will be able to focus on the PeerStore v2 over the coming releases, which might add multiaddr confidence, peer scoring, among other improvements aiming to improve connectivity efficiency and connection management.

♻️ Removed peer-info abstraction layer

PeerInfo is a libp2p peer abstraction layer that combines a PeerId with known data of the peer, namely its multiaddrs and protocols. It has been used for a long time by js-libp2p and its modules to carry this data around the libp2p stack, as well as by the libp2p API, both for providing this data to the users or to receive it from them.

Since this PeerInfo instances were navigating through the entire codebases, some data inconsistencies could be observed in libp2p. Different libp2p subsystems were running with different visions of the known peers data. For instance, a libp2p subsystem receives a copy of this instance with the peer multiaddrs and protocols, but if new data of the peer is obtained from other subsystem, it would not be updated on the former. Moreover, considering that several subsystems were modifying the peer data, libp2p had no visibility on which data was the updated and the older one.

Considering the complete revamp of the libp2p PeerStore towards its second version. With this new PeerStore acting as the single source of truth, we do not need to carry [PeerInfo][peer-info] instances around. This also solves all the problems stated above, since subsystems will report new observations to the PeerStore and it will provide clear and updated picture of the known peers' data.

Given that peer-info is being deprecated, all the API methods with parameters or return values were changed in favour of the peer-id. If someone need more information about the peer, it is now recommended to use the PeerStore API.

⚙️ Address Manager

With the deprecation of the peer-info module, js-libp2p must provide a new way of specifying which multiaddrs should be used by its underlying transports to listen for new connections. With this in mind and some other discussions regarding supporting announce and noAnnounce addresses in the past, we created the Address Manager.

With this release, js-libp2p supports the configuration of listen, announce and noAnnounce multiaddrs. These will be used to create the Address Manager (listen) and by other subsystems which announce the peer addresses to the outside world (announce and noAnnounce).

🛡️Noise handshake protocol

Thanks to NodeFactoryIo, js-libp2p now supports the noise handshake protocol through NodeFactoryIo/js-libp2p-noise module. This module is now fully supported and tested through the libp2p codebase and is interoperable with the noise implementation for go-libp2p.

🔒Out of the box keychain

Libp2p already provided the libp2p-keychain module that users could use for key management and cryptographically protected messages. However, users would need to properly setup the keychain as a separate piece of the stack.

In 0.28, libp2p keychain is now part of the libp2p core 🎉. As a result, libp2p users can now provide the keychain configuration through the libp2p config and use the keychain via its API, i.e libp2p.keychain.

🏗 API Changes

See the API.md readme for detailed usage on the new API and the migration guide v0.27 to v0.28.

Significant breaking changes are briefly listed below:

  • All peerInfo usage
  • libp2p.peerStore