2021-05-11 Indy Contributors Call

• Stephen Curran (Cloud Compass Computing Inc.) <swcurran@cloudcompass.ca>

• @Richard Esplin (Evernym)  <richard.esplin@evernym.com>

• @Sebastian Schmittner (EECC) <sebastian.schmittner@eecc.de>

• Indy Node

  • GitHub actions led by @Wade Barnes

  • Ubuntu 20.04 upgrade led by @Robin Klemens and@Ryan Marsh

  • Sovrin Updates @Wade Barnes 

  • New branching model led by @Wade Barnes

• Indy SDK

  • GitHub actions led by @Patrik Stas

  • LibVCX tests are failing. Proposal is to deprecate LibVCX in the Indy SDK, and focus on aries-vcx.

• Indy Monitoring - https://github.com/hyperledger/indy-node-monitor

  • Sovrin Steward Council Health Workstream has been working on it.

• Indy/Aries Shared Libraries - donated to Hyperledger (indy-vdr, indy-shared-rs, aries-askar)

• Ursa

  • Appears that refactor has stalled? Need volunteers.

• Hyperledger Contribution Campaign (@Richard Esplin @Stephen Curran )

• Update:

  • Indy-Plenum CD is the furthest along. Thank you @Robin Klemens!

    • PR submitted last week - for 16.04

    • Reviewed by @Wade Barnestoday, some cleanup needed

    • No blockers

    • Next step is CD for Ubuntu 20.04

  • Indy-Node

    • No changes – waiting on Plenum

  • Sovrin Release - @Wade Barnes

    • Issue with libsov token builds for IOS/client side – needed for the testing, engaged Ian C/BC Gov to work this

    • Jenkins build 

  • indy-test-automation – had been working, but it is dependent on the Sovrin packages that are not made yet.

    • Blocked on previous issue

• Indy SDK - ABSA updates merged – libvcx removed from CI / CD

• IDUnion Docker images for Indy Node ( https://github.com/IDunion/docker-container-wg/ )

  • Goals: reduce dependencies, in particular from specific Ubuntu Versions

    • Questions around running indy node in a container in the first place (restarts/upgrades, systemd,...)

  • WIP! But we got a few (ubuntu 18, debian buster) running containers which are not ubuntu16 based.

  • Upstream Contribution

    • @Wade Barnes : Perhaps make it a part of Indy Node repo?

    • Into a separate - repo – e.g. "indy-node-container" - in case the repo is moved to Hyperledger

  • Sovrin experience goes:

    • Persisting the ledgers – that's easy

    • Challenge is that the network is long running and does network driven updates

      • Network update done, updates node themselves – new dependencies, new version of Node – but this is happening to ephemeral storage (not persisted)

        • Upgrade strategy for docker is that they pull a new image, not simply automate the upgrade of the running container

      • On restart, the ephemeral updates are lost, and the node is running old code again.

      • Need to persist the code changes.

    • Challenge as well is that we lose diversity if all nodes run the same docker image – how do we retain diversity?

    • Old PR about using docker: https://github.com/hyperledger/indy-node/pull/588/

Next call:

Future:

• Changes to indy-node needed for did:indy

• 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

• Hyperledger campaign to recruit additional developers.