shuttle: Change internal protocol

[dariusc93]

Currently, shuttle utilizes a low level request-response protocol with the idea of being able to benefit from utilizing the transport for handling security without any redundant security methods that may be done via pubsub for specific request to a specific peer while waiting on a response from shuttle for specific request (eg registering the identity, updating, requesting mailbox, etc)., however because of the way things are designed currently, we have to send commands to the behaviour to send the request to the peer, while awaiting on a response to be sent via oneshot from the behaviour. While generally this would be fine, this, in some way, introduces some complexity between having to split the protocol between a "client" and "server", having to introduce additional channels to warp-ipfs, etc. After evaluating things, this protocol may benefit from being change from the low level behaviour to something more higher.

Thoughts:

• Switch to using pubsub, with each shuttle node having its own specific topic in which we would subscribe and send messages.
  • Subscribing to the specific topic isnt required but if for whatever reason we are not connected to a shuttle node, we would be able to fanout messages if a peer we are connected to is connected to the shuttle node(s), increasing efficiency.
    • This may require providing a "callback" on how the shuttle node can respond if the node is not connected to us and never been connected to us before. This field may include the peer specific topic (either one assigned based on the public key or a unique topic specific for that request), a reachable address of the peer for the shuttle node to connect too.
  • This would require encrypting the data being publish so only the shuttle node would be able to decrypt it due to pubsub nature and how a connected peer could easily subscribe to that topic and see published messages.
    • The data would be encrypted via a shared key generated via ecdh.
• Enable streams feature and utilize the connection streams to be able to send messages directly to the node.
  • The feature is still considered experimental, but is functional and usable
  • Would allow us to continue to utilize the connection we have established
  • Would be more low level vs current protocol methods, however would give more flexibility while removing the complexity of communication to the behaviour.

Notes:

• As noted above, the purpose of using the behaviour itself was to utilize the transport so we do not have to double encrypt (messages being encrypted via transport protocol and again when utilizing pubsub when publishing a message to a specific topic) when sending to a specific peer, however we would have to communicate to the behaviour via channels so the behaviour can send the message accordingly, which can make things complex long term. Furthermore, it may not give as much flexibility and introduces additional types, etc. Utilizing the streams directly, while may require a bit more work as we read and write from stream, parse the data, etc., would give the same benefits as mentioned previously.
• Messages via pubsub are generally encrypted via transport, but is still available to be seen as clear as plaintext for connected peers subscribe to the topic unless the data published is also encrypted. This will make sure only the intended recipient of the message can decrypt and read the message, while taking advantage of pubsub internals to propagate messages out over a mesh network, which would increase the chances of subscribed peers being able to propagate it.
• The data internally would not require changing as this is more focus on the networking side, with the ability to even add backward compatibility to those protocols if needed, so things can still carry over if needed.
• This is still TBD as things are continued to be evaluated.