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
Related to libp2p/specs#458 (and exemplified in ipfs-shipyard/vole#27). It is sometimes nice to be able to connect to a peer without knowing its peerID (e.g. Trust on First Use models, when your network logs aren't libp2p aware and you want to probe a node given only its IP, ...).
Aside from whether go-libp2p should expose the ability to connect to an address without its peerID and then ask for the peerID it seems reasonable that the application layer should be able to perform this task if it wanted to.
In ipfs-shipyard/vole#27 (vole is a tool mostly used for debugging) this functionality was implemented by manipulating the stringified errors returned from dialing a bogus peer. This is particularly brittle since if the error text changes this behavior will break (Note: other brittle error checks in that PR failed immediately after upgrading go-libp2p due to #2331 which is fine, that's why they were guarded with tests, but it'd be convenient to have an easier error to rely on).
Perhaps the easiest thing to do here to make this more palatable would be to have some structured error like ErrPeerIDMismatch (rather than a one off string error) that gets returned when there's a peerID mismatch during a dial attempt.
The text was updated successfully, but these errors were encountered:
Related to libp2p/specs#458 (and exemplified in ipfs-shipyard/vole#27). It is sometimes nice to be able to connect to a peer without knowing its peerID (e.g. Trust on First Use models, when your network logs aren't libp2p aware and you want to probe a node given only its IP, ...).
Aside from whether go-libp2p should expose the ability to connect to an address without its peerID and then ask for the peerID it seems reasonable that the application layer should be able to perform this task if it wanted to.
In ipfs-shipyard/vole#27 (vole is a tool mostly used for debugging) this functionality was implemented by manipulating the stringified errors returned from dialing a bogus peer. This is particularly brittle since if the error text changes this behavior will break (Note: other brittle error checks in that PR failed immediately after upgrading go-libp2p due to #2331 which is fine, that's why they were guarded with tests, but it'd be convenient to have an easier error to rely on).
Perhaps the easiest thing to do here to make this more palatable would be to have some structured error like
ErrPeerIDMismatch
(rather than a one off string error) that gets returned when there's a peerID mismatch during a dial attempt.The text was updated successfully, but these errors were encountered: