2023-01-31 Indy Contributors Call
Summary
Update on Sovrin Node pipeline
DSR progress report
Transition of indy-node from RC to final - branch comparisons
Open Discussion
Recording of Call: 20230131 Indy Contributors Call
Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit the Hyperledger Code of Conduct. |
|---|
Welcome and Introductions
Attendees
@Char Howland (Indicio, PBC) <char@indicio.tech>
@Philipp Schlarb (esatus AG) <p.schlarb@esatus.com>
@Wade Barnes (BC Gov / Neoteric Technologies Inc.) <wade@neoterictech.ca>
@Lynn Gray Bendixsen (Indicio, PBC) <lynn@indicio.tech>
@Sylvain Martel (Qc Gov) <sylvain.martel10@mcn.gouv.qc.ca>
@Alexander Sherbakov (DSR) <alexander.sherbakov@dsr-corporation.com>
@Vladimir Shishkin (DSR) <vladimir.shishkin@dsr-corporation.com>
Related Calls and Announcements
Release Status and Work Updates
Indy Node
Indy SDK
Indy Monitoring - https://github.com/hyperledger/indy-node-monitor
Indy Node Container - https://github.com/hyperledger/indy-node-container
Indy/Aries Shared Libraries - Hyperledger (indy-vdr, indy-shared-rs, aries-askar)
Ursa
Indy DID Method – https://hyperledger.github.io/indy-did-method/
AnonCreds Specification: https://anoncreds-wg.github.io/anoncreds-spec/
Meeting Topics
Sovrin Node build
Ubuntu 20.04-compatible release candidate for Sovrin Node!
Testing in VON network with new package- has gone well
Lynn has gotten new and replaced nodes working on the Indicio tempnet
Refactoring Indy test automation and incorporate it into the Indy node pipeline
Transition of indy-node from RC to final
Issue created: https://github.com/hyperledger/indy-node/issues/1791
Priority raised on this issue since we have the release candidate
DSR progress report
Update of VON network to use the recent Indy-VDK depedency instead of libindy
Done
New Indy CLI based on Indy VDR and Aries Askar
PR waiting for review
Indy test automation
Made improvements in Askar and Indy VDR
Good process here
Other Topics
Future Calls
Indy Roadmap
GDPR and the right to be forgotten – mitigations and approaches.
The Indy "Corporate Firewall Problem" and the idea of a Proxy Server on Nodes? @Kim Ebert
Core issue: A mobile wallet user using a Corporate WiFi may find that they can't get to an Indy ledger because all but 80/443 ports and HTTP/S protocols are blocked
Discussion/Options paper: https://hackmd.io/@n5FW6jwuRfCgchBDNWR3VQ/H1kNlKpmo
Question: Is it viable to have each Indy Node also listen on port 80/443 for HTTP/S requests and arrange to have them processed?
Option: Receive on HTTP(S) and send on to local ZMQ instance as if coming from outside.
Answer: We think it is probably not viable, as mobile agents require HTTPS. As such, each Steward would have to get a IP-based SSL Certificate. Technically doable, but getting everyone through that is really not practical. The cost of the certificates and maintaining them would be ugly.
Option: Add a DIDComm agent to every node, and use DIDComm to send the messages
Similar to using HTTP(S), but use a DIDComm message. Since Mobile Agents would be using a mediator, the DIDComm message would flow through that, and the HTTPS issue would not matter. This is almost easy, but... There is no encryption public key in the genesis file, so that needs to be retrieved from somewhere else...