Implement subkey

[dariusc93]

In the current implementation, warp-mp-ipfs warp-ipfs utilizes the key generated for the identity as apart of the ipfs/libp2p node, however in a situation where 2 instances share the same key attempts to communicate with the same peer (eg a friend) would likely cause unexpected behaviour such as one peer only receiving data while the other is unable to receive data, etc. Furthermore, if the two nodes will fail to connect to each other while maintaining the same key. This behaviour is expected due to libp2p design.

I propose a subkey implementation. This key will be used as apart of the local node, which would be separate from the identity. This key will be used no more than just for handling connectivity with the node to prevent this conflict if two or more instance use the same identity.

Thoughts:

Key Usage

• Each subkey can be unique or derived from the main private key.
  • Unique keys can be persistent along side the primary key, or unique on every start of the instance
• The subkey should not be used for anything other than passing off into ipfs.
  • In warp-mp-ipfs, it can be used as apart of encrypting the payload, but not recommended as the primary key should be used for signing and encrypting.
  • In warp-rg-ipfs, the subkey can be ignored as the primary key will handle the signing and encrypting.

Discovery Options

Since the subkey will be used as apart of the network itself, we will not be able to perform any direct communication to the peer. through their public key (eg querying the DHT for the peer). In such case, we have additional options

Provider

1. Each peer will provide over DHT that points to their public key.
2. When a peer is performing a lookup, instead of querying the peer id, we would attempt to perform a query to determine who is providing the public key instead.
3. When the [list of] peer(s) are found and are connected, we will send an encrypted request to the peer for their identity, in which case would be responded back with a signed copy of their identity that can be validated by their public key.

IPNS[1]

1. Each peer will publish their identity over DHT via ipns
2. Perform a lookup of the record by the public key and grab the latest record, along with the cid apart of that record.
3. Attempt to perform a lookup of who is providing the cid
4. Send a request to the connected peers of the provided cid, repeating Provider#3.

[1]. IPNS is not implemented at this time, so this discovery option is only planning

Notes

1. This should not be a breaking change to the profile itself, but rather a possible breaking change to the discovery methods
2. The subkey can be optional, making it so that the primary key is used as apart of the node instead of the subkey. Downside would be what was mentioned above, but would be helpful in situations where the options above arent sufficient enough (eg connecting directly to a peer via set of common relays)
3. This may be updated with more options and methods

[dariusc93]

Note:

• Due to the support of external behaviours, this can be easy to implement after a small refactor in the discovery process.

[dariusc93]

Blocked on #288