feat: certified addressbook

[vasco-santos]

This PR adds the signed peer records in the AddressBook as part of #653

Remaining:

• Identify service should use these new features to store self and fetch it

Needs:

• feat: signed peer records data types #681
• feat: exchange signed peer records in identify #682

The protobuf definition for persistence was inspired (copied) from go-libp2p, and the API to consume and get the records was inspired on go-libp2p CertifiedAddressBook interface.

---

The AddressBook was previously holding Map<string, Array<Address>>, which mapped a peer id string identifier to an Array of Address (object with multiaddr property). It was changed to Map<string, Array<Entry>>, where the Entry is an object containing { addresses: Array<Address>, record: { raw: Buffer, seqNumber: number} }. The Address now also includes a isCertified property that aims to allow subsystems to filter known multiaddrs of a peer that are certified without a need to unmarshall the record. The raw envelope is stored for being exchanged easily with other peers.

There are 3 remaining questions to be answered:

1. When the AddressBook receives a new peer record, should it replace the previously stored multiaddrs (not certified) by the new ones, or should it merge? If it merges, when the AddressBook receives a new peer record with different addresses from a previously stored record, what happens to the previously addresses marked as certified?
2. We emit change:multiaddrs when a peer has new multiaddrs. The question is, what if we already know a multiaddr but it is now certified? From the persistence layer standpoint, it is important to receive the event, but is this expected from a regular listener of the events?
3. (this we talked before, and we should just delay a decision and add it to Future Work section): When loading from the datastore on restart, should we ignore the multiaddrs stored that are not in the signed peer record?

[jacobheun]

1. When the AddressBook receives a new peer record, should it replace the previously stored multiaddrs (not certified) by the new ones, or should it merge? If it merges, when the AddressBook receives a new peer record with different addresses from a previously stored record, what happens to the previously addresses marked as certified?

Non certified addresses should be expired by TTL. When we receive a new Peer Record, the record with the highest sequence wins, the other certified addresses should be removed.

2. We emit change:multiaddrs when a peer has new multiaddrs. The question is, what if we already know a multiaddr but it is now certified? From the persistence layer standpoint, it is important to receive the event, but is this expected from a regular listener of the events?

We should trigger the change. While the underlying multiaddr didn't change, our state did. This is helpful for apps that may want to take action when addresses become certified.

3. (this we talked before, and we should just delay a decision and add it to Future Work section): When loading from the datastore on restart, should we ignore the multiaddrs stored that are not in the signed peer record?

We should check the TTL on load for these and only keep them if it hasn't expired.

I haven't checked the address book code yet, let me know if you want me to give that a pass.

[vasco-santos]

Since we now have self being stored in the AddressBook, should we filter out self in libp2p.peerStore.peers?
Note: the interop tests are breaking because the daemon is breaking because of this (trying to get a connection from self to self as a result of being present in the peerStore.peers)

[wemeetagain]

Just noticed that gossipsub v1.1 will need to import from this repo at runtime to access Envelope.openAndCertify. Not just a devDependency, as before.
Is this intended?

[vasco-santos]

Just noticed that gossipsub v1.1 will need to import from this repo at runtime to access Envelope.openAndCertify. Not just a devDependency, as before.
Is this intended?

Yes! I am not a fan of requiring stuff as libp2p/src/..., but the alternative is getting a mountain of repos. We are moving forward on having all modules tight with libp2p inside the libp2p repo. We can move it to its own repo/module in the future if we think it is valuable.

[jacobheun]

Why is this optional? I don't see a use case for it and it just adds unnecessary checks when filtering self out.

[jacobheun]

Why not just set the function here and avoid two names for the same method?

[vasco-santos]

Should we add a convenience method for getRawSelfEnvelope?
We are using this providing own peerId in the identify protocol, and I am also using it now in rendezvous

[jacobheun]

What's the need here? We should already have easy access to libp2p, libp2p.peerStore.addressBook.getRawEnvelope(libp2p.peerId), I'm not seeing what we'd gain from this.

[vasco-santos]

It is not needed, but could potentially help. I did not have access to the self peerId in the rendezvous server (in the previous PR state), and I needed to change everything to provide libp2p because of that. But yeah, it was mostly a question, we don't need it, it could just help in some cases

[jacobheun]

What's the need here? We should already have easy access to libp2p, libp2p.peerStore.addressBook.getRawEnvelope(libp2p.peerId), I'm not seeing what we'd gain from this.

[jacobheun]

LGTM, just 2 minor language suggestions.