Summary:
| Excerpt |
|---|
|
...
- Name (organization) <email>
- Richard Esplin (Evernym) <richard.esplin@evernym.com>
- Daniel Bluhm (Sovrin Foundation) <daniel.bluhm@sovrin.org>
- Adam Burdett (Sovrin Foundation) <adam@sovrin.org>
- John Callahan (Veridium) <jcallahan@veridiumid.com>
- Nicholas Rempel (BC Gov) <nick@lucent.is>
- Andrew Whitehead (BC Gov) <cywolf@gmail.com>
- Rebecca Christman <rebeccachristman@gmail.com>
- Brent Zundel (Evernym) <brent.zundel@evernym.com>
- 26 attendees
Welcome / Introductions
Announcements
...
- Aries-CloudAgent-Python (bc.gov) - Release 0.2.0, 0.2.1 tagged
- Recording for aries-cloudagent-python: Architectural Deep Dive - Tuesday July 23, 8AM Pacific - recording: https://zoom.us/j/491220480Likely will do it again at 3PM Pacific time as well.wiki.hyperledger.org/download/attachments/16322546/GMT20190723-ACA_Deep_Dive_1920x1080.mp4?api=v2
- Aries-Framework-Go (Troy)
- Aries-SDK-Ruby (Jack)
- Moving from personal repo (https://github.com/johncallahan/rindy) soon.
- Indy SDK
- Late July:
- GitLab migration alongside Jenkins (Foundation)
- LibVCX without agency (Evernym)
- Proof of possession
- CLI tab completion
- Migration of components to Aries (
)Jira server Hyperledger JIRA serverId 6326cb0b-65b2-38fd-a82c-67a89277103b key IS-1285
- Late July:
- Ursa
- PRs for Anoncreds 2.0 are in progress
- ZMix specification in progress
...
- LibAries: library threading models and synchronicity
- Resolver and wallet might have different needs than other API functions.
Current design in Indy was implemented as part of IS-660
HIPE: https://github.com/hyperledger/indy-hipe/tree/master/text/0012-concurrency-improvement
- Mike's concerns: https://docs.google.com/document/d/1-oabbR7n4MsLsU-MGfrwbjJvB1V4nMroW_oh2BvYVXc/edit
- VON Anchor takes a significantly different approach:
- https://von-anchor.readthedocs.io/en/latest/von_anchor/anchors.html#revregbuilder
- "Neither multithreading nor green-threading primitives pass through the wrapper/shared-library barrier; subprocessing must occur early in the game before libindy sets up its dispatcher, as it operates in a separate thread(? message loop? it's been a while) that does not replicate over a fork (this is unix architecture not indy).
"In von_anchor, An external rev reg builder process uses file system semaphores as IPC, increases rev reg size as it scales up, and anticipates one rev reg in the future so that the issuer process never waits for a rev reg build."
- Problems with current architecture
- not flexible enough (PicoLabs' experience)
- hard for contributors to understand and improve
- Advantages of current architecture
- handles various inherent types of asynchronicity (ledger resolver, wallets, crypto)
- hides difficulty from application developers using the library
- Current Indy architecture:
https://github.com/hyperledger/indy-sdk/tree/master/docs/design/012-libindy-architecture-overview - Proposals:
- Keep the current Indy model of asynchronicity
- Handle asynchronicity in the language libriaries
- Multi-process instead of multi-thread
- Push asynchronicity from the common library closer to the sources of asynchronicity: ledger resolver, wallet handler, crypto wrapper (or crypto moves to application tier)
- Different threading models for Indy tier and Aries tier
- Follow up conversation: #aries-sdk
Future Topics
- Other LibAries architecture suggestions
- Hubs vs Agents
- Payments in Aries
- wallet query language
- IOT best practices (Robert Mitwicki, Adam Burdett , Lohan Spies )
...