IPIP-0388: Routing HTTP API Support for Querying Multiple Routers

[aschmahmann]

Adds support for querying for multiple routers via query parameter. cc @lidel @masih @guseggert

Marked as draft since it's point to the branch renaming delegated routing to routing v1

[BigLep]

2023-04-19 conversation:

• Adin will check to see what is needed to get this out of draft
• @lidel will surface to #bedrock / Rhea to ensure there is alignment on moving cid.contact to using this spec

[willscott]

should we include / how should we name 'server's connected bitswap peers'?

[lidel]

ipfs-bitswap-peers ?
I think it is ok to define some canonical names for popular things here, but the spec should be clear that it is at liberty of implementer to use other, opaque strings (for custom / future routing systems)

[lidel]

I've removed this list from the IPIP and added sentence that these are opaque strings controlled by implementation/instance.

[lidel]

+1, we need this, as noted in cc'd threads

• Expose /routing/v1 HTTP APIs for proxying DHT+IPNI someguy#12
  • Support a DHT-only proxy mode exposed over HTTP someguy#13
  • Remove dependency on Kubo RPC and node[0-2].delegate.ipfs.io bifrost-gateway#151

GET /routing/v1/providers?routers=all (less ambiguous than *) sounds sensible, there is some UX gap around learning what routers are available, but grabby catch-all that enables all optional backend routers is already usefull.

In a spare moment this PR needs to be rebased to use specs.ipfs.tech, but for now some thoughts inline.

[lidel]

Some quick thoughts:

• Learning about available routers via OPTIONS header is ok, but just for the record, it introduces some UX challenges:
  • can't paste link in address bar: need to pass custom method to curl -X OPTIONS, JS may need explicit entry in Access-Control-Expose-Headers for the value to be readable via JS.
• Given the design decisions made when we abandoned Reframe and prioritized user-friendliness and human-readablinity of API, it may be a better UX and less headache to support listing available routers via GET and return them as JSON.

Alternative idea just to see if it resonates better:

Request: GET /routing/v1/routers (dedicated endpoint)

Response: JSON with list of items following router schema

{
  "Schema": "router",
  "Name": "ipfs-public-dht",
  "Default": false, // is it used when `?routers` is not passed
  "RoutingType": ["providers", "ipns", "peers"], // where can it be used
  "Details": { .. } // optional opaque JSON with router-type-specific values
}

[lidel]

Rebased this IPIP on top of latest spec, and replaced OPTIONS with GET /routing/v1/routers and a router schema above.

[lidel]

Rebased on top of latest /routing/v1 spec and applied changes from comments.
Main one is dedicated router schema used for returning enumeration results for GET /routing/v1/routers (and removal of HTTP OPTIONS).

[lidel]

I've removed this list from the IPIP and added sentence that these are opaque strings controlled by implementation/instance.

[lidel]

Rebased this IPIP on top of latest spec, and replaced OPTIONS with GET /routing/v1/routers and a router schema above.

[TorfinnOlsen]

added issue: ipni/storetheindex#2215 to backlog of IPNI repo cc @masih , @gammazero