From 4a1f33b4196dc457d3042e08611d92ee6591ee0a Mon Sep 17 00:00:00 2001 From: Daniel Norman <1992255+2color@users.noreply.github.com> Date: Fri, 27 Sep 2024 14:45:02 +0200 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Marcin Rataj --- src/ipips/ipip-0484.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/ipips/ipip-0484.md b/src/ipips/ipip-0484.md index eb9a7086..1d45d28b 100644 --- a/src/ipips/ipip-0484.md +++ b/src/ipips/ipip-0484.md @@ -1,5 +1,5 @@ --- -title: 'IPIP-0484: Delegated Routing V1 Support for Querying Specific Network Transport and Transfer Protocols' +title: 'IPIP-0484: Opt-in Provider and Peer Filtering in Routing V1 HTTP API' date: 2024-09-03 ipip: proposal editors: @@ -58,15 +58,15 @@ The proposed change is to add a `?filter-addrs` parameter to the `GET /routing/v - If there are no multiaddrs that match the passed transports, the provider is omitted from the response. - Filtering is case-insensitive. -### Transfer Protocol Filtering +### IPFS Protocol Filtering The proposed change is to add a `?filter-protocols` parameter to the `GET /routing/v1/providers/{cid}` and `GET /routing/v1/peers/{peer-id}` endpoints of :cite[http-routing-v1]: - Add a `?filter-protocols=` optional parameter to `GET /routing/v1/providers/{CID}` to filter providers based on the `Protocol` field of the [Peer schema]. - The `filter-protocols` parameter is a comma-separated list of transfer protocol names, e.g. `?filter-protocols=transport-bitswap`. - Transfer protocols names should be treated as opaque strings and have a max length of 63 characters. A non-exhaustive list of transfer protocols are defined per convention in the [multicodec registry](https://github.com/multiformats/multicodec/blob/3b7b52deb31481790bc4bae984d8675bda4e0c82/table.csv#L149-L151). -- Implementations MUST ignore unknown transfer protocol names. -- `unknown` can be be passed to include providers whose transfer protocol is unknown, e.g. `?filter-protocols=unknown`. This allows filtering providers returned from the DHT that do not contain explicit transfer protocol information. +- Implementations MUST preserve all transfer protocol names when returning a positive result that matches one or more of them. +- A special `unknown` name can be be passed to include providers whose transfer protocol list is empty (unknown), e.g. `?filter-protocols=unknown`. This allows for including providers returned from the DHT that do not contain explicit transfer protocol information. - Providers are filtered by checking if the transfer protocol name appears in the `Protocols` array (logical OR). - If the provider doesn't match any of the passed transfer protocols, the provider is omitted from the response. - If a provider passes the filter, it is returned unchanged, i.e. the full set of protocols is returned including protocols that not included in the filter. (note that this is different from `filter-addrs` where only the multiaddrs that pass the filter are returned) @@ -74,7 +74,7 @@ The proposed change is to add a `?filter-protocols` parameter to the `GET /routi - If no parameter is passed, the default behavior is to not filter by transfer protocol. :::note -Even though existing transfer protocol names start with `transport`, e.g. `transport-bitswap`, `transport-graphsync-filecoinv1`, and `transport-ipfs-gateway-http`. This is not to be confused with the network transport protocols, which are filtered using the `filter-addrs` parameter. +Even though some of existing IPFS transfer protocol names start with `transport`, e.g. `transport-bitswap`, `transport-graphsync-filecoinv1`, and `transport-ipfs-gateway-http`, they should not to be confused with the network transport protocols used in peer addresses, which are filtered using the `filter-addrs` parameter. ::: ## Design rationale