...
- Alexander Shcherbakov (Evernym) <alexander.shcherbakov@evernym.com>
- Nemanja Patrnogic (Evernym) <nemanja.patrnogic@evernym.com>
Related Calls and Announcements
...
- Documentation improvements: Michael B and Stephen C
- Need to review and prune out-of-date documentation (Alice / Faber treatment of pairwise DIDs is a key pain point)
- Michael is working on Indy Agent walkthrough using C#
- Finishing work on ReadTheDocs (2 more weeks?)
- Cloud Compass is building the Linux Foundation EdX courses for Indy and Aries
- SDK 2.0 architecture / Indy-Aries split (Sergey)
- Evernym: A PR with an example how the wallet can be separated; this is internal work
- Kiva is working on a Futures implementation of threading (instead of call-backs) (https://github.com/kiva/aries-sdk.git)
- CI / CD: GitLab migration (Mike and Steve G)
- Advanced Schemas and W3C creds (Ken)
- Warnings from rust cargo clippy (Mike and Axel)
- Epic: IS-1410
- New design for revocation / Anoncreds 2.0 (Mike)
- Would be useful to have a comparison in performance between Anoncreds 1.0 and Anoncreds 2.0
- Need a plan for changes to Indy Node
- HIPE for overall changes, then a design PR for the changes specific to the different repos.
https://github.com/hyperledger/indy-node/tree/master/design
- HIPE for overall changes, then a design PR for the changes specific to the different repos.
- Replacing Indy-Crypto with Ursa in Indy Node (Mike and Cam)
...
- The future of consensus in Indy Node: proposal for moving from RBFT to Aardvark
Jira server Hyperledger JIRA serverId 6326cb0b-65b2-38fd-a82c-67a89277103b key INDY-2250 - Kiwa is OK
- No other comments or concerns
- Update on Indy / Aries split
- Watch last Aries call recording
- create repos for AriesJira server Hyperledger JIRA serverId 6326cb0b-65b2-38fd-a82c-67a89277103b key ARIES-3
- move Indy wallet into AriesJira server Hyperledger JIRA serverId 6326cb0b-65b2-38fd-a82c-67a89277103b key IS-1376
- Define the pull request review process for Indy Plenum/Node
- Should define the process, including how we handle exceptions (emergency fixes shouldn't be blocked, but would require notification)
- What is important in a good review?
- Items from Evernym team:
- covered by tests
- has a link to the issue in Jira
- fixed according to PoA
- follows https://github.com/hyperledger/indy-node/blob/master/docs/source/write-code-guideline.md
- Items from Evernym team:
- Proposed Process (by Evernym team):
- All Pull Requests can be reviewed by non-Evernym team members
- Evernym team members will also do internal review in addition to external one
- All interested parties are notified when a PR is sent
- If a person wants to do an external review, he or she puts a comment or tag. This needs to be done in X hours.
- Once a reviewer put a "want-to-review" tag, he or she need to finish review in Y hours
- If no one wants to review a PR in X hours, or review is not finished in Y hours, we can do our internal review and merge the PR
- An external review can be done against closed PRs as well, and Evernym team will process all findings ASAP
- We may merge a PR with internal review only in case of urgency (critical fixes, release preparation etc.)
- Items to be defined with the Community:
- A timeframe for external review (X):
- X=12 hours, Y=2 days? - What projects it should affect?
- Plenum and Node?
- Only Node?
- We are not proposing SDK as it will be split to Aries in any case - Who is going to commit to participate in this process?
- A timeframe for external review (X):
- No volunteers on this call
Future Calls
- Requirements question: IS-1099, should we allow duplicate credentials from the same issuer?
- Non-secrets in the Indy Wallet
- Cam is working on pluggable crypto. They wallet shouldn't decide what encryption you should be using.
- Use cases where we would want to move keys between wallets
- Moving the link secret / credential data from one device to another (synchronized storage).
- Debug use cases
- Richard's hit other uses cases that were better solved with DID Doc, pre-signing, signing API.
- Work-around with the web-crypto API
...