2023-01-03 Indy Contributors Call

Owned by Stephen Curran
Last updated: Jan 03, 2023
2 min read

Summary

  • Update on Sovrin Node pipeline
  • Transition of indy-node from RC to final - branch comparisons
  • Open Discussion

Recording of Call: dummyfile.txt


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

Related Calls and Announcements

  • BC Gov Code With Us opportunities – Transitioning to the Indy/Aries Shared Components
    • Opportunities closed and awards have been made.

Release Status and Work Updates

Meeting Topics 

  • Sovrin Node build
    • Past the pipeline in indy-test-automation
    • Two tests failing, but they aren't part of the check for the change.
    • Philipp is on vacation and ready to go
    • Remaining:
      • Finishing integration
      • Publishing the artifact for Sovrin – Indy Plenum/Node done, Sovrin Plugins done, so just the Sovrin Node left to go
      • RC releases as soon as end of next week! Perhaps a first node deployed by the next meeting!!!!!!!!
  • Transition of indy-node from RC to final
    • About 2/3 of the way through branch comparisons of the main indy-node portion
    • Mostly there have not been significant differences discovered, except for in the following places:
      • data/migrations/deb
      • indy_node/server/request_handlers/domain_req_handlers
  • 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