Brainstorming TrRemoteConnection rearrangement

TrRemoteConnection

• This should contain everything required to connect to a remote node (right now it doesn't contain the public key, or whether the node will accept unilateral connections)

PROBLEM: If A connects to B unilaterally, then B doesn't have the ability to connect back to A because it doesn't have A's public key

So, we've been using TrRemoteConnection to identify nodes, even though we might not be able to connect to them.

So, we need to separate something that identifies a remote node, from something that allows us to connect to a remote node. eg. an IP address and port allow us to identify a remote node, but do not allow us to connect to it.

Also, a node's identity may be associated with multiple mechanisms to connect to it.

Worse, we could have several different identities for the same remote node.

Perhaps we need a notion of node identity that isn't tied to a specific transport, meaning that IP/port isn't a good identification mechanism.

So what entities do we need, and what are their properties?

• TrPeerIdentity

  • This really only needs to be able to tell us when two peers are the same peer (even though we may contact them separately)
  • But, what about abuse? Do we take a peer's word for it about its own identity? What are the risks?
  • We could have a mechanism that verifies, for a given type of TrRemoteAddress, we get the same TrPeerIdentity

• TrRemoteAddress

  • This allows us to connect to a remote peer, and also tells us whether the remote peer must be attempting to connect to us in order for the connection to be successful (ie. does it accept unilateral connections)