feat: delegated routing filtering for transports

chore: update ipip number

src/ipips/ipip-0484.md

@@ -0,0 +1,105 @@
+---
+title: 'IPIP-0484: Delegated Routing V1 Support for Querying Specific Network Transport and Transfer Protocols'
+date: 2024-09-03
+ipip: proposal
+editors:
+ - name: Daniel Norman
+ github: 2color
+ affiliation:
+ name: Shipyard
+ url: https://www.ipshipyard.com/
+relatedIssues:
+ - https://github.com/ipfs-shipyard/someguy/issues/13
+order: 483
+tags: ['ipips']
+---
+
+## Summary
+
+Add opt-in support for filtering specific network transports and/or transfer protocols to the Delegated Routing v1 HTTP endpoint via HTTP GET parameters.
+
+## Motivation
+
+IPFS aims to allow ubiquitous data exchange across different runtimes and platforms. One of the most challenging aspects of this goal is the diversity of network conditions and capabilities across different environments. Web browsers have a very limited network stack, and most web browsers do not support the full range of network transport protocols that are commonly used in other IPFS implementations.
+
+The Delegated Routing v1 API empowers resource constrained clients like web browsers by significantly reducing the number of network connections necessary to fetch content addressed data directly from provider peers.
+
+However, there are many cases where most of the results from the Delegated Routing v1 API are not actionable by clients, because the client does not support either the **network transport protocol** or the **transfer protocol** of the provider.
+
+For instance, web browsers are limited to a specific set of network transport protocols, namely HTTPS, Secure WebSockets, WebTransport (emerging), and WebRTC. Consequently, providing information about providers that exclusively support TCP and/or UDP is not beneficial for browser-based clients, as they are unable to utilize such connections.
+
+Moreover, [Helia](https://github.com/ipfs/helia/), the most actively maintained browser IPFS implementation, supports block retrieval by CID with Bitswap and Trustless Gateways, but does not support GraphSync.
+
+This means that returning providers that only support GraphSync from the Delegated Routing API is not useful for browser clients, and results in unnecessary network traffic for browser clients.
+
+## Note on terminology
+
+The term **"transport"** is overloaded in the IPFS ecosystem.
+
+In the context of this IPIP, we refer to the network layer transport protocol, e.g. TCP, QUIC, WebTransport, as **"network transport protocol"** to avoid ambiguity.
+
+**"Transfer protocol"** refers to data exchange protocols, i.e. content-addressed block retrieval format, e.g. Bitswap, GraphSync, HTTP.
+
+## Detailed design
+
+### Network Transport Protocol Filtering
+
+The proposed change is to add a `?network-transports` parameter to the `GET /routing/v1/providers/{cid}` endpoint of :cite[http-routing-v1]:
+
+- Add a `?network-transports=<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](peer-schema).
+- The value of the `network-transports` 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. `?network-transports=webtransport`.
+- Multiaddrs are filtered by checking if the protocol name appears in any of the multiaddrs.
+- 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. `?network-transports=!webtransport`.
+- The filtering is case-insensitive.
+- If the parameter is not 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 `?transfer-protocols` parameter to the `GET /routing/v1/providers/{cid}` endpoint of :cite[http-routing-v1]:
+
+- Add a `?transfer-protocols=<comma-separated-list>` optional parameter to `GET /routing/v1/providers/{CID}` that indicates which transfer protocols to return by filtering the `Protocol` field of the [Peer schema](peer-schema).
+- The value of the `transfer-protocols` parameter is a comma-separated list of known transfer protocol names:
+ - `transport-bitswap`
+ - `transport-graphsync-filecoinv1`
+ - `transport-ipfs-gateway-http`
+- Providers are filtered by checking if the transfer protocol name appears at least once in the `Protocols` array.
+- If the provider doesn't match any of the passed transfer protocols, the provider is omitted from the response.
+- Negative filtering is done by prefixing the protocol name with `!`, e.g. `?transport=!transport-graphsync-filecoinv1`.
+- The filtering is case-insensitive.
+- If the parameter is not passed, the default behavior is to not filter by transfer protocol.
+- Providers returned from the DHT, currently do not contain a `Protocol` field. In such cases, Bitswap can be implied.
+
+:::note
+For legacy reasons, the transfer protocols are referred to and prefixed with `transport` in their names, 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 `network-transports` parameter.
+:::
+
+## Design rationale
+
+- 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, even though Bitswap can be implied in all cases.
+
+### User benefit
+
+By filtering out providers that do not support the desired network transport protocol and/or transfer protocol, the client can reduce the traffic necessary in order to fetch the data.
+
+Moreover, it makes it much easier to determine whether there are any browser-usable providers for a given CID, which is a common use case for clients.
+
+### Compatibility
+
+This should not effect existing clients or servers.
+
+The default behavior when `?network-transports` and `?transfer-protocols` is not passed is left unspecified, this IPIP is limited to opt-in behavior.
+
+### Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+[peer-schema]: https://specs.ipfs.tech/routing/http-routing-v1/#peer-schema