From ce8b77106edfed7b09f411abceb3255d395f0d6e Mon Sep 17 00:00:00 2001 From: Vasco Santos Date: Wed, 15 Jul 2020 13:34:52 +0200 Subject: [PATCH] chore: apply suggestions from code review Co-authored-by: Jacob Heun --- src/record/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/record/README.md b/src/record/README.md index fe0a1ff8..0a665fa5 100644 --- a/src/record/README.md +++ b/src/record/README.md @@ -60,7 +60,7 @@ const rec = ExampleRecord.createFromProtobuf(e.payload) All libp2p nodes keep a `PeerStore`, that among other information stores a set of known addresses for each peer, which can come from a variety of sources. -Libp2p peer records were created to enable the distribution of verifiable address records, which we can prove originated from the addressed peer itself. With such guarantees, libp2p is able to prioritize addresses based on their authenticity, with the most strict strategy being to only dial certified addresses (no strategies implemented at the time of writing). +Libp2p peer records were created to enable the distribution of verifiable address records, which we can prove originated from the addressed peer itself. With such guarantees, libp2p is able to prioritize addresses based on their authenticity, with the most strict strategy being to only dial certified addresses (no strategies have been implemented at the time of writing). A peer record contains the peers' publicly reachable listen addresses, and may be extended in the future to contain additional metadata relevant to routing. It also contains a `seqNumber` field, a timestamp per the spec, so that we can verify the most recent record.