TODOs before someguy's General Availability

[lidel]

TODOs for delegated-ipfs.dev/routing/v1

Minimum we need to switch delegated-ipfs.dev/routing/v1 from Kubo to someguy:

• [x] ask both cid.contact and Amino DHT
• [x] allow adjusting config via env variables instead of CLI params (prior art in )
• [x] Docker image build & publish the same way as https://github.com/ipfs/rainbow/

cc @ns4plabs @cewood lmk if there are any additional asks from bifrost infra side that would make deployment/configuration easier – my idea is to follow similar conventions as rainbow / bifrost-gateway

TODOs for General Availability

Things to do before we start recommending someguy to our users for use in their dev/prod:

• [x] defaults: change default port to something unique (NOT 8080) (https://github.com/ipfs/someguy/issues/47)
• [ ] #63
• [x] README with usage examples (cli, docker – prior art)
• [ ] tag v1.0.0
• [ ] docs
  • [x] docs/environment-variables.md (prior art)
  • [ ] docs/kubo.md showing how to use someguy as delegated routing for Kubo specifically (including Kubo config) – this could be linked from kubo/docs/config.md too
  • [x] mention at docs.ipfs.tech (cc https://github.com/ipfs/ipfs-docs/issues/1752)

cc @2color for visibility, feel free to flag any dx/ux pain points we should fix before GA

[aschmahmann]

defaults: in addition to DHT, should we ask both delegated-ipfs.dev and cid.contact, or only delegated-ipfs.dev?

Looks like this is being done in https://github.com/ipfs/someguy/pull/50 where both are asked, but trying to understand why a little more. Is this about future proofing?

At the moment there are two widely deployed routing "systems" used by IPFS implementations:

• Amino DHT
• IPNI (albeit until federation is landed along with expectations around sync-times it's mostly considered the cid.contact service)

delgated-ipfs.dev currently just proxies those two systems. So by default hitting it in addition to the others just means the same query is happening twice, just with maybe some caching happening on delegated-ipfs.dev. What's the goal here?

---

Setting the default for someguy ask to delegated-ipfs.dev, or (re)building a tool like ipget to default to delegated-ipfs.dev seems reasonable though.

[lidel]

@aschmahmann I raised similar questions in https://github.com/ipfs/someguy/pull/50#discussion_r1515372538 before reading your comment.

In my mind the goals of including delegated-ipfs.dev are:

• include an endpoint that follows latest specs and is actively maintained by the same team, allowing us to dogfood more and give people example of system where there is more than a single endpoint.
• cid.contact and IPNI as it is today does not support /routing/v1/peers or /routing/v1/ipns routing endpoints. delegated-ipfs.dev supports all routing types.
• cid.contact does not support streaming (Accept: application/x-ndjson), delegated-ipfs.dev does.

My main question is do we even keep cid.contact , if delegated-ipfs.dev proxies to it already.

We could say we trade the additional request for resiliency of having different hostnames with separate HTTP caches, which I am fine enough as a reason enough to keep it. Thoughts?