-
Notifications
You must be signed in to change notification settings - Fork 1.2k
[Types] SwarmAPI.connect requires a Multiaddr but libp2p.dial allows PeerId|Multiaddr|string #3638
Comments
humm, good question. In libp2p we have the addressBook as part of the API and users can add addresses to the AddressBook and then dial using PeerId. Discovery mechanisms also add to the addressBook out of the box. In the future, we want to try to find addresses of a peer if we don't have any libp2p/js-libp2p#901 . However, now if we do not have any addresses the dial will just fail (error no addresses for given peer). In IPFS, I think we can allow dials to PeerId, but it should probably mentioned in the docs that dial a peerId is only supported if libp2p's addressBook already has addresses for it? |
Peer IDs are a bit of a problem in the public API as the We've been using CIDs and strings for Peer IDs in other places as a more lightweight solution. CIDs have always felt a bit weird (to me) as a Peer ID type, and strings are too opaque (could be a multiaddr, could be a peer id) - we could introduce a marker interface style class that just lets us drop strings as an argument and only accept multiaddrs or Peer IDs while not needing to use the full |
sounds good. We want to move in the future with a change to use strings everywhere in libp2p libp2p/js-libp2p#680 , but the could be a multiaddr, could be a peer id is tricky in the dial side of things. When we do this change in libp2p, we can consider moving this interface style class to the libp2p side of things |
Accept peer ids as strings or multiaddrs as Multiaddrs. Fixes #3638
Accept peer ids as strings or multiaddrs as Multiaddrs. Fixes #3638
Accept peer ids as strings or multiaddrs as Multiaddrs. Fixes #3638
Ref: ceramicnetwork/js-ceramic#1194
Similar to #3637
js-ipfs/packages/ipfs-core-types/src/swarm/index.d.ts
Line 16 in 63b11e5
But this passes straight through to
libp2p.dial()
which is more permissive:https://github.com/libp2p/js-libp2p/blob/5372f7af2f8f1653384504af15efea8ba776534b/src/index.js#L454-L465
Should we be similarly lax here?
The text was updated successfully, but these errors were encountered: