Design desired comprehensive routing config

[BigLep]

Done Criteria

We have a design document that covers:

1. Problems we need to solve and usescases we need to meet within Kubo around supporting multiple routers.
2. Proposed solution(s) with justification and pros/cons. This proposal should show what the Kubo config will look like for a user attempting to satisfy their usecases.

Why Important

In #9150, we have an immediate usecase of getting Kubo to query Reframe.FindProviders whenever it would normally query the DHT so that the ipfs.io Gateway can use storetheindex as an extra router to the DHT. A config migration will be needed to go from our previous world without reframe to one with reframe. Repo migrations aren't free to implement and we'd like to make sure that the work we do for #9150 is moving us in a direction that doesn't require immediate additional config migrations as we support additional routers and options.

Notes

1. The design document should be in a place that is public and easy/quick to leave contextual comments. This likely means Notion or Hackmd. If no preference, Notion is recommended so it fits within the Kubo document browse tree.
2. Routing: conform DHT to common Router interface #9079 as defined in Routing: conform DHT to common Router interface #9079 (comment) doesn't account for areas like:

• Other routers (peer routing, local DHT)
• How multiple routers will be combined for each routing "method" in terms of execution ordering and result merging.

2. https://github.com/libp2p/go-libp2p-routing-helpers contains some helpers for combining routers
3. Not authoritative but Routing: conform DHT to common Router interface #9079 (comment) is one proposal sketch for what the config can look like.
4. There may be other patterns in the codebase we can draw on (like datastore) that allow for nesting/wrapping.

[ajnavarro]

Design document work in progress: https://hackmd.io/@ajnavarro/HJr059wC9

[ajnavarro]

@BigLep document is ready for review!

[BigLep]

@ajnavarro : Thanks a lot Antonio for putting this together. There’s a decent amount of subtlety here. For this week we need to settle on the design ideally and estimate the work. I would be great to get another set of eyes like @guseggert’s since I see @lidel already reviwed. I’m particularly interested to see if there’s a way to simplify.

Note to self: comments on code snippets or blocks in hackmd get put to the bottom. As a result, I have commented in the whitespace around code blocks so the comments can be seen inline.

[ajnavarro]

I addressed all the comments. I will need some help for:

• How to make bitswap WANT broadcasting fit here (I'll need some advice)
• How far do we want to go with DHT configuration params. I'm using a flag to configure public or private DHTs because it is what it was defined in almost all previous documents.
• I didn't understand the problem @lidel mentioned: ("should hardcode the implicit default routers in user configuration") could you develop a little more where the problem is?

Thanks!

[ajnavarro]

Changed the JSON structure to make it more versatile. Also, after talking with @guseggert and @lidel, we are NOT going to need a migration step. Everything is described in the design document:

https://hackmd.io/@ajnavarro/HJr059wC9

@guseggert FYI, things I changed from your proposal:

• Moved global timeout to helper routers. If we have a timeout per router, It makes more sense to me that the helper router (the parallel or sequential one) should own the global Timeout.
• Removed MaxResults option.

[guseggert]

How far do we want to go with DHT configuration params.

As long as we have a clear place to add them later, we don't have to figure all of this out right now.

[BigLep]

@ajnavarro : I've lost access to https://hackmd.io/@ajnavarro/HJr059wC9 . Can you please reshare?

[BigLep]

2022-08-19 conversation:

1. Deferring "How to make bitswap WANT broadcasting" into the current design.
2. Other items in Design desired comprehensive routing config #9188 (comment) have been covered.

At this point we think "we're done", but we should tie it off.

[ajnavarro]

• Routers (3)
• FX estimation (5)
• Sharness smoke test (1-2)
• Testing on gateways (1-2)
• Documentation (1)
• Metrics ()
  • Edelweiss (1) (Define metrics we want, RPC metrics already there)

[ajnavarro]

@BigLep Could you clarify how this is related to boost? Thanks!

[BigLep]

@BigLep Could you clarify how this is related to boost? Thanks!

I'm confused. I don't think it is related to Bitswap/Boost integration and I don't have that mentioned anywhere.

Also, thanks for the estimates. I'll move those to the tracking issue for getting this into production: #9150

[BigLep]

@ajnavarro : I think we can mark this done once:

1. Any other open review comments have been responded to or closed
2. We make clear that the design is intentionally deferring "how to make bitswap WANT broadcasting" from the current design and why we're deferring.

[ajnavarro]

@BigLep I don't know why but Boost appeared in our conversation and I wrote the question down so I didn't forget.

• All comments have been responded.
• Adding into the document that bitswap WANT broadcasting is deferred to future iterations.

https://hackmd.io/@ajnavarro/HJr059wC9