Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Projects

Distributed Ledger
Client Tool
Shared Components

Project Health

In a change from the previous quarters, contributions to Indy ticked up this quarter – a good thing!  The project is getting a lot of external attention and that is (finally!) changing into contributor interest.  Attendance is up significantly at community meetings, a new repo was added (indy-node-container – a containerized instance of Indy Node for easier deployment). As well, the first major addition to Indy in some time was added – an implementation of did:indy in indy-node, with the following features:

  • Indy clients (e.g. Aries Agents) can add full DID Standard DIDDocs to an Indy DID published on the ledger. This had not been supported in Indy prior to this because Indy pre-dated the DID Standard.
  • A client can indicate a new DID is self-certifying, with the ledger verifying that the DID (the identifier) was derived from the initial verkey (public key) of the key pair associate with the DID
  • The did-indy-method repository and published spec have been updated to match the implementation.
  • Changes were added to indy-vdr to implement the "network of networks" support so that a DID will contain an extra "namespace" element indicating on which Indy network the object is to be found.
  • A mechanism has been defined based on the concept of DID URLs as a mechanism for providing identifiers for other AnonCred objects beyond DIDs: schemas, CredDefs and Revocation Registries.
  • The use of the ATTRIB transaction was deprecated in favour of the (somewhat) less arbitrary DIDDoc feature of DIDs. The use of ATTRIBs may be used for other purposes in the future, but we'd like to stop the "wild, wild west" days of using ATTRIB for anything.

A BC Gov "Code With Us" challenge for $CDN70k was create to get work on the "did:indy" method done. The challenge was won last quarter and implemented this quarter by two respondents – Indicio for the Indy Node/Plenum work and Dominic Wörner for the Indy VDR (Client) work. They completed the plan worked and their changes have been merged into the relevant code bases. Kudos to all of the participants and the progress it represents!

On the less good news front, the CI/CD upgrade and Ubuntu 20.04 effort moved forward, but is still not complete.  Just as was stated in the last quarterly report, there is still work to do, but progress was made – including some significant updates.  The big items to complete remain the same:

  • Investigation of a potential intermittent bug on a network with a mix of Ubuntu 16.04 and 20.04 nodes (likely something in libsodium).
  • Automation of a tagged release to produce published artifacts.

As mentioned in the last report, the focus on making AnonCreds a standard vs. an open source implementation de facto standard is gaining momentum. The standard drafting process is going will, producing this work in progress spec, with a strong contingent working regularly to evolve it.

Work continues this quarter on the new client-side Indy library indy-vdr, and on indy-shared-rs, although no new releases were tagged. The Aries Cloud Agent Python project has made the use of the shared components (along with Aries Askar) as the recommended default for ACA-Py. The stability and performance results are much better than with Indy SDK.

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 (2022-01 to 2022-03), there were 135 commits from 20 contributors. both of which are double the numbers from 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. We're seeing improvements beginning as more deployments begin (notably Aries deployments) and the importance of the underlying ledger utility is understood. We need more, but in this quarter, there was improvement seen.

Releases

  • indy-did-method (completed)

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.  Unlike previous quarters, there was also work completed on the did:indy DID Method and effort put into providing stable indy-node containers.

Current Plans

The push will be to complete the new CI/CD Indy Node and Plenum pipelines, the Ubuntu 20.04 upgrade.

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 increased recently, with more and more interested parties showing up, and new contributors weighing in on the conversations.

Contributor Diversity

The "Indy Contributors" course was presented in early 2022 and was extremely well received. 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


  • No labels