Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove peer-id? #535

Closed
achingbrain opened this issue Jan 20, 2020 · 1 comment
Closed

Remove peer-id? #535

achingbrain opened this issue Jan 20, 2020 · 1 comment

Comments

@achingbrain
Copy link
Member

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

@achingbrain
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant