2022-11-22 Indy Contributors Call

Summary

Recording of Call:

Open

Welcome and Introductions

Attendees

@Wade Barnes Neoteric Technologies Inc. <wade@neoterictech.ca>

@Lynn Gray BendixsenIndicio <lynn@indicio.tech>

@Kim Ebert Indicio <kim@indicio.tech>

@Christian Bormann (Robert Bosch GmbH) <christiancarl.bormann@de.bosch.com>

@Char Howland (Indicio PBC) <char@indicio.tech>

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 

• IIW Update

  • AnonCreds and their use with other ledgers and the W3C format

  • DIDComm vs OpenID for VC

  • Implemtation of predicates using BBS+

• Sovrin Node build

  • Working through blockers on the Indy Test Automation pipeline

• Help on the transition of indy-node from RC to final

  • Determining if there are commits on the main branches of indy-node and indy-plenum that should be in the 20.04 upgrade branches

  • Kim anticipates having recommendations next meeting

  • Christian tried the migration process switching to the current release candidate

    • Ran into some networking issues

    • Difficulty getting a timeslot that works for everyone

• Update on indy-vdr issue with Genesis File/Node mismatch issue (indy-vdr#106)

  • Workaround from Lynn is updating the genesis file to ensure that you have a current snapshot of the network you're connecting to

  • Andrew is determining is there is a secure and reliable way to sync transactions from the pool without requiring full-on consensus with the network

• Using indy-node-container for the indy-vdr tests

  • Draft PR from Christian: https://github.com/hyperledger/indy-vdr/pull/112

• Deprecate the indy-sdk initiative

  • Adam is evaluating the best path forward for phasing out the Indy SDK

    • Whether to continue with having it be a Rust application or to move to using a Python applucation that uses the binaries built for Askar, Indy-VDR, etc.

    • Preparing proposal for the future of the Indy-CLI

• Questions bout deprecating the indy-sdk

  • The whole community is moving away from indy-sdk towards Askar, indy-vdr, and the other shared libraries

  • Discussion about the migration is happening on the indy-vdr and ACA-Py channels on discord

• Question about the implementation of observer nodes

  • Still just a concept, not implemented except some pieces in plenum; not known documentation

• 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...

• Status of Indy-SDK

  • Statement on the future of the Indy SDK: PR 2329

  • Plans for future of Indy CLI (move to Indy VDR?)

  • Indy SDK in test for Indy Node (move to Indy VDR?)

  • Status of GitHub Actions for the Indy-SDK

• Indy bugs

  • Using GitHub tags "Good First Issue" and "Help Wanted" 

  • Node 1490: problems with large catch-up

  • Plenum 1506: view change message consensus calculation error

Action items