feat(iroh): Avoid allocations in AddrFilter

[matheus23]

Description

• Makes AddrFilter essentially a wrapper around &Vec -> Cow<Vec> instead of &BTreeSet -> Vec.
• Reworks EndpointInfo and EndpointData APIs. Some docs were outdated (e.g. claiming with_relay_url(None) would remove relays), etc. Generally also removed Deref and DerefMut implementations from EndpointInfo -> EndpointData.

Breaking Changes

iroh::address_lookup::EndpointInfo:

• EndpointInfo::with_relay_url now takes RelayUrl instead of Option<RelayUrl>
• EndpointInfo::with_ip_addrs now takes Vec<SocketAddr> instead of BTreeSet<SocketAddr>.
• Removed Deref and DerefMut with Target = EndpointData from EndpointInfo.
• Added EndpointData::{addrs, relay_urls, user_data, ip_addrs}.

iroh::address_lookup::EndpointData:

• EndpointData::new now takes a Vec<TransportAddr> instead of impl IntoIterator<Item = TransportAddr> and keeps the ordering of addresses. Use EndpointAddr::from_iter instead (although less performant).
• EndpointData::with_user_data now takes UserData instead of Option<UserData>.
• EndpointData::filtered_addrs now returns Cow<Vec<TransportAddr>> instead of Vec<TransportAddr>.
• Added EndpointData::{add_relay_url, add_ip_addrs, apply_filter}.
• Added impl From<BTreeSet<{TransportAddr, SocketAddr}>> for EndpointData.
• Added impl FromIterator<TransportAddr> for EndpointData.

iroh::address_lookup::AddrFilterFn:

• Changed from being BTreeSet-based to Vec-based.
• Return type changed to Cow<Vec<TransportAddr>> fromVec<TransportAddr>.

Notes

There's some work required to keep the EndpointData transport addresses deduplicated, and deduplicating a Vec is unfortunately somewhat expensive and requires allocations, but I think it's better to have this than not to.
I already saw some code in some publishing services that just keep adding new information to a single EndpointData and keep publishing. Without deduplication, this would go wrong. Maybe that should change nonetheless, but that'd be a PR for another day.

Change checklist

• Self-review.
• Documentation updates following the style guide, if relevant.
• Tests if relevant.

[github-actions]

Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/4018/docs/iroh/

Last updated: 2026-03-19T10:53:44Z

[github-actions]

Netsim report & logs for this PR have been generated and is available at: LOGS
This report will remain available for 3 days.

Last updated for commit: 010db72

[dignifiedquire]

yeah, having just a vec might make more sense

[rklaehn]

I had something similar, but one of the goals of the filter functionality was to be able to not just filter but also reorder addrs. Hence the vec.

See the PR from ramfox: #3960

/// A filter and/or reordering function applied to transport addresses before publishing.

and/or reordering

Now, do we need reordering? I am not sure. But just wanted to mention that this design is making reordering impossible.

I would argue that ordering can be important in some cases. E.g. you can order from "good" to "bad" or "new" to "old", and dialing the addrs in a reasonable order will have much more benefit than saving an allocation.

[rklaehn]

I am fine if we decide that reordering is not needed. But we should at least briefly discuss why the reordering of the original design is no longer needed.

[matheus23]

Yeah - thanks for raising this @rklaehn

I briefly discussed this with @Frando. Address reordering became impossible with #3987, but bringing it back makes sense.

My response in discord was: Let's switch everything to Vec, including the addresses in EndpointData. Does that make sense?

[rklaehn]

Yeah - thanks for raising this @rklaehn

I briefly discussed this with @Frando. Address reordering became impossible with #3987, but bringing it back makes sense.

My response in discord was: Let's switch everything to Vec, including the addresses in EndpointData. Does that make sense?

Yes, if the order is interesting we should also allow it there. However, I would prefer if we don't allow duplicates, since I really don't see a good reason to have those.

addrs are not pub in EndpointData, so I guess having this a vec but preventing dupes is viable.

[matheus23]

Yes, if the order is interesting we should also allow it there. However, I would prefer if we don't allow duplicates, since I really don't see a good reason to have those.

addrs are not pub in EndpointData, so I guess having this a vec but preventing dupes is viable.

The only problem is that this is somewhat ugly to enforce. You need to enforce everywhere you can now add ordered elements to EndpointData. But now that I looked into that struct and its methods, I realize there's a lot of weird APIs that need cleanup. I think I'll try to work on this.