Unarchive py-ipld-dag to support py-libp2p Dependency Chain

[seetadev]

Team,

We wish to request that py-ipld-dag be unarchived, as it is part of the dependency chain required for active Python libp2p development.

We currently have access to the PyPI project for py-ipld-dag: https://pypi.org/project/py-ipld-dag/

However, the GitHub repository is still archived, which is blocking active maintenance and coordinated updates across the Python libp2p dependency stack.

We have recently unarchived py-cid and are actively maintaining it for py-libp2p. Please also visit https://pypi.org/project/py-cid/ .

If py-ipld-dag remains archived, it prevents us from:

• Publishing clean PyPI releases
• Maintaining the dependency chain properly
• Ensuring long-term stability of py-libp2p

Request

We kindly request:

1. Unarchiving py-ipld-dag

2. Granting maintenance access to:

   • @acul71
   • @pacrob
   • @seetadev

We are actively working on modernizing and maintaining the Python libp2p ecosystem and would be happy to take responsibility for keeping this repository healthy and up to date.

Thank you 🙏

[vmx]

The repo is really old and it's referring to "MerkleDAG" which for many years isn't a term that is used anymore. Now it's called "DAG-PB". So it might even make sense to just start from scratch and implement the DAG-PB bits you need.

This would also enable you to license it as MIT/APACHE-2.0 as py-libp2p itself and not having it under MIT only.

[seetadev]

@vmx : Hi Volker. Greetings :) Hope you are doing well.

Wish to thank you for sharing a thoughtful and forward-looking suggestion. Appreciate it.

You’re absolutely right that continuing to anchor on the old MerkleDAG terminology doesn’t reflect where the ecosystem has been for years. Aligning directly with DAG-PB makes much more sense semantically, architecturally, and from a long-term maintenance perspective.

We’ll explore a clean DAG-PB–focused implementation and scope it carefully around what py-libp2p actually needs today, rather than recreating historical surface area. If you have any guidance on spec edge cases or minimal compliance expectations for DAG-PB in this context, we’d deeply appreciate it.

Two of my team members working on this repo with us will also be meeting you at https://luma.com/cid-congress. We have a py-libp2p meeting at the same time.

[acul71]

The repo is really old and it's referring to "MerkleDAG" which for many years isn't a term that is used anymore. Now it's called "DAG-PB". So it might even make sense to just start from scratch and implement the DAG-PB bits you need.

This would also enable you to license it as MIT/APACHE-2.0 as py-libp2p itself and not having it under MIT only.

Unarchive + access — done

The repo is unarchived and @acul71, @pacrob, and @seetadev have maintenance access. We’re treating the unarchive + access part of this request as done.

We’ll keep maintaining py-ipld-dag as the current Python implementation (e.g. merge the modernization PR, do releases as needed) so the dependency chain stays healthy in the meantime.

On the longer-term direction @vmx raised (DAG-PB naming, license): I propose to go toward a from-scratch implementation aligned with the Go and JS implementations (DAG-PB, dual MIT/Apache-2.0), rather than evolving this repo. Until that exists, py-ipld-dag remains the in-between solution for the Python stack. We’ll treat that new impl + migration as a separate track (design/scope, then implementation);
Hey @seetadev, eventually are you willing to open the new repo ?

[seetadev]

The repo is really old and it's referring to "MerkleDAG" which for many years isn't a term that is used anymore. Now it's called "DAG-PB". So it might even make sense to just start from scratch and implement the DAG-PB bits you need.
This would also enable you to license it as MIT/APACHE-2.0 as py-libp2p itself and not having it under MIT only.

Unarchive + access — done

The repo is unarchived and @acul71, @pacrob, and @seetadev have maintenance access. We’re treating the unarchive + access part of this request as done.

We’ll keep maintaining py-ipld-dag as the current Python implementation (e.g. merge the modernization PR, do releases as needed) so the dependency chain stays healthy in the meantime.

On the longer-term direction @vmx raised (DAG-PB naming, license): I propose to go toward a from-scratch implementation aligned with the Go and JS implementations (DAG-PB, dual MIT/Apache-2.0), rather than evolving this repo. Until that exists, py-ipld-dag remains the in-between solution for the Python stack. We’ll treat that new impl + migration as a separate track (design/scope, then implementation); Hey @seetadev, eventually are you willing to open the new repo ?

@acul71 : Yes, my friend :)

@vmx has shared key insights and pointers on moving forward. Very timely and productive.

However, this will also require some more management bandwidth and quality time available at our end.

We need to do this initiative well, not just for py-libp2p but also for any project interested in python using DAG-PB.