feat: add unknown to filter addrs

src/ipips/ipip-0484.md

@@ -48,17 +48,14 @@ The proposed change is to add a `?filter-addrs` parameter to the `GET /routing/v
 
 - Add a `?filter-addrs=<comma-separated-list>` optional parameter to `GET /routing/v1/providers/{CID}` that indicates which network transports to return by filtering the multiaddrs in the `Addrs` field of the [Peer schema].
 - The value of the `filter-addrs` parameter is a comma-separated list of network transport protocol _name strings_ as defined in the [multiaddr protocol registry](https://github.com/multiformats/multiaddr/blob/master/protocols.csv), e.g. `?filter-addrs=webtransport`.
+- `unknown` can be be passed to include providers whose multiaddrs are unknown, e.g. `?filter-addrs=unknown`. This allows filtering providers whose multiaddrs are unknown at the time of filtering.
 - Multiaddrs are filtered by checking if the protocol name appears in any of the multiaddrs (logical OR).
 - Only multiaddrs that pass the filter are included in the response.
 - If there are no multiaddrs that match the passed transports, the provider is omitted from the response.
 - Negative filtering is done by prefixing the protocol name with `!`, e.g. `?filter-addrs=!quic-v1,!tcp`.
 - Filtering is case-insensitive.
 - If no parameter is passed, the default behavior is to not apply filtering by network transports.
 
-:::note
-Filtering out providers without any matching transport, will cause providers without any multiaddrs to be filtered out, even if they _might_ support the requested transports. This is due to the fact that provider records are independent of peer records, and it's pretty common to have provider records without up-to-date multiaddrs for that peer.
-:::
-
 ### Transfer Protocol Filtering
 
 The proposed change is to add a `?filter-protocols` parameter to the `GET /routing/v1/providers/{cid}` endpoint of :cite[http-routing-v1]:
@@ -82,7 +79,8 @@ Even though existing transfer protocol names start with `transport`, e.g. `trans
 - Using these query parameters improves cache efficiency, as the response will be smaller and more specific to the client's needs.
 - Backward compatibility by not changing the default behavior of the API.
 - Use of protocol name rather than code makes it easier for human debugging.
-- DHT providers currently do not contain any transfer protocol information. `unknown` can be used to filter such providers.
+- DHT providers currently do not contain any transfer protocol information. `unknown` can be passed to `filter-protocols` to include such providers.
+- Since provider records are independent of peer records, and it's pretty common to have provider records without up-to-date multiaddrs for that peer, `unknown` can be passed to `filter-addrs` to include such providers.
 
 ### User benefit