Hyperledger Project Update
Project
Distributed Ledger
Shared Components
Project Health
As planned, the contributors to Hyperledger Indy spent this past quarter working on three key initiatives:
Hardening the ledger so that it is ready for widespread usage,
Improving the developer experience when using the SDK,
Maturing reference agents so that they are usable by new participants in the ecosystem.
These three efforts have yielded significant results:
This week the Sovrin network is being upgraded to the latest release of Indy Node. It is now ready for production identity projects. The government of British Columbia is immediately expected to go live with their project.
Evernym has contributed their verifiable credentials exchange library (libVCX) to the Indy SDK, making it significantly easier to build solutions that leverage Indy credentials. libVCX works against a demonstration cloud agent, and work has begun to evolve that communication to interoperate with the other Indy reference agents.
Significant work has been done on standardizing the agent connection protocol, including the implementation of a test suite that can be used to demonstrate compatibility between agents. In addition, the organizational agent contributed by British Columbia is maturing into a sub-project of Hyperledger Indy that we are calling Hyperledger Indy Catalyst.
Other important outcomes this quarter:
The CI / CD pipeline for the Indy projects is now significantly more robust. The Android, iOS, and Windows builds are no longer exclusively hosted by Evernym, but are also being hosted by the Sovrin Foundation.
The hackfest that coincided with the Hyperledger Member Summit in Montreal was well attended, as were the Indy demonstration sessions at the Internet Identity Workshop.
Indy’s interests were well represented in the Verifiable Credentials Working Group at the
W3C TPAC in Lyon.
Indy’s codebase has surpassed 15,000 commits from 131 unique contributors.
The Indy team has been working with other Hyperledger teams to establish the indy-crypto library as a shared Hyperledger library called Ursa. We now need to migrate to this new library.
New interesting use cases for Indy are being developed.
One exciting Indy solution is Cordentity, which is developed through a collaboration with Luxoft and Tieto.
“Cordentity is a self-contained CorDapp identity service that integrates Hyperledger Indy, for decentralized identity, with the R3 Corda Platform. This project creates interoperability of two purpose-built ledger technologies, each with a focus on privacy. Corda is designed to enable private transactions and Indy is a ledger built specifically for self-sovereign identity.”
More details are available [in R3’s solution marketplace](https://marketplace.r3.com/solutions/Cordentity/d680ac65-cb41-450c-950c-21c646b19384?referrer=featured-card).
Another exciting Indy solution is being pursued by the BC Government:
“The Verifiable Organizations Network (VON) envisions globally available Hubs that bootstrap Self-Sovereign Identities by making it easy for Issuers of authoratitive credentials - especially governments - to issue and use Verifiable Credentials. Built on top of Hyperledger Indy technology, VON empowers Governments, organizations and individuals to benefit from being associated with trustworthy sources of data and the ability to exchange this data in trustworthy ways.
The BC Government would like to solidify the VON model, code and business processes as a sub-project of Hyperledger Indy called “Hyperledger Indy Catalyst”. Instances of HL Indy Catalyst operated in jurisdictions around the world will drive the supply side of the Verifiable Credential (VC) ecosystem by enabling Government (and other permitted) Services to Issue and Verifier VCs as a form of digital Licenses, Permits and Registrations before Digital Wallets become commonplace. With a robust supply side, the demand for VCs will grow as organizations and individuals understand the utility of holding and using digital versions of the Licenses, Permits and Registrations that they currently receive only in (easily forged) printed form.”
Issues
Most of the concerns raised in our last report still exist, and we will continue our efforts to address them.
Meet the needs of a diverse set of contributors
Coordination between teams has been difficult at times, slowing progress in some aspects of development
Progress made:
Contributors have collaboratively created twelve [Hyperledger Indy Project Enhancement](
https://github.com/hyperledger/indy-hipe) (HIPE) documents, codifying areas of the project such as maintainer procedures, the key git repositories, encryption, message types, wallets, and the agent test suite.
We have consistently held coordination calls between maintainers from different organizations who are contributing to Indy as a whole, Indy SDK, Indy Agents, and Indy Overlays.
Further remediation planned:
-
We need to diversify the contributions to the core ledger by encouraging other teams to step up to match the investment made by Evernym’s team.
Embedding developers from multiple organizations into the same sprint team to meet specific development goals
Ensure quality releases for downstream users
This upgrade of the Sovrin network is the first in six months. The delay is due to concerns about the quality of the Indy releases, and the effort required to upgrade due to changes that are not backwards compatible.
Progress made:
Recently the team has given significant focus to testing Indy Node for scalability and performance, resulting in a lot of bug fixes and refactoring for maintainability.
The team has identified places where the algorithms for view change and catch-up can fail. We have started researching possible solutions to these concerns.
The team has been using new tools for automated testing (indy-chaos framework).
Improvements in the CI / CD pipeline should provide more reliable releases with consistent versions of components.
Further remediation planned:
The Indy team will continue to focus on providing releases that can be immediately deployed downstream.
The team is being more deliberate about preserving backwards compatibility.
We are launching a formal research project to design a “ledger 2.0”, including representatives from many organizations within our community..
Inconsistent documentation
The lack of quality documentation remains a significant obstacle for many of those interested in working with Indy. Many contributors have included documentation with their work; however, this documentation sometimes does not match the existing documentation or is not easily found.
Progress made:
In the past quarter we did not make the progress on documentation that we had hoped. The member of our community who volunteered to lead this effort ended up changing employers. We need to renew our efforts to improve things this quarter.
However, members of our community did assemble a set of “getting started” resources that will be helpful to new developers.
We also have a HIPE drafted to establish documentation guidelines, but it has not yet completed review.
Further remediation planned:
Publish the getting started resources somewhere that is publicly and likely to be found.
Consolidating redundant documentation and reworking it for different user levels.
Proof-of-concept implementation for publishing documentation to a shared site (Read The Docs).
Minimize the onboarding burden for both developers and users
The learning curve for new developers is currently very steep.
Progress made:
Further remediation planned:
Incompatible agent implementations
Efforts are ongoing to increase interoperability between existing agent implementations and future implementations.
Progress made:
A common repository is established where we can create a set of intercompatible reference agents.
A HIPE has been accepted defining many parts of Agent to Agent communication.
A canonical test suite has been started. It will verify that a new agent follows the established communication protocol
Further remediation planned:
Measuring the size and make-up of our user community
We don’t currently have good data on the usage of Indy by organizations deploying Indy networks or by developers creating solutions
Progress made:
Further remediation planned:
Working with Hyperledger to get analytics about GitHub project usage, web sites, Rocket Chat usage
Begin measuring usage of the Sovrin forums: new contributors, questions asked, and questions answered
Build Issues
The CI/CD pipelines were made after projects had code, so each pipeline was building each of their own dependencies instead of leveraging the dependencies’ own builds. Hyperledger CI / CD infrastructure for client builds on iOS, Android, Windows, and Mac OSX have been insufficient.
Progress made:
Further remediation planned:
CI/CD pipelines will target prebuilt dependencies instead of building them from source.
CI/CD pipelines will be put in place first before additional code changes are made.
Client libraries and reference agents will be built at the Sovrin Foundation.
Releases
August 2018:
Indy SDK 1.6.3
Indy SDK 1.6.4
Indy Node 1.6.70
Indy Node 1.6.71
September 2018:
Indy SDK 1.6.5
Indy Node 1.6.73
October 2018:
Indy SDK 1.6.6
Indy SDK 1.6.7
Supported setting fees in did rotate-key CLI command.
Supported hexadecimal seed for did and key creation.
Removed TGB role.
Added EXPERIMENTAL Rust wrapper for Libindy.
Bugfixes.
Indy Node 1.6.78
Overall Activity in the Past Quarter
General
Indy Node
Indy SDK
Indy Agent
Many HIPEs moved to accepted status:
Message Types
Message Structure
Cross-domain Messaging
Significant iterations on and discussion surrounding the following HIPEs:
Significant contributions from Linux Foundation Intern, Kuzma Leshakov, in Python Reference Agent
Increased collaboration with new contributors in the community (Unveil)
Dockerization efforts from Stephen Curran
Current Plans
General
Proposal for incubation status graduation
Continue to refine documentation
Improve onboarding process for new developers
Identify beginner tasks
Provide examples
Produce more videos
Network stability of the first production deployment (Sovrin)
Indy Node
Consume official builds of Hyperledger Ursa (the shared crypto-lib), as they are approved.
Further improvements to automated testing.
Research into Ledger 2.0
Improve stability and performance of View Change, Catch-up, and Replication
Establish a cache for reads, such as observer nodes
-
Indy SDK
Indy Agent
Standardizing agent-to-agent protocol through agent test suite
Tests associated with each major aspect of the protocol
Multiple interoperable agents in the community
Continuing functionality improvements in Python reference agent
Addition of a reference cloud agent.
Contributing a reference mobile agent to the Sovrin Foundation.
Maintainer Diversity
Indy maintainers remain active in developing and contributing to working group calls and public discussions. The bi-weekly Indy Maintainers Circle call has consistently been the medium by which maintainers coordinate work, discuss critical issues to the Indy codebase, and resolve HIPEs. The Indy Agent call has grown significantly, and the Overlays Working Group continues to receive a lot of interest.
Contributor Diversity
Hyperledger Indy continues to see contribution from developers and organizations around the world. Our weekly Working Group call is normally attended by two dozen people representing nearly a dozen organizations.
POCs, Pilots, Projects
Sovrin
Verifiable Organizations Network
Brigham Young University
Evernym