Support legacy double-hash entries for IPNS CIDs and DNSLink #40
Open
Labels
effort/hours
Estimated to take one or several hours
exp/intermediate
Prior experience is likely helpful
P1
High: Likely tackled by core team if no one steps up
Why
Filling this issue so we don't have regression in IPNS Blocking (https://github.com/ipshipyard/waterworks-infra/issues/209) when switching from legacy badbits service to modern NOPFS-based support in rainbow and kubo.
We need to ensure modern nopfs in rainbow/kubo applies check to
/ipns/{id}
content paths starting with either ipns record as cidv1 and a string with dnslink name.What
Work here is to check NOpfs behavior, namely, if legacy double-hashed rules are applied to
/ipns/
namespace, and if not, implement it.Badbits denylist already has a lot of IPNS CIDs + our legacy infra supports double-hashed DNSLink since https://github.com/protocol/badbits.dwebops.pub/pull/40002.
We also clarified in specs ipfs/specs#482
Test vectors
/ipns/k51qzi5uqu5dixwsch9wpd9rolqby1m0uqj5hhxwtxal0dwltastfmh01dlniq
→//6ef262a67f2c7caa9722b0fe46aced2f1559c749eab2bcf2f2701f43f802e900
The text was updated successfully, but these errors were encountered: