Description
I realise this is a little late in the day for the async await refactor, but here goes.
We really, really want to reduce the bundle size for the ipfs-http-client, a great big chunk of that is taken up by libp2p-crypto, the reason for which is that peer-id depends on it.
Current thinking is that a peer needs to be identified, a CID instance can be used with the libp2p-key codec as peer IDs are valid CIDs. It's complicated a little in that the JavaScript peer-id module has a class that also contains private/public keys and methods to serialize/deserialize from various formats. This is a bit weird in that classes should encapsulate data and operations on that data, serialization formats should be a separate concern.
My gut feeling is that we can remove the peer-id module entirely and store keys as opaque buffers on peer-info objects instead. Any references to peers would be received (e.g. from libp2p.pubsub.subscribers, libp2p.swarm.peers, etc) and passed around (e.g. to libp2p.swarm.connect or libp2p.dialProtocol as a (relatively) lightweight CID.
Extraction of the keys from peer IDs with the identity codec can take place during object creation inside libp2p.
Internally peer-info objects corresponding to that peer can then be looked up from libp2p.peerStore and any serialization/deserialization or crypto related operations can then be done inside libp2p.
If a users' application needs to do ser/deser/crypto, these functions could be in a separate module (also used by libp2p) that they can depend on, pulling in libp2p crypto and the increased bundle size that would entail.
Using CIDs as input/output formats and encapsulating everything else inside libp2p would allow the ipfs-http-client to not require bundling libp2p-crypto which would make it vastly smaller.
Perhaps related to #453