You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
I think I have the wrong end of the stick here. The issue is not libp2p-crypto or bundle size, the issue is libp2p needs to accept CID instances as well as PeerID in its various methods.
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 bylibp2p-crypto
, the reason for which is thatpeer-id
depends on it.Current thinking is that a peer needs to be identified, a
CID
instance can be used with thelibp2p-key
codec as peer IDs are valid CIDs. It's complicated a little in that the JavaScriptpeer-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 onpeer-info
objects instead. Any references to peers would be received (e.g. fromlibp2p.pubsub.subscribers
,libp2p.swarm.peers
, etc) and passed around (e.g. tolibp2p.swarm.connect
orlibp2p.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 fromlibp2p.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 bundlinglibp2p-crypto
which would make it vastly smaller.Perhaps related to #453
The text was updated successfully, but these errors were encountered: