2020 Q4 Hyperledger Aries

Created by Stephen Curran, last modified by Gari Singh on Feb 05, 2021

Project

Hyperledger Aries

Project Health

Project health is strong, getting stronger, and the community is thriving. There are a number of significant projects going on within and outside of Hyperledger related to Aries, and continuous progress is being made across the community.

Questions/Issues for the TSC

Given the nature of Hyperledger Aries as a set of protocols and a set of implementations of those protocols versus a releasable artifact, how do we declare Aries as “active” vs. the current “incubation”? A newcomer arriving at Hyperledger knowing about Indy and Aries might see the “incubation” status and shy away, even though Aries builds on Indy and it has numerous production deployments?  IMHO, Aries is production ready, but there has been little discussion about changing the status, and it’s not clear how the Hyperledger definition should apply to this type of project.

A second question relates to the fact that a core element of Aries is the protocols defined in the Aries RFCs repo. Does the TSC have an opinion on whether Hyperledger Aries is the right, safe location for those protocols?

Releases

There are three major Frameworks in Aries – Aries Cloud Agent Python (ACA-Py), Aries Framework Go (AFGo) and Aries Framework .NET (AFD), with a fourth (aries-framework-vcx) being extracted from Indy into Aries.  All are active, with ACA-Py and AFGo releasing regularly:

  • ACA-Py had 11 releases in 2020
  • Aries Framework Go has 5 releases in 2020

There are (at least) 14 active repos in Aries (per the metrics below – although I think there might be a couple of others…to be verified), including the major (and several less mature) frameworks, conformance and interoperability test suites, and several tools and utilities.  Added in early 2021 is an Aries-level secure storage component th”at replaces a comparable component in the indy-sdk and is available for use across frameworks. It is the first “shared component” in Aries, with more expected in the next year.

Overall Activity in the Past Quarter

Per the  Aries Activity Dashboard for the last quarter of 2020, Aries codebases had 708 commits in 506 PRs from 44 contributors.

Community participation is extremely active in rocketchat channels, community calls, and repo PR reviews and issues. Email lists are less frequently used.

Coordination with the DIF DIDComm working group is healthy, with regular reports being shared.

Project work in main repos is healthy and active.

Current Plans

  • Aries Interop Profile (AIP) 1.0 was accepted by the community in January 2020 and has been successful in enabling multiple Aries deployments to interoperate – especially ACA-Py (enterprise) and AFD (enterprise and mobile) deployments.
  • AIP 2.0 is in draft at the Aries Working Group and is expected to be completed in January 2021. AFGo skipped past AIP 1.0 and it is expected that with AIP 2.0 we will achieve interoperability across all major frameworks, which is great for the entire community.
  • Work is now active to extend Aries beyond support just Indy ledgers and Indy AnonCred verifiable credentials to supporting other ledgers and other verifiable credential formats – most notably BBS+ signatures, supporting ZKPs and selective disclosure.
  • AFGo chose not to use Indy as the underlying ledger or verifiable credential model (although contributors have added that), so the other frameworks so the Aries protocols have implementations that other frameworks can follow.

Maintainer Diversity

Aries is a multi-codebase effort, and each codebase has its own set of maintainers. The diversity of maintainers closely matches contributors, with notes below.  Cross framework collaboration is increasing. For example, work is happening on interop testing capabilities across the Python, Go, .NET and JavaScript frameworks.

As interest in verifiable credentials has increased with COVID-19 use cases (proof of testing, proof of immunization and mobile medical workforces), interest and attendance has increased, as have deployments of Aries-based implementations.

Contributor Diversity

We have not tracked meeting attendance, RFC contributions, and code contributions in a way that makes it easy to quantify contributor diversity. Here are a few indicators of our current diversity:

  • We hold two community calls: Weekly at Noon Pacific to cover US and Pacific contributors, and every two weeks at 7am Pacific to cover US and European contributors.
  • Call attendance for each call is typically in the 15-20 range.
  • Most organizations have only one attendee; it is rare for more than 3 to attend from the same organization.
  • Cross codebase interoperability efforts indicate cross-organization cooperation.

Additional Information

Please note the questions to the TSC raised at the top of the document.

Reviewed by

Comments:

Daniel Hardman Sam Curren   Troy Ronda   Tomislav Markovski Andrew Whitehead  – anything to add/modify/delete from this report?

Posted by swcurran at Jan 15, 2021 01:18

Nothing to add from me. Wondeful report,  Stephen Curran

Posted by danielhardman at Jan 15, 2021 07:03

I think the questions raised are important ones that ought to be discussed by the TSC and that are relevant to the overall community beyond Aries. So, I added them as discussion items for our next call: 2021 01 21 TSC Meeting Record .

Thanks.


Posted by lehors at Jan 20, 2021 15:45

'H ow do we declare Aries as "active" vs. the current "incubation"?'

You should apply for active status!  My personal opinion is that it seems like you all can more than meet the criteria with a little bit of work (i.e. the CII badge needs completion).

Posted by hartm at Jan 20, 2021 19:29

"Does the TSC have an opinion on whether Hyperledger Aries is the right, safe location for those protocols?"

Questions about standards are always going to be complicated.  While the majority opinion has always been that we don't want Hyperledger to become a standards organization, it seems that de facto standards th"at come out of code have typically been accepted.  I'm guessing that no one will have problems with what you are doing, but it is something worth bringing up to the TSC.

Posted by hartm at Jan 20, 2021 19:31

Here are my thoughts

Re: "A newcomer arriving at Hyperledger knowing about Indy and Aries might see the "incubation" status and shy away, even though   Aries  builds on Indy and it has numerous production deployments? IMHO, Aries is production ready, but there has been little discussion about changing the status, and it's not clear how the Hyperledger definition should apply to this type of project."

[Arun] Given the significance of Aries and the adoption, it shall be made clear that there is no actual tie-up with the Indy. In other words, Aries shall have a spec repository. This shall serve as an entry point for somebody wanting to begin their journey. Aries agent implementations (ACA-Py/Go/.Net etc) can be spawned from here.

Re: " A second question relates to the fact that a core element of Aries is the protocols defined in the   Aries RFCs  repo. Does the TSC have an opinion on whether Hyperledger Aries is the right, safe location for those protocols? "

[Arun] These define one of the way to achieve the goal. These define how an Aries agent out of box behaves. They are not standards. If a standardization entity likes this model, they could potential define one.

My proposal here is also to bring up a specification repository, this does not necessarily mean a standard definition. The specification repository serves as a main repository for the Aries. As long as at least one agent implementation follows the spec, Aries can be considered as an active project. Rest of the documentation is left to the Aries community, i.e. for instance the Aries community can define availability of agents in Go/.Net etc through a table in README file in the spec repository.

Posted by arsulegai at Jan 31, 2021 08:49

I understand that Aries has its own RFC repository, that is where the spec is being tracked. This shall be made easily accessible. I am happy to work with the community &  David Boswell to define a process/reuse the RFC as a specification repository or even setup a website to serve these over there.

Posted by arsulegai at Jan 31, 2021 08:50