chore: apply suggestions from code review

Co-authored-by: Jacob Heun <jacobheun@gmail.com>

src/index.js

@@ -47,12 +47,12 @@ class Libp2p extends EventEmitter {
     this.peerId = this._options.peerId
     this.datastore = this._options.datastore
 
-    this.peerStore = !(this.datastore && this._options.peerStore.persistence)
-      ? new PeerStore()
-      : new PersistentPeerStore({
+    this.peerStore = (this.datastore && this._options.peerStore.persistence)
+      ? new PersistentPeerStore({
         datastore: this.datastore,
         ...this._options.peerStore
       })
+      : new PeerStore()
 
     // Addresses {listen, announce, noAnnounce}
     this.addresses = this._options.addresses

src/peer-store/README.md

@@ -87,21 +87,21 @@ Access to its underlying books:
 
 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](https://github.com/ipfs/interface-datastore), in order to store this data in a persistent way. A [datastore](https://github.com/ipfs/interface-datastore) stores its data in a key-value fashion. As a result, we need coherent keys so that we do not overwrite data.
+The libp2p node will need to receive a [datastore](https://github.com/ipfs/interface-datastore), in order to persist this data across restarts. A [datastore](https://github.com/ipfs/interface-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 be continuously updating the datastore with the new data observed. Accordingly, it should only store new data after reaching a certain threshold of "dirty" peers, as well as when the node is stopped.
+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.
 
-Taking into account that a datastore allows queries using a key prefix, we can find all the information if we define a consistent namespace that allow us to find the content without having any information. The namespaces were defined as follows:
+The peer id will be appended to the datastore key for each data namespace. The namespaces were defined as follows:
 
 **AddressBook**
 
-All the knownw peer addresses are stored with a key pattern as follows:
+All the known peer addresses are stored with a key pattern as follows:
 
 `/peers/addrs/<b32 peer id no padding>`
 
 **ProtoBook**
 
-All the knownw peer protocols are stored with a key pattern as follows:
+All the known peer protocols are stored with a key pattern as follows:
 
 `/peers/protos/<b32 peer id no padding>`