IPIP-484: Opt-in Filtering on Routing V1 HTTP API

[2color]

No description provided.

[masih]

Overall I for one welcome this. Thank you for putting this one together @2color 🙏

In therms of filter extensibility, my vote would be to start with the simplest most demanded one and expand later. In that pile, I can think of a more compact filtering using multicodec codes, bitfields, etc. all of which can be postponed for later.

[2color]

In that pile, I can think of a more compact filtering using multicodec codes, bitfields, etc. all of which can be postponed for later.

Thanks, good to have these optimisation suggestions on the record here.

My take is that there are diminishing returns for these:

• multicodec codecs would be smaller, at the cost of reducing human debug-ability
• bitfields would require assigning explicit bits for each protocol. This breaks the ability to treat filter values as opaque (to allows future evolution without regressions), because it requires assigning new bits as protocols are added.

[masih]

there are diminishing returns for these

The context for a more compact filtering suggestion on my part (which we should definitely ignore for now because of the "O"-word) is that I envision a world where these APIs would mostly be called by machines - not humans.

[2color]

Open question: should we also add this to the GET /routing/v1/peers/PeerID endpoint?

[SgtPooki]

I'm definitely in favor of this one, and it looks good as a starting point.

[gammazero]

see question

[2color]

@lidel Is there anything left to address before merging?

[lidel]

@2color I think we are happy with this spec and unlikely to change any further (boxo implementation got merged: ipfs/boxo#671).

The next steps here:

• Update this PR to add "Request Query Parameters" sections to /providers and /peers endpoint docs at https://specs.ipfs.tech/routing/http-routing-v1/ (src/routing/http-routing-v1.md), and document the newly added parameters there.
  • Fine to copy-paste content, just follow section/header naming convention established in other HTTP specs so we have meaningful permalinks, example: https://specs.ipfs.tech/http-gateways/path-gateway/#request-query-parameters
  • Fine to keep content duplicated in IPIP, IPIP acts as a snapshot in time, while the spec document is a living document
• Ship both client and server, to ensure spec truly works end-to-end and we've identified all the gaps
  • release and deploy server (someguy at https://delegated-ipfs.dev/)
  • release helia; it should be asking only for actionable peers when running in browser context.
• Merge this PR (The specs / IPIP always land last, allowing community to engage over long window of time)

[2color]

release helia query for action

What do you by that?

[lidel]

Ah, it cut-off, I meant helia should be asking only for actionable peers (unknown, or known to work in browser) when running in browser context.

[lidel]

Thank you all for fleshing this out @2color.
No concerns were raised since September, applied final ratification edits, ok to be merged.
We can refine this in follow-up IPIP if necessary.

For anyone reading this in the future, initial reference implementation(s) shipped in:

• https://github.com/ipfs/boxo/releases/tag/v0.24.1 (client/server)
• https://github.com/ipfs/rainbow/releases/tag/v1.8.1 (client powering public gateways)
• https://github.com/ipfs/someguy/releases/tag/v0.5.0 (client/server from boxo, powering public goods delegated routing endpoint)
• https://github.com/ipfs/helia-delegated-routing-v1-http-api/releases/tag/%40helia%2Fdelegated-routing-v1-http-api-client-4.1.0 (client used by verified fetch / service worker gateway prototype)
• and this will ship in kubo 0.32.0-rc1 this week (client)

Feel free to refer to this IPIP using permalinks

• https://specs.ipfs.tech/ipips/ipip-0484/
• https://specs.ipfs.tech/routing/http-routing-v1/#request-query-parameters