Page tree
Skip to end of metadata
Go to start of metadata


Distributed Ledger
Client Tool
Shared Components

Project Health

The work on the Indy DLT (indy-node and indy-plenum) continued slowly this quarter with a focus only on the CI/CD capabilities and upgrading to Ubuntu 20.04. A small team of 3 working on the project. Again this quarter no new functionality was added to Indy. The transition of the CI/CD from an older, undocumented Jenkins/manual process to a GHA-based CI/CD pipeline has been slow but seems to have turned a corner. The work on the CI/CD and OS Upgrade has prevented progress on new features – blocking most notably the upgrade to the new "did:indy" DID Method.

The "did:indy" method has a new repo ( and the spec has been moved from a HackMD document to.a published specification. The task backlog to implement the new DID Method is still to be created, and work will start once the CI/CD and Ubuntu upgrades are sufficiently stable.

Work has accelerated this quarter on the new client-side Indy library indy-vdr, with 3 tagged releases. More teams are deploying that code and contributing to the code base. Non indy-sdk or indy-shared-rs tags were created.

The interest in deploying instances of Indy continues to be strong, with lots of questions on Hyperledger Chat from people learning to run their own instances. There are no significant bugs that are pending action, and little demand for new functionality (beyond the "did:indy" method) from the user base. Indy "just works". 

Per the Indy Activity Dashboard (2021-07 to 2021-09), there were 72 commits from 14 contributors. which is up a little from the last quarter.

Questions/Issues for the TSC

Issues from previous reports:

Build Pipelines

Update: Steady progress, with GHAs implemented, the test automation process updated and the Ubuntu upgrade nearing completion.

Diversity of Contributor Community

Update: Contributor community diversity remains a top of mind issue with the maintainers. The Hyperledger Staff (particularly David Boswell and Ry Jones – thanks!) working on getting an "Indy Contributors" course in place for early in 2022 in conjunction with the ToIP Foundation. We have also had a number of new contributors joining Aries projects that have a reliance on Indy.  We expect that to result in a focus on the "did:indy" work that is needed. As noted, interest and contributions to indy-vdr have increased.


  • indy-did-method (first draft)
  • indy-vdr 0.3.1, 0.3.2, 0.3.3

Overall Activity in the Past Quarter

In the past quarter (as in the previous quarter), ledger code development focused on code management – upgrading the Indy Node and Plenum CI/CD pipeline and upgrading Indy Node to run on Ubuntu 20.04.  

There has been some progress on the new Indy DID Method, but not code. The work left at the end of the last two quarters remains (albeit now as a repo vs. HackMD doc): wrapping up the specification and defining the backlog of work for indy-node, indy-sdk and indy-vdr. With the CI/CD work blocking progress on indy-node, it's been difficult to convince contributors in the community to work on the DID Method if it is so hard to test and impossible to release.

Current Plans

The push will be to complete the new CI/CD Indy Node and Plenum pipelines, the Ubuntu 20.04 upgrade, and tools to make it easier to do Indy Node development. In parallel, we expect coding to begin on the "did:indy" method.

Maintainer Diversity

The bi-weekly Indy Contributors call continues to be the medium by which maintainers coordinate work, discuss critical issues to the Indy codebase, and agree on HIPEs. Topics and attendance has dropped recently, mostly because of the lack of topics other than "how is the CI/CD work coming along?"

Contributor Diversity

Work has begun on putting together an "Indy Contributors" course for presentation in early 2022. The edX course about Indy, Aries and Ursa (here) was updated early in 2021 (this was missed in the last Quarterly report – even though the author of the quarterly report was the course creator...).

Additional Information

Reviewed by


  1. I realize this is probably not really the place to discuss the Indy DID method but I have to ask:

    While I understand the interest in having a dynamic resolution mechanism isn't it counter productive to depend on a centralized service like github given that the premise was that depending on a domain name was considered unacceptable because users don't have full control over it?

    Isn't depending on a specific service under the control of a single corporation even worse than depending on the DNS which is under the control of ICANN?

    1. Yup...we understand the, shall we say, awkwardness of that approach.  The goal will be to enable better approaches over time, particular the idea of cross-registration of networks on the networks themselves.  We did discuss that option, and we're open to other techniques for DID-component-to-configuration-file mappings.

      For now, the driver to punt on that issue is that we need the first two features of the DID Method ASAP (multi-network identifiers and full DIDDoc support) much sooner than a proper and robust discovery mechanism, particularly while we expect discovery to be more "word of mouth" driven in the initial implementations.

  2. Are there any plans to provide a JS native SDK implementation for indy or is the long term plan to have the NodeJS SDK be a wrapper around the bindings for other languages (it was either Python or C++ IIRC)

    1. Hi Peter Somogyvari

      There is a nodejs wrapper for the Indy SDK, along with several others (list here).  All of the Indy client-side apps (indy-sdk, indy-vdr and indy-shared-rs) are implemented in Rust and thus have a C FFI that is possible and wrappers in various languages.

      The primary use of a JavaScript wrapper is to enable using the indy-sdk in an Aries Framework – notably Aries Framework JavaScript, which is under intense development right now to enable an open source Aries wallet.

      1. Stephen CurranThank you for the information! Are there any plans to add a wasm-pack build target to the code that's implemented in Rust providing the C FFI? (which would enable the code to be loaded without the NodeJS gyp binding/linking/compilation/etc. steps)

        1. Peter Somogyvari interesting comment. I'm not a Rust person, but have talked to the folks that built this and that option has not been raised.  From what I have understood (until now), there was not a wasm option, and generally, not a better way to use generally use the library other than via FFI. That said, I do know about (but not the details) a way to use a Rust library in Python that provides more of a "Python native" interface – allowing things like shared access to data vs. the typical FFI "make a copy" approach.

          I'll ask around if that is possible with this codebase.


          1. Stephen CurranThank you for the detailed answers and the asking around, very much appreciated! And please also note (just in case) that I'm merely asking these questions for my own information.

            My (entirely selfish) reason for advocating for wasm adoption is because I happen to be a maintainer of a project that uses NodeJS so it makes life simpler from that perspective. (smile)