feat(utils): add multiaddr sort comparators - #3488
Merged
Merged
Conversation
Required for the multiaddr-only sort comparators being relocated from libp2p to @libp2p/utils.
Move the four multiaddr-only sort comparators from libp2p into @libp2p/utils, retyped to take Multiaddr directly. The Address-aware composition stays in libp2p (next commit).
Drops the inline implementations of the four multiaddr-only comparators. The Address-aware composition (defaultAddressSorter, certifiedAddressesFirst) stays here, feeding utils comparators through a small asMultiaddr adapter. Sort order is preserved.
One focused test per comparator validating direction and no-op-on-tie behavior, with bare Multiaddr inputs.
Convenience wrapper that chains the four multiaddr-only comparators in the standard priority order. Lets bare-Multiaddr callers sort without composing their own chain.
tabcat
commented
May 5, 2026
Comment on lines
+6
to
+10
| /** | ||
| * Sorts addresses by order of reliability, where they have presented the fewest | ||
| * problems: | ||
| * | ||
| * TCP -> WebSockets/Secure -> WebRTC -> WebRTCDirect -> WebTransport |
Member
Author
There was a problem hiding this comment.
wondering if this needs to be updated.
Collaborator
There was a problem hiding this comment.
think this is still the best order
tabcat
marked this pull request as ready for review
May 5, 2026 12:06
tabcat
commented
May 5, 2026
Comment on lines
+141
to
+145
| return multiaddrs.sort((a, b) => | ||
| loopbackAddressLast(a, b) || | ||
| publicAddressesFirst(a, b) || | ||
| circuitRelayAddressesLast(a, b) || | ||
| reliableTransportsFirst(a, b) |
Member
Author
There was a problem hiding this comment.
equivalent to .sort chain (although primary key order changes). could make this change to defaultAddressSorter.
dozyio
approved these changes
May 6, 2026
This was referenced May 7, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Move the four multiaddr-only sort comparators (
reliableTransportsFirst,loopbackAddressLast,publicAddressesFirst,circuitRelayAddressesLast) frompackages/libp2p/src/connection-manager/address-sorter.tsinto@libp2p/utils, retyped to takeMultiaddrdirectly. Also adds adefaultMultiaddrSorter(multiaddrs: Multiaddr[])convenience that chains the four in the standard priority order (loopback last, public first, relay last, reliable transports as innermost tiebreaker).The
Address-aware composition (certifiedAddressesFirst,defaultAddressSorter) stays in libp2p and now feeds the utils comparators through a smallasMultiaddradapter. Sort order is preserved verbatim — same five-key priority chain indefaultAddressSorter.dial-queue.tsimport path is unchanged. TheAddressSorterinterface in@libp2p/interfaceis unchanged.@libp2p/utilsgains a new dependency on@multiformats/multiaddr-matcher.This unblocks #3423, which puts the addresses we send in identify messages in priority order.
Notes & open questions
defaultAddressSorterto consumedefaultMultiaddrSorter.certifiedAddressesFirstneeds to slot at priority 4 inside the chain, which doesn't fit cleanly into a no-optionsdefaultMultiaddrSorter.Change checklist