2021 Q4 Hyperledger Indy

Created by Stephen Curran, last modified by Angelo De Caro on Dec 09, 2021

Projects

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 ( https://github.com/hyperledger/indy-did-method ) 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.

Releases

  • 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

Comments:

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?

Posted by lehors at Nov 11, 2021 07:43

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)

Posted by Peter Somogyvari at Nov 15, 2021 21:24

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.

Posted by swcurran at Nov 16, 2021 03:54

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.

Posted by swcurran at Nov 16, 2021 04:01

Stephen Curran Thank 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)

Posted by Peter Somogyvari at Nov 17, 2021 01:04

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. Th"at 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.

Thanks!  

Posted by swcurran at Nov 18, 2021 00:05

Stephen Curran Thank 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)

Posted by Peter Somogyvari at Nov 18, 2021 00:17