- Work updates
- Agents vs Hubs
- Aries SDK threading model
Note: This call is Recorded. Recordings posted at the bottom of the page.
(7AM Los Angeles, 10AM New York, 3PM London, 17H Moscow)
Remember the Hyperledger Code of Conduct
Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.
Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.
- Name (organization) <email>
- Richard Esplin (Evernym) <email@example.com>
- Daniel Bluhm (Sovrin Foundation) <firstname.lastname@example.org>
- Adam Burdett (Sovrin Foundation) <email@example.com>
- John Callahan (Veridium) <firstname.lastname@example.org>
- Nicholas Rempel (BC Gov) <email@example.com>
- Andrew Whitehead (BC Gov) <firstname.lastname@example.org>
- Rebecca Christman <email@example.com>
- Brent Zundel (Evernym) <firstname.lastname@example.org>
- 26 attendees
Welcome / Introductions
- BC Gov is interested in collaborating with groups working on Mobile Agents that could be ready for a live implementation at the end of the summer. Contact Stephen Curran.
- Community project: Aries RFCs - process to move HIPES; RFCs that have been moved concepts / features / pull requests.
Summary of Prior Calls and Related Meetings
- Aries WG
- Aries-CloudAgent-Python (bc.gov) - Release 0.2.0, 0.2.1 tagged
- Architectural Deep Dive recording: https://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
- PRs for Anoncreds 2.0 are in progress
- ZMix specification in progress
- Documentation improvements: Michael B and Stephen C
- First draft in aries-cloudagent-python from 0 to coding in Aries
- Need to review and prune out-of-date documentation (Alice / Faber treatment of pairwise DIDs is a key pain point)
- SDK 2.0 architecture / Indy-Aries split (Sergey)
- https://docs.google.com/document/d/1MYMi4NkixfoIJeC79WBOfX_QA3_9rG-iK3lZa86vIR0/edit#heading=h.z1u0dzf62loi POA and discussion
- https://docs.google.com/drawings/d/1d-aCRC_Nzyywv9nyQif9_vBGbeWhp69M4T5_8_yYtAI/edit?usp=sharing Indy SDK Migration box diagram
- https://docs.google.com/drawings/d/1sUffkRPlufingeeRjjBniVt9Ek3CNih9lUqym8mUl4M/edit?usp=sharing Aries Architecture
- https://hackmd.io/_BhJewTlSUqMGNDc4SvgNw?edit developing ideas around APIs
- 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
- Mike's concerns: https://docs.google.com/document/d/1-oabbR7n4MsLsU-MGfrwbjJvB1V4nMroW_oh2BvYVXc/edit
- VON Anchor takes a significantly different approach:
- "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:
- 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
- Other LibAries architecture suggestions
- Hubs vs Agents
- Payments in Aries
- wallet query language
- IOT best practices (Robert Mitwicki, Adam Burdett , Lohan Spies )