Skip to content
This repository has been archived by the owner on Jun 20, 2024. It is now read-only.

Delegate resolution of DNSlink and IPNS records #5

Closed
lidel opened this issue Feb 1, 2023 · 4 comments
Closed

Delegate resolution of DNSlink and IPNS records #5

lidel opened this issue Feb 1, 2023 · 4 comments
Milestone

Comments

@lidel
Copy link
Collaborator

lidel commented Feb 1, 2023

Initial idea (for Feb 17 binary)

  • For resolving /ipns/id content paths to /ipfs/cid ones
    • Delegate RPC at https://node[0-2].delegate.ipfs.io/api/v0/resolve (it handles both DNSlink and IPNS)
    • (TBD) if we need local cache per id to avoid sending lookup, we can do it in two stages:
      • naive mvp can be 1 minute LRU cache, matching current behavior in Kubo 0.18 (which we want to fix long term)
      • correct cache is based on record TTL, so we reuse resolution for subsequent requests
        • this may require us to switch away from /api/v0/resolve and handle IPNS and DNSLink separately
          • DNSLink: run own DNS lookup for TXT record, and cache based on TTL of TXT record
          • IPNS record: use /api/v0/routing/get and cache based on TTL of the IPNS record
  • For resolving raw IPNS record
    • Delegate RPC at https://node[0-2].delegate.ipfs.io/api/v0/routing/get (cc @hacdias to confirm, I believe we already do this is tests)
  • Ensure resolution is as fast as possible:

Long term, we want to use delegated HTTP routing for IPNS (follow-up for IPIP-337, when that API supports IPNS lookups), and DoH for DNSLink (https://github.com/libp2p/go-doh-resolver/ ?)

@hacdias
Copy link
Collaborator

hacdias commented Feb 2, 2023

@lidel I wonder if using the ?type=ipns-record couldn't also be an option so would not necessarily need to rely on the RPC API. Also, /api/v0/routing/get is not available on the delegate nodes, and relying on /api/v0/resolve would mean we fully trust the delegated nodes. I would prefer to run my own DNS lookup and have a way of fetching raw IPNS records I could cheaply verify myself.

@lidel
Copy link
Collaborator Author

lidel commented Feb 2, 2023

@hacdias we won't have ?type=ipns-record because bifrost-gateway we will be the gateway that is supposed to implement it. We won't be running DHT client (no go-libp2p is hard requirement for bifrost-gateway binary atm), and we don't have IPIP specs or implementation for ipfs/someguy#15 yet, so the only option that works for Feb 17 deliverable is /api/v0/routing/get from preexisting delegates.

I filled https://github.com/protocol/bifrost-infra/issues/2327 to expose /api/v0/routing/get there, but if you have better idea lmk (i also don't like this, but don't see anything else that would work for 17th).

@BigLep
Copy link

BigLep commented Feb 2, 2023

Discussion/analysis of v0 api usage on ipfs.io was done here: https://www.notion.so/pl-strflt/API-v0-Distribution-9342e803ecee49619989427d62dd0f42

@lidel lidel added this to the M1: Feb 17 milestone Feb 3, 2023
@lidel
Copy link
Collaborator Author

lidel commented Feb 11, 2023

Done in #19

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants