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

Expose enough information to enable connecting to multiaddrs without a peerID #2449

Closed
aschmahmann opened this issue Aug 1, 2023 · 0 comments · Fixed by #2451
Closed

Expose enough information to enable connecting to multiaddrs without a peerID #2449

aschmahmann opened this issue Aug 1, 2023 · 0 comments · Fixed by #2451

Comments

@aschmahmann
Copy link
Collaborator

aschmahmann commented Aug 1, 2023

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.

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

Successfully merging a pull request may close this issue.

2 participants
@aschmahmann and others