Only peers found from DHT seem to be getting used as relays, so can't use HTTP routers

[estebanabaroa]

@lidel

but I understand the most impactful one for you right now would be Only peers discovered from DHT can be used as relays · Issue #10899 · ipfs/kubo · GitHub?

yes that would be useful, I think in some scenarios that would help some of our users be reachable.

@lidel

Interesting idea. FYI there is IPIP-504: provider query parameter as hint for HTTP Gateways by vasco-santos · Pull Request #504 · ipfs/specs · GitHub – your idea sounds like more palatable internal (RPC) version of that but for hinting at http router.

I think a provider parameter would also be fine. One potential issue is the delegated routing API can have streaming, and I think it would be complicated for us to figure out the most optimized algorithm to know how many providers to wait for to do the request, and when to request it again when new providers are streamed, etc.

@lidel

Question: if you have access to RPC, you can update config to add router and restart node via RPC. So is this &http-router just for ergonomics?

At the moment we just hardcode a list of trackers in our apps, so the router config is enough. But at some point I think it would make sense for communities to advertise the trackers they use in their human readable name records, and/or in the community metadata (which is downloaded with IPNS over pubsub). And maybe for trackers discovered this way, it would make more sense to use them only when fetching content related to that community. They could be malicious and waste the user’s time/resources if we were to add them to the default config. For example I think bittorrent clients have a list of trackers hardcoded with the client, and also magnet links / torrent files can include trackers, and I don’t think these new trackers get added to the default trackers of the client, they only get used for that specific torrent they came with.

@lidel

and replace or pivot IPIP-378 with something backward-compatible,

We know the API isn’t supported and we don’t mind that it gets removed some day. We were just desperate to have something that works that we could use for prototyping.

And actually I dont think we need backwards compatibility, something nice and new like IPIP-378 would be preferable imo.

Since all the old clients have our trackers hardcoded, we can just make sure the old trackers keep supporting the old endpoints for some time. (We also don’t have that many users.)

@lidel

Do you have dumps / examples of PUTs done by this legacy API

We haven’t been keeping logs of full requests but if it helps you guys I could start keeping them.

I think the schema looks like this because I have it as a mock in the tests:

{
  Providers: [
    {
      Schema: 'bitswap',
      Protocol: 'transport-bitswap',
      Signature: 'mx5kamm5kzxuCnVJtX3K9DEj8gKlFqXil2x/M8zDTozvzowTY6W+HOALQ2LCkTZCEz4H5qizpnHxPM/rVQ7MNBg',
      Payload: {
        Keys: [
          'bafkreigur6gzxm3ykiol7ywou3iy3obruzs2q7boizj7oznznid34dzc3e',
          'bafkreigur6gzxm3ykiol7ywou3iy3obruzs2q7boizj7oznznid34dzc3e'
        ],
        Timestamp: 1725833163372,
        AdvisoryTTL: 86400000000000,
        ID: '12D3KooWEdCRaQTjjgbtBoSMhnguznp7GHhsin8eRDEtgEso6Z1B',
        Addrs: [
          `/ip4/1.1.1.1/tcp/4001`,
          `/ip4/1.1.1.1/udp/4001/quic-v1`,
          `/ip4/1.1.1.1/udp/4001/quic-v1/webtransport`,
        ]
      }
    }
  ]
}

At the moment the only values we look at are Keys, Addrs and ID. We didn’t bother implementing any other validation because we knew the API would change.