Link to quarterly Report Q1, 2021

Project:

There are three major Frameworks in Aries – Aries Cloud Agent Python (ACA-Py), Aries Framework Go (AFGo) and Aries Framework .NET (AFD)

Image Added

Feb 9, 2021

Image Added

Hyperledger Aries

 11/17

Project Health

...

• A blockchain interface layer (known as a resolver) for creating and signing blockchain transactions
• A cryptographic wallet that can be used for secure storage of cryptographic secrets and other information (the secure storage tech, not a UI) used to build blockchain clients
• An encrypted messaging system for allowing off-ledger interaction between those clients using multiple transport protocols.
• An implementation of ZKP-capable W3C verifiable credentials using the ZKP primitives found in Ursa.
• An implementation of the Decentralized Key Management System (DKMS) specification currently being incubated in Hyperledger Indy.
• A mechanism to build higher-level protocols and API-like use cases based on the secure messaging functionality described earlier.

• Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions. It includes a shared cryptographic wallet (the secure storage tech, not a UI) for blockchain clients as well as a communications protocol for allowing off-ledger interaction between those clients.  This project consumes the cryptographic support provided by Hyperledger Ursa, to provide secure secret management and decentralized key management functionality.

  
  

  Documentation

  
  

  Project Management

  JIRA issues:

  • https://jira.hyperledger.org/browse/aries 

  Repositories

  https://github.com/hyperledger/aries

  https://github.com/hyperledger/aries-rfcs

  https://github.com/hyperledger/aries-cloudagent-python

  https://github.com/hyperledger/aries-staticagent-python

  https://github.com/hyperledger/aries-framework-go

  All Aries repositories - https://github.com/hyperledger?utf8=%E2%9C%93&q=aries&type=&language=

  Communication

  Mailing List

  • https://lists.hyperledger.org/g/aries

  Chat (for questions and ephemeral discussions)

  • #aries

  Meetings

  Aries Working Group

  People who want to learn about or contribute to Aries should join this call. This does not replace our asynchronous collaboration, but should help us keep everyone up-to-date and moving together.

  Discussion items: upcoming releases, current PRs, work that will generate future PRs, architecture changes that will impact downstream teams, project standards, best practices, design, etc.

  For call details and agendas, see: Aries Working Group

  Calendars

  • Hyperledger Calendar of Public Meetings

  History

  • Proposed by Nathan George

  • Approved by the TSC on 2019-05-02

• Image Added

  This repo holds Request for Comment (RFCs) for the Aries project. They describe important topics (not minor details) that we want to standardize across the Aries ecosystem.

  If you are here to learn about Aries, we recommend you use the the RFC Index for a current listing of all RFCs and their statuses.

  There are 2 types of Aries RFCs:

  • RFCs that describe individual features (in the features folder)
  • RFCs that explain concepts underpinning many features (in the concepts folder)

  RFCs are for developers building on Aries. They don't provide guidance on how Aries components implement features internally; individual Aries repos have design docs for that. Each Aries RFC includes an "implementations" section and all RFCs with a status greater than Proposed should have at least one listed implementation.

  RFC Lifecycle

  RFCs go through a standard lifecycle.

  Image Added

  PROPOSED

  To propose an RFC, use these instructions to raise a PR against the repo. Proposed RFCs are considered a "work in progress", even after they are merged. In other words, they haven't been endorsed by the community yet, but they seem like reasonable ideas worth exploring.

  DEMONSTRATED

  Demonstrated RFCs have one or more implementations available, listed in the "Implementations" section of the RFC document. As with the PROPOSED status, demonstrated RFCs haven't been endorsed by the community, but the ideas put forth have been more thoroughly explored through the implementation(s). The demonstrated status is an optional step in the lifecycle. For protocol-related RFCs, work on protocol tests SHOULD begin in the test suite repo by the time this status is assigned.

  ACCEPTED

  To get an RFC accepted, build consensus for your RFC on chat and in community meetings. If your RFC is a feature that's protocol- or decorator-related, it MUST have reasonable tests in the test suite repo, it MUST list the test suite in the protocol RFC's Implementations section, at least one other implementation must have passed the relevant portions of the test suite, and all implementations listed in this section of the RFC MUST hyperlink to their test results. An accepted RFC is incubating on a standards track; the community has decided to polish it and is exploring or pursuing implementation.

  ADOPTED

  To get an RFC adopted, socialize and implement. An RFC gets this status once it has significant momentum--when implementations accumulate, or when the mental model it advocates has begun to permeate our discourse. In other words, adoption is acknowledgment of a de facto standard.

  To refine an RFC, propose changes to it through additional PRs. Typically these changes are driven by experience that accumulates during or after adoption. Minor refinements that just improve clarity can happen inline with lightweight review. Status is still ADOPTED.

  RETIRED

  An RFC is retired when it is withdrawn from community consideration by its authors, when implementation seems permanently stalled, or when significant refinements require a superseding document. If a retired RFC has been superseded, its Superseded By field should contain a link to the newer spec, and the newer spec's Supersedes field should contain a link to the older spec. Permalinks are not broken.