You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: src/peer-store/README.md
+8-6
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,9 @@ Several libp2p subsystems will perform operations, which will gather relevant in
10
10
11
11
In a libp2p node's life, it will discover peers through its discovery protocols. In a typical discovery protocol, addresses of the peer are discovered along with its peer id. Once this happens, the PeerStore should collect this information for future (or immediate) usage by other subsystems. When the information is stored, the PeerStore should inform interested parties of the peer discovered (`peer` event).
12
12
13
-
Taking into account a different scenario, a peer might perform/receive a dial request to/from a unkwown peer. In such a scenario, the PeerStore must store the peer's multiaddr once a connection is established.
13
+
Taking into account a different scenario, a peer might perform/receive a dial request to/from a unkwown peer. In such a scenario, the PeerStore must store the peer's multiaddr once a connection is established.
14
+
15
+
When a connection is being upgraded, more precisely after its encryption, or even in a discovery protocol, a libp2p node can get to know other parties public keys. In this scenario, libp2p will add the peer's public key to its `KeyBook`.
14
16
15
17
After a connection is established with a peer, the Identify protocol will run automatically. A stream is created and peers exchange their information (Multiaddrs, running protocols and their public key). Once this information is obtained, it should be added to the PeerStore. In this specific case, as we are speaking to the source of truth, we should ensure the PeerStore is prioritizing these records. If the recorded `multiaddrs` or `protocols` have changed, interested parties must be informed via the `change:multiaddrs` or `change:protocols` events respectively.
16
18
@@ -42,7 +44,7 @@ The `addressBook` keeps the known multiaddrs of a peer. The multiaddrs of each p
42
44
43
45
`Map<string, Address>`
44
46
45
-
A `peerId.toString()` identifier mapping to a `Address` object, which should have the following structure:
47
+
A `peerId.toB58String()` identifier mapping to a `Address` object, which should have the following structure:
46
48
47
49
```js
48
50
{
@@ -52,19 +54,19 @@ A `peerId.toString()` identifier mapping to a `Address` object, which should hav
52
54
53
55
#### Key Book
54
56
55
-
The `keyBook` tracks the publick keys of the peers by keeping their [`PeerId`][peer-id].
57
+
The `keyBook` tracks the public keys of the peers by keeping their [`PeerId`][peer-id].
56
58
57
59
`Map<string, PeerId`
58
60
59
-
A `peerId.toString()` identifier mapping to a `PeerId` of the peer. This instance contains the peer public key.
61
+
A `peerId.toB58String()` identifier mapping to a `PeerId` of the peer. This instance contains the peer public key.
60
62
61
63
#### Protocol Book
62
64
63
65
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.
64
66
65
67
`Map<string, Set<string>>`
66
68
67
-
A `peerId.toString()` identifier mapping to a `Set` of protocol identifier strings.
69
+
A `peerId.toB58String()` identifier mapping to a `Set` of protocol identifier strings.
68
70
69
71
#### Metadata Book
70
72
@@ -129,4 +131,4 @@ Metadata is stored under the following key pattern:
129
131
- When improving libp2p configuration for specific runtimes, we should take into account the PeerStore recommended datastore.
130
132
- When improving libp2p configuration, we should think about a possible way of allowing the configuration of Bootstrap to be influenced by the persisted peers, as a way to decrease the load on Bootstrap nodes.
0 commit comments