feat: switch config to orient routing around the routing system names

[aschmahmann]

@lidel putting up an alternative proposal for the config formatting to discuss

While we both have gripes about the state of the kubo config for routing, I feel like this setup is really quite coupled to what kubo looks like right now.

The overall idea of the change is to:

• Have close to the minimum data needed given existing types of usage
• Be more easily extensible for people to add new systems (e.g. someone can add "NewSys" to their list of systems and give it a delegated routing endpoint and implementations will just add unless they already have a specific "NewSys" implementation)

I'll drop more comments on the individual changes made for easier discussion

[aschmahmann]

The Bootstrap nodes are really only intended as Bootstrap nodes for the Amino DHT, I'm not sure we have much evidence around non-Amino DHT usage. I recall there was a CJDNS variant of the Amino DHT that's classified by kubo as a "LAN" DHT, but I don't know if it's in use anymore or if it's a distinction worth making.

We could've also left the Bootstrappers top level and called them DHTBootstrappers or AminoDHTBootstrappers, but I figured leaving space for per-system configuration seemed reasonable.

As for how someone might handle configuring say kubo with a CJDNS DHT using an AutoConfig endpoint:

• We could either add a "type" field so that implementations like kubo can know a new system is a libp2p-dht that has a set of bootstrappers
• Just leave let those users pretend to be the AminoDHT as largely happens today

[lidel]

Semantics, but we probably want to avoid "Amino" name in contexts of DHT other than Mainnet WAN one.

If Amino DHT is an instance of IPFS Kademlia DHT used by the IPFS Mainnet (ipfs/specs#497):

Amino DHT is a public instance of the IPFS Kademlia DHT spec [..] also referred to as the Public IPFS DHT.

..then every private swarm is "non-Amino DHT usage" (an instance of IPFS Kademlia DHT).

I would keep this field as Bootstrap because it is not just for DHT, this could also be for things like RelayV2.

[aschmahmann]

but we probably want to avoid "Amino" name in contexts of DHT other than Mainnet WAN one.

I agree, but am confused where you think we're disagreeing. The specific system here in the ipfs-mainnet config is for Amino though. Similarly, all of your suggested profile names had the word "mainnet...dht" in there which is just Amino, right?

We could certainly talk about a generic libp2p-dht type to let people use this to configure custom DHTs (e.g. Amino + a CJDNS variety), but your example didn't have that and it seems easy enough to describe at the config layer by just adding a type.

I would keep this field as Bootstrap because it is not just for DHT, this could also be for things like RelayV2.

Interesting.... maybe a "please connect to me, but no reason why is given" field is useful. People have certainly abused it in kubo for all sorts of things. My inclination is that when possible it's much better to know why you're making a connection. For example, when people have abused this for Bitswap (and hypothetically for Relays the story is similar) it tends to blow up in their faces because the connection will get closed at some point and then never reopen. This led to the separate "Peering" config in kubo which similarly is a pretty low level approach that's reliant on implementation details to the point that when we reduced Bitswap broadcast we had to leave a mechanism to explicitly broadcast to Peered peers.

[lidel]

I've been thinking about it, and if we have DelegatedConfig and NativeConfig per "system", then we can put bootstrappers in NativeConfig of AminoDHT.

PoC in:

• refactor: schema 4 with extensible systems and APIs #4

[aschmahmann]

I get the idea of disambiguating which functions we're planning to use on a given endpoint by just interpreting /v1/peers as peers vs the kubo config find-peers tag, although that ends up then introducing a separate DelegatedPublishers because of the HTTP PUT vs GET. Is this really better than get-ipns vs put-ipns though?

In this example, I've removed the tags entirely to discuss. The downside is that one of the following would happen:

1. We'd need some logic for cid.contact to tell people it doesn't support anything but "find providers"
2. We'd need some logic in implementations that IPNI as a system only supports "find providers"
3. We'd need some logic in implementations to figure out that cid.contact only supports /v1/providers and not the other endpoints
4. We'd waste resources sending useless requests to cid.contact

While I'd like 3 to be real, I agree that these are all not great outcomes and we'd probably be better off having some more data in the config.

How about:

Suggested change

	"https://cid.contact" : ["IPNI"],
	"https://delegated-ipfs.dev" : ["AminoDHT", "IPNI"]
	"https://cid.contact" : {
	"Systems" : ["IPNI"],
	"Methods" : ["find-providers"],
	},
	"https://delegated-ipfs.dev" : {
	"Systems" : ["AminoDHT", "IPNI"],
	"Methods" : ["find-peers", "find-providers", "get-ipns", "put-ipns"],
	}

We could disambiguate on end-point but it seems like we'd lose the System tags and still end up needing something special (e.g. also adding delegated publishers). This is a little more verbose, but feedback definitely welcome

[lidel]

IMO separating reads from writes, and then using original URLs with paths is better than inventing another complex JSON representation.

I tried the approach you suggest here, but it felt virtually same complexity as Routing.Type=custom in Kubo.

• Implementation:
  • Every client would have to implement an extra indirection(s) to map from method names and systems invented here to /routing/v1 endpoints and also to the routing interface.
  • There is no way to group systems in your proposal, so every implementation would have to hardcode own set of Systems that means "Mainnet". Because it will be hardcoded on each client, no way to add new System to be picked up immediatelly. This means fixing things like IPNI outage will mean spoofing IPNI, and not adding separate system. Makes System as a concept meaningless and effectively, over time, turns them to be used as "profiles" I proposed.
    • Thats why I feel it is a lesser evil to have profiles that group routing systems (e.g. for Mainnet, a default one + separate one for browsers), rather than listing specific routing system names.
• Specs: There is no spec for what "find-peers", "find-providers", "get-ipns", "put-ipns" are. There is a spec for delegated /routing/v1 and its endpoints, we can reuse its full URLs to collapse complexity. Let's not introduce another spec if we don't have to.
  • (1) is trivially represented as https://cid.contact/routing/v1/providers under DelegatedRouters. To do it your way, we need to invent what AminoDHT is and what find-providers is, and write a spec so every client implements it the same way.?
  • DelegatedPublishers is there only so we don't forget about representing writes somehow (even tho we only have them for IPNS right now, and it is not a high priority). I do think separating reads from writes is better – especially for writes, because it makes it very clear that only IPNS writes can be delegated over HTTP today.

[aschmahmann]

There is no way to group systems in your proposal, so every implementation would have to hardcode own set of Systems that means "Mainnet".

Clarified in the System thread above. Implementations don't have to hardcode, the list of routers they need from an autoconfig is defined here.

DelegatedPublishers

I don't have a strong opinion on if we swap the words and decide to have two lean into effectively HTTP GET vs PUT. If you don't like find-peers and prefer providers or /v1/providers that seems fine. You could have a grouping like

"https://delegated-ipfs.dev/routing/v1" : { 
    "Systems" : ["AminoDHT", "IPNI"],
    "Endpoints" : ["peers", "providers", "ipns"],
 }

You could reorganize them differently (e.g. a list of URLs), but I can see that if that's more complicated or not depends on resolving the Systems question

[lidel]

Thx, see a variant in

• refactor: schema 4 with extensible systems and APIs #4

[aschmahmann]

The concept of these long tags like "mainnet-for-nodes-with/out-dht" or "mainnet-for-ipns-publishers-with-http" seems both overly verbose and not extensible in ways that just don't have to be the case.

What happens if some system (e.g. IPNI) is something you could interact with directly or via delegated routing, what does the implementation do? It seems like we'd have to bump config versions and code in ways that seem unnecessary.

This approach basically let's clients say: Do I have an <AminoDHT / IPNI / ...> implementation already?
-> Yes , I can use that (or use it to check my usage of a delegated router if I want)
-> No, ok I'll use one or more of the endpoints provided to me

[lidel]

Agree on names of "profiles": can be adjusted, they are verbose to make initial discussion easier.

But the framing of "profiles" around swarm type, like "Mainnet-for-X", and not specific routing system like "AminoDHT" or "IPNI" is intentional. Imo this is how people think about their nodes: members of specific swarm, or specific subset of swarm, and not chery-picking specific routing system by hand.

After some prototyping I've formulated an opinion that forcing end users to pick routing system by hand defeats the purpose of AutoConfig. We need higher level profiles that reflect real world needs (Kubo daemon vs inbrowser.link), and minimize the choices consumers of autoconfig.json have to do.

People who want to make low level choices will not use AutoConfig.

What happens if some system (e.g. IPNI) is something you could interact with directly or via delegated routing, what does the implementation do?

We have such system. It is DHT. And we have two profiles to reflect the difference in how Kubo vs inbrowser.link access it.

Isn't the intention of AutoConfig to be practical, and it is more likely we will need to add more delegated routing endpoints than deal with a hypothetical new routing system that is DHT-like and that can be talked to in two ways?

It seems like we'd have to bump config versions and code in ways that seem unnecessary.

Let me flip the question: what if a new routing system INPI is introduced?

No client will start using INPI when it is added to AutoConfig.

Kubo and other clients will need update their code to look for entries with INPI in addition to IPNI.

So what did AutoConfig archieve? We end up in the same state as today, where adding new endpoint to defaults requires a new Kubo release.

I think my position boils down to "naming routing systems == bad" and "we need to agree on names of profiles instead, profiles that have /routing/v1 URL lists that can be extended, profiles not specific to one routing system".

[aschmahmann]

forcing end users to pick routing system by hand

I think you've misunderstood my proposal with the system names. Say you have a kubo node and get a list of 3 systems ["AminoDHT", "IPNI", "AdinSys"] and it turns out that your node understands only what AminoDHT is. Ok, well then for the other two systems you will substitue in a delegated router and now you have support for all 3.

From another comment of yours:

There is no way to group systems in your proposal, so every implementation would have to hardcode own set of Systems that means "Mainnet".

The systems are grouped here. Every system listed is a system clients consuming (this) autoconfig should be using, whether directly or via a delegated router.

Let me flip the question: what if a new routing system INPI is introduced?
No client will start using INPI when it is added to AutoConfig.

Per the above it will get auto-added (just swap AdinSys for INPI and you see it matches exactly)

What happens if some system (e.g. IPNI) is something you could interact with directly or via delegated routing, what does the implementation do?

We have such system. It is DHT. And we have two profiles to reflect the difference in how Kubo vs inbrowser.link access it.

Right, and if there was a second system (e.g. AdinSys) like this then we'd end up with even more profiles: mainnet-for-nodes-with-dht-but-no-adinsys, mainnet-for-nodes-with-dht-and-adinsys, mainnet-for-nodes-with-no-dht-or-adinsys. Compared to just introducing AdinSys and if any system natively speaks it then it will not use a delegated router, otherwise it will.

Isn't the intention of AutoConfig to be practical, and it is more likely we will need to add more delegated routing endpoints than deal with a hypothetical new routing system that is DHT-like and that can be talked to in two ways?

I'd hope that if we ever end up in a position where there's an additional routing system that it can be talked to beyond relying on a (specific / authorized) proxy.

I think I understand how what you thought this proposal was was overkill. However, I don't see how moving from an unbounded number of profile names for implementers to know about to a list of system names that implementers don't need to understand if they don't want to makes this harder / more complicated.

[lidel]

Thank you for clearing up my misconceptions. I agree if we frame config around systems, it will be easier for clients to decide which ones to delegate, and also we no longer need to have overly prescriptive profiles.

@aschmahmann take a look at my attempt to remove need for profiles (they become more like a hint), but also remove need for inventing capabilities (keeping URL paths as indicator of that is supported):

• refactor: schema 4 with extensible systems and APIs #4

[lidel]

Superseded by #4