Closed swcurran closed 5 years ago
aries-framework-go
plans to also have present-proof
and introduce
for the initial release. Other things are required that still haven't made their way into RFCs yet.
@llorllale do you mean the initial release, or the 1.0 release (per the Hyperledger definition) or are those the same? https://wiki.hyperledger.org/pages/viewpage.action?pageId=16321784 (updated - changed the link to a more general definition).
How do these impact (or not) aries-gramework-go
:
issue-credential
. Will that be part of the initial release?Thanks
Last I understood, we needed to meet the requirements in the proposal so we could move to active status allowing us to declare the project 1.0. I think @nage would be able to provide better details on what this actually means and what we signed up for. Of particular note in that proposal I saw that we made DKMS work in scope.
After rereading the approval vote, one of the reservations brought up was that we should support multiple languages (@nage stated in the approval vote we would achieve this with a rust layer using a c-callable API - bullet point 6 in discussion). Does this mean we need to have multiple language support as well to achieve 1.0? Hopefully it doesn't mean we need to support all of the ones listed in the proposal.
Good thought. The laundry list is pretty long, but this one is particularly interesting:
Other functionality that would be in scope for a 1.0 project release would be a Decentralized Key Management Solution (DKMS) which would add key recovery, social recovery, and wallet backup and restore functionality. Much of this work would be based on the DKMS documents outlined in the Indy-HIPE dkms design folder. https://github.com/hyperledger/indy-hipe/blob/49fcd78883d38babe9c95a4e1d150969797cffa2/design/dkms/README.md
That wording puts the bar for Aries getting out of "incubating" state extremely high. Not sure what it means for getting a product within the project to the 1.0 level. If that is the bar, we really need to slow down our consumption of minor version numbers :-).
On Mon, Sep 2, 2019 at 1:26 AM Kyle Den Hartog notifications@github.com wrote:
Last I understood, we needed to meet the requires in the proposal https://wiki.hyperledger.org/display/HYP/Hyperledger+Aries+Proposal. I think @nage https://github.com/nage would be able to answer this question best.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/207?email_source=notifications&email_token=AAHYRQWBA36KMSEZWLPA4XDQHTE5DA5CNFSM4ISGJIKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5VDIIA#issuecomment-527053856, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHYRQRWKXTFSLXDWRBYC3TQHTE5DANCNFSM4ISGJIKA .
Closing this issue.
We've been adding features to ACA-Py and starting to think about what would be needed for a 1.0 release of the product. Per Hyperledger guidelines, that would mean the 0.8.0 would be API complete, and 0.6.0 would need to be functionally complete.
What functionality is needed in a release for us to declare it 0.6.0, the first predecessor to 1.0.0?
Questions and Comments
At minimum, we think we need to have what we have today, plus the 1.0 version of Credential Exchange operating.
Logically, you would have proof of interoperability via a run completed with the test suite, but at this point that would not show a lot. Doable easily, but not particularly useful.
A non-Indy implementation of credential exchange would seem like a reasonable bar to set, but that is out of our hands. Note that I think credential exchange is needed, not just DID resolution, because Credential Exchange is the only thing in the application that uses public DIDs. Does the community think this is necessary?
We could make the completion of functionality dependent on having the implementation of Aries core complete. That makes sense, but is again out of our control, and seems to be some time away. Does the community think this is necessary?
What do others think about what functionality is needed to be on a path to 1.0?