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
+44
Original file line number
Diff line number
Diff line change
@@ -83,7 +83,51 @@ Access to its underlying books:
83
83
-`change:multiaadrs` - emitted when a known peer has a different set of multiaddrs.
84
84
-`change:protocols` - emitted when a known peer supports a different set of protocols.
85
85
86
+
## Data Persistence
87
+
88
+
The data stored in the PeerStore will be persisted by default. 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.
89
+
90
+
---
91
+
TODO: Discuss if we should make it persisted by default now. Taking into consideration that we will use a MemoryDatastore by default, unless the user configures a datastore to use, it will be worthless. It might make sense to make it disabled by default until we work on improving configuration and provide good defauls for each environment.
92
+
---
93
+
94
+
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. Otherwise, it will be stored on a [memory datastore](https://github.com/ipfs/interface-datastore/blob/master/src/memory.js).
95
+
96
+
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.
97
+
98
+
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:
99
+
100
+
**AddressBook**
101
+
102
+
All the knownw peer addresses are stored with a key pattern as follows:
103
+
104
+
`/peers/addrs/<b32 peer id no padding>`
105
+
106
+
**ProtoBook**
107
+
108
+
All the knownw peer protocols are stored with a key pattern as follows:
109
+
110
+
`/peers/protos/<b32 peer id no padding>`
111
+
112
+
**KeyBook**
113
+
114
+
_NOT_YET_IMPLEMENTED_
115
+
116
+
All public and private keys are stored under the following pattern:
117
+
118
+
` /peers/keys/<b32 peer id no padding>/{pub, priv}`
119
+
120
+
**MetadataBook**
121
+
122
+
_NOT_YET_IMPLEMENTED_
123
+
124
+
Metadata is stored under the following key pattern:
125
+
126
+
`/peers/metadata/<b32 peer id no padding>/<key>`
127
+
86
128
## Future Considerations
87
129
88
130
- If multiaddr TTLs are added, the PeerStore may schedule jobs to delete all addresses that exceed the TTL to prevent AddressBook bloating
89
131
- Further API methods will probably need to be added in the context of multiaddr validity and confidence.
132
+
- When improving libp2p configuration for specific runtimes, we should take into account the PeerStore recommended datastore.
133
+
- 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