Store the NoiseKey
in peers.rs
instead of collection.rs
#377
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Step towards #44
Right now, the
NoiseKey
is stored incollection.rs
within anArc
. ThisArc
is shared with all the background tasks.This PR removes the
NoiseKey
fromcollection.rs
, and you must now pass a&NoiseKey
every time you add a connection to the collection. This allows using multiple different noise keys if desired.The
NoiseKey
is now stored inpeers.rs
. Eventually, the plan is to move it toservice.rs
or even outside.Unfortunately,
peers.rs
might be a bit of a blocker, because the same remote peer might open multiple substreams towards the multiple local identities without it being a protocol violation.Even if
peers.rs
turns out to be a blocker, the change in this PR is good even in isolation.As part of this change, we now provide the
NoiseKey
immediately when initializing a single stream handshake, so that we can pass a&NoiseKey
by reference at initialization rather than having to store it by value and load it later.