From db2e8907d854b1b0fbf6ed55bdea36133a056f81 Mon Sep 17 00:00:00 2001 From: Vasco Santos Date: Thu, 9 Apr 2020 12:54:48 +0200 Subject: [PATCH] chore: apply suggestions from code review Co-Authored-By: Jacob Heun --- doc/API.md | 6 +++--- src/peer-store/README.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/API.md b/doc/API.md index 4a95b2d866..78080182a8 100644 --- a/doc/API.md +++ b/doc/API.md @@ -519,7 +519,7 @@ const key = '/key' const { from, val } = await libp2p.contentRouting.get(key) ``` -### peerStore.addressBook.Add +### peerStore.addressBook.add Adds known `multiaddrs` of a given peer. If the peer is not known, it will be set with the provided multiaddrs. @@ -574,7 +574,7 @@ peerStore.addressBook.delete(peerId) ### peerStore.addressBook.get -Get the known [`MultiaddrInfos`](multiaddr-info) of a provided peer. +Get the known [`MultiaddrInfos`][multiaddr-info] of a provided peer. `peerStore.addressBook.get(peerId)` @@ -588,7 +588,7 @@ Get the known [`MultiaddrInfos`](multiaddr-info) of a provided peer. | Type | Description | |------|-------------| -| `Array` | Array of peer's multiaddr with their relevant information [`MultiaddrInfo`](multiaddr-info) | +| `Array` | Array of peer's multiaddr with their relevant information [`MultiaddrInfo`][multiaddr-info] | #### Example diff --git a/src/peer-store/README.md b/src/peer-store/README.md index a17b26c79a..a2f0a02b55 100644 --- a/src/peer-store/README.md +++ b/src/peer-store/README.md @@ -26,7 +26,7 @@ It is also possible to gather relevant information for peers from other protocol When the PeerStore data is updated, this information might be important for different parties. -Every time a peer needs to dial another peer, it is essential that it knows the multiaddrs used by the peer, in order to perform a successful dial to it. The same is true for pinging a peer. While the `AddressBook` is going to keep its data updated, it will also emit `change:multiaddrs` events so that subsystems/users interested in knowing these changes can be notifyied instead of pooling the `AddressBook`. +Every time a peer needs to dial another peer, it is essential that it knows the multiaddrs used by the peer, in order to perform a successful dial to it. The same is true for pinging a peer. While the `AddressBook` is going to keep its data updated, it will also emit `change:multiaddrs` events so that subsystems/users interested in knowing these changes can be notified instead of polling the `AddressBook`. Everytime a peer starts/stops supporting a protocol, libp2p subsystems or users might need to act accordingly. `js-libp2p` registrar orchestrates known peers, established connections and protocol topologies. This way, once a protocol is supported for a peer, the topology of that protocol should be informed that a new peer may be used and the subsystem can decide if it should open a new stream with that peer or not. For these situations, the `ProtoBook` will emit `change:protocols` events whenever supported protocols of a peer change.