Having to send this stream is unfortunate but I see why we're doing it.

What if, instead of preparing/recording the entire message inside the loop, we just recorded our protocols/addresses? Then, we'd change the populateMessage signature to take the set of protocols/addresses that should be sent.

As is, we may end up sending the peer the wrong observed address (we'll send them the address observed on the initial connection).

@Stebalien I do understand the intuition behind not wanting to send streams to channels but can you explain with a bit more detail why we wouldn't to pass streams across channels.

I am making the change.

Streams on channels is fine. The issue is really:

• The identify loop doesn't actually care about the stream, we're handling the response outside of the loop. Really, we're just sending the stream so we can pull off the remote address so we can initialize an identify message that we're not even sending from the loop.
• The observed address will always be the addressed observed during the first identify request until we finally disconnect.

@Stebalien I see what you mean. Have made the change.