You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 20, 2024. It is now read-only.
lidel
changed the title
Support DNSLink on *.eth: use the same implicit DNS resolvers as Kubo
Support DNSLink on ENS AKA decouple namesys defaults from Kubo
Mar 7, 2023
lidel
changed the title
Support DNSLink on ENS AKA decouple namesys defaults from Kubo
Support DNSLink on ENS (decouple namesys defaults from Kubo)
Mar 7, 2023
lidel
changed the title
Support DNSLink on ENS (decouple namesys defaults from Kubo)
Support DNSLink on ENS (move namesys defaults out of Kubo)
Mar 7, 2023
@lidel I think the idea of moving to go-libipfs/gateway (approach B) is the best option to go, as it allows re-use without cluttering too much our other general packages (go-namesys).
Problem
bifrost-gateway must have feature and behavior parity with Kubo, but we have a bug around ENS:
Potential cause
Seems that we are running different namesys config than Kubo.
It should use the same set of
defaultResolvers
to support ENS and UD, as noted in the config docs, but*.eth
resolution does not work atm.Cleanup proposal
Move
defaultResolvers
to one of upstream libraries, and make them implicit default to avoid ENS failures like this one.Option A: move to go-namesys (global)
defaultResolvers
from Kubo to https://github.com/ipfs/go-namesysThis applies defaults to both DNSLinks and Multiaddrs, allowing use of
*.eth
in/dnsaddr
tooOption B: move to go-libipfs/gateway (minimal, scoped to DNSLinks)
defaultResolvers
from Kubo to https://github.com/ipfs/go-libipfs/tree/main/gatewayWithNameSystem
option for passing custom namesys – we could use that in bifrost-gateway to pass namesys with these additional resolvers, ORThis would only apply to DNSLinks, but that is enough given the utility of ENS today (just DNSLinks).
@hacdias @aschmahmann Thoughts?
I feel (B) may be cleaner:
WithNameSystem
allows users to pass custom resolversWithNameSystem
is passed we applydefaultResolvers
on the library level as implicit defaultThe text was updated successfully, but these errors were encountered: