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

[2color]

[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?

[2color]

@lidel Is there anything left to address before merging?

[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.