Implementing IPNS Validator for DHT

[asmit27rai]

Hey everyone!

I've been exploring the py-libp2p codebase and noticed that IPNS (InterPlanetary Naming System) support is marked as TODO in the DHT module. I'd like to propose implementing an IPNSValidator to complete this functionality. (#1157)

Background

IPNS provides cryptographically verifiable, mutable pointers to content-addressed data. The DHT already has a PublicKeyValidator for the pk namespace, but the ipns namespace validator is missing.

Current TODOs in kad_dht.py:

• Line 280: "Do the same thing for ipns, but need to implement first"
• Lines 308, 316: IPNS validation checks needed

Proposed Approach

I've drafted an implementation following the IPNS Record Specification, which includes:

1. Protobuf definition for IpnsEntry (V2 format with signatureV2 and DAG-CBOR)

2. IPNSValidator class with:

   • Record size validation (≤ 10 KiB)
   • V2 signature verification using "ipns-signature:" + CBOR prefix
   • Public key extraction (from record or inlined Ed25519 in IPNS name)
   • RFC3339 timestamp expiration checking
   • V1/V2 field consistency validation
   • Selection based on sequence number (tiebreaker: longer validity)

3. DHT integration - auto-registered via apply_fallbacks()

4. New dependency: cbor2 for DAG-CBOR decoding

Current Status

I have a working implementation with 19 passing tests covering:

• Valid/invalid record validation
• Signature verification
• Expiration checking
• V1/V2 consistency
• Record selection logic
• DHT integration

Questions for Maintainers

Before I submit a PR, I wanted to check:

1. Is this the right time to add IPNS support? Does it align with the current roadmap?

2. Scope: Should this just be the validator, or should I also implement IPNS record creation (signing/publishing)?

3. cbor2 dependency: Is adding this acceptable? It's well-maintained and necessary for DAG-CBOR decoding per the spec.

4. Test vectors: The IPNS spec provides official test vectors. Should I include tests against these?

5. Any design concerns with the approach outlined above?

CCing : @seetadev , @acul71

[seetadev]

@asmit27rai : This is a great proposal, Asmit — thanks for taking the time to dig this deep into the DHT and for writing such a clear, well-structured write-up. 🙌
You’ve clearly done your homework, both on the spec side and on how py-libp2p is structured today.

A few thoughts, inline with your questions:

Overall direction / timing
Yes, this is absolutely the right time. IPNS being marked as TODO in the DHT has been a known gap for a while, and filling it at the validator layer is the correct first step. What you’re proposing aligns very well with where py-libp2p is headed: spec-compliant, interoperable, and incrementally complete rather than over-bundled.

Scope
I’d strongly recommend keeping the initial PR scoped to exactly what you outlined:
👉 an IPNSValidator + clean DHT integration.
Record creation / signing / publishing can (and probably should) come later as a follow-up once the validation path is solid and reviewed. That separation will make this much easier to reason about and review.

Design & approach
Your approach looks solid and well thought out:

• Following the IPNS Record Spec (V2, DAG-CBOR, signatureV2) is the right call.
• Size limits, expiration checks, sequence-based selection, and V1/V2 consistency validation are all exactly the right guardrails.
• The signature prefix handling ("ipns-signature:" + CBOR) and public-key extraction logic match expectations from other implementations.
• Auto-registration via apply_fallbacks() is a nice touch and keeps integration clean.

The fact that you already have 19 passing tests covering validation, selection, expiration, and integration is a big plus.

Dependency (cbor2)
Adding cbor2 sounds reasonable. It’s well-maintained, widely used, and DAG-CBOR decoding isn’t something we should try to hand-roll. As long as it’s clearly documented and scoped to IPNS validation, this feels like an acceptable dependency.

Test vectors
Yes — including the official IPNS spec test vectors would be excellent, especially for long-term interoperability and regression safety. They don’t have to all land in the first PR, but if you already have them handy, that would be very welcome.

Next steps
I’d say go ahead and open the PR with:

• The validator + DHT integration
• The existing test suite you’ve described
• Clear documentation/comments referencing the relevant parts of the IPNS spec

We can then review and iterate on any edge cases or integration details together.

Overall: really strong proposal, very much in the spirit of py-libp2p. Looking forward to reviewing the PR — nice work 👏

[seetadev]

@asmit27rai — one more related update that may be useful context as you work on IPNS.

We’re in the process of getting py-ipld-dag un-archived again:
https://github.com/ipld/py-ipld-dag

CCing @0-th , who have been working on Storacha Python client and can share multiple pointers over here.

In the meantime, it would be great if you could also take a quick look at the py-ipld-dag-pb work that’s been happening. The DAG-PB functionality has been actively tested and hardened across the following PRs by @0-th:

• feat(test): add basic tests storacha/py-ipld-dag-pb#3
• feat(test): add compatibility tests storacha/py-ipld-dag-pb#5
• feat(tests): add edge test cases storacha/py-ipld-dag-pb#6
• feat(tests): add forms test cases storacha/py-ipld-dag-pb#7
• feat(tests): add protobuf test cases storacha/py-ipld-dag-pb#8

@0-th also added coverage against the standard IPLD codec fixtures, which significantly increases trust and recognition in the broader IPLD ecosystem:

• feat: add tested ipld-dag-pb python library ipld/codec-fixtures#149 — added DAG-PB fixture tests
• feat/add python car library ipld/codec-fixtures#152 — did the same for the CAR library; there’s still an elusive ordering issue during CAR decode/encode, but the library behaves correctly in practice

Related libraries that may be relevant for future integration work by @0-th:

• py-ipld-unixfs
  feat: add codec module storacha/py-ipld-unixfs#5 — adds a codec layer

• py-actress (actor-based concurrency, used by py-ipld-unixfs)
  feat(wip): port reference JS implementation to Python storacha/py-actress#13 — WIP, currently adding tests and fixing implementation bugs

Sharing this mainly for awareness and alignment — there’s a lot of parallel groundwork happening across the Python IPLD stack, and your IPNS work fits very naturally into this direction.

CCing @acul71 , @sumanjeet0012 and @yashksaini-coder , who will collaborate with you on this effort soon.

[asmit27rai]

@seetadev I opened a pr with some starting implementation still working on some improvement
... #1161