Peer Sharing - node handling of shared information

[njd42]

• what the lifecycle
  • what validation should be performed on received information
• how does it influence current data structures
• how does it influence governor targets

[coot]

What information to pass about peers?
I think we are in agreement here. I just want to make this explicit, that we'll exchange RelayAccessPoints.

Should peers that we gossip about come with a TTL?
This would allow us to tidy up very old entries in the known peers. If TTL expires we would forget about that peer, and request new set of peers; Alternative we could re-check if the peer is still accessible and renew its TTL.

[bolt12]

On the receiving end of the protocol, ultimately we will receive the peers to add to our Known Set (or perhaps our Shared set). Some validation should be performed, i.e. we should only accept those peers whose validation is successful. Validation process should check:

• If a peer is connectable (it might not be for a variety of reasons, but we should only keep peers that have higher connection potential)
• If a peer wants to be asked (this situation is weird, we might want to accept it still, because at the time that was the way it was configured)
• if number of peers is within the upper-limit we asked about (this should only apply if decided the requesting end sends an upper limit amount of peers to get)
• we should also probably check if any of the peers are already known so we can discard those

Should shared peers come with a TTL?

Interesting, this can be a good idea!

[bolt12]

Should peers that we gossip about come with a TTL?
This would allow us to tidy up very old entries in the known peers. If TTL expires we would forget about that peer, and request new set of peers; Alternative we could re-check if the peer is still accessible and renew its TTL.

Good idea! This could be our churn mechanism.