2022-12-06 Indy Contributors Call

Owned by Stephen Curran
Last updated: Dec 07, 2022 by Char Howland
2 min read

Summary

  • Update on Sovrin Node pipeline
  • Steps in eliminating the Indy SDK
  • Transition of indy-node from RC to final
  • Question from Lynn: Will the did-method work be included in the 20.04 upgrade?
  • Open Discussion


Recording of Call: 20221206 Indy Contributors Call Recording


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

Stephen Curran (BC Gov/Cloud Compass Computing Inc.) <swcurran@cloudcompass.ca>

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>

Kim Ebert (Indicio, PBC) <kim@indicio.tech>

Related Calls and Announcements

  • BC Gov (likely) to post funded opportunities around the migration from the Indy SDK to the Indy/Aries Shared Components (Indy VDR, Askar, etc.)

Release Status and Work Updates

Meeting Topics 

  • Sovrin Node build
    • indy-test-automation consistent failing some tests.
    • call of indy-test-automation from sovrin via json encoded variable inputs (atm still hardcoded in sovrin GHA defintion, working on the parametrization and information extraction)
    • specific version problems with fpm
  • Steps in eliminating the Indy SDK
    • Investigating different paths for the Indy CLI
    • Working on a repo using Python to recreate the Indy CLI
    • Creating a HIPE
  • Transition of indy-node from RC to final
    • Lots of blockers getting the environment set up to, moving forward towards branch comparisons
    • VSCode Dev Containers and GitPod on the 20.04 upgrade branch
  • Question from Lynn: Will the did-method work be included in the 20.04 upgrade?
    • Yes, the Indy DID method work is already on the 20.04 upgrade branch
    • Only outstanding item: required work on the Indy-VDR side that hasn’t been merged into the main branch yet
    • Indy VDR and Indy node 20.04 releases can be separate
      • However, if using Indy-VDR and the Indy DID method, need to upgrade
  • Using indy-node-container for the indy-vdr tests
  • 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...

Action items