/
2022-01-18 Indy Contributors Call

2022-01-18 Indy Contributors Call

Jan 19, 2022

Summary

  • Status of indy-node CI/CD and the Ubuntu upgrade

  • did:indy DID Method PR review

  • Getting started on the "did:indy" DID Method development work

Recording of Call: 

Chat from Call:

  • 08:28:47 From Wade Barnes : I have one Indy-SDK related topic before we end. We’ve been getting a fair number of contributors lately. The builds are failing due to Rust build dependency issues. I’m thinking I need to dig into and resolve that sooner than later. Agreed?

  • 08:30:39 From Robin Klemens : @Wade. I agree since Indy-Node still relies on Indy SDK and we need a running CD pipeline there. Otherwise, the contributions won't help the community

  • 08:37:36 From Dominic : The public key is generated from the private key using the Elliptic Curve Digital Signature Algorithm. You get a public address for your account by taking the last 20 bytes of the Keccak-256 hash of the public key and adding 0x to the beginning.

  • 08:37:52 From Dominic : Source: https://ethereum.org/en/developers/docs/accounts/#account-creation

  • 08:38:13 From Paul Bastian : so they are using the hash of the whole public key and thats what we should do as well

  • 08:38:59 From Paul Bastian : did:indy:sovrin:staging:6cgbu8ZPoWTnR5Rv5JcSMB
    did:indy:sovrin.staging:6cgbu8ZPoWTnR5Rv5JcSMB

  • 08:39:56 From Robin Klemens : Isn't that the idea behind hashing? At any given input create a unique hash value at a specific length

  • 08:42:44 From Paul Bastian : technically right Robin, but it makes sense to take the highest entropy available anyway

  • 08:43:23 From Robin Klemens : which is the whole public key rather than just a fraction of it

  • 08:44:28 From Paul Bastian : did:indy universal resolver driver mvp:
    https://github.com/IDunion/indy-did-resolver

  • 08:45:35 From Paul Bastian : its kind of a mess, but a first working example that provides the minimal did document from a NYM

  • 08:47:36 From Dominic : Awesome!

Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.

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 (Cloud Compass Computing Inc.) <swcurran@cloudcompass.ca>

  • @Robin Klemens  (Institute for Internet Security) <klemens@internet-sicherheit.de>

  • @Philipp Schlarb (esatusAG) <p.schlarb@esatus.com>

  • @Hakan Yildiz (TU Berlin) <hakan.yildiz@tu-berlin.de>

  • @Christian Bormann (Robert Bosch GmbH)  <ChristianCarl.Bormann@de.bosch.com>

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

  • @Lynn Gray Bendixsen(Indicio, PBC) <lynn@indicio.tech>

  • @Paul

Related Calls and Announcements

BC Gov Indy DID Method Code With Us opportunity: https://digital.gov.bc.ca/marketplace/opportunities/code-with-us/e3dd1605-cc1d-4c30-a9ee-245940bccd0d

  • Indicio PBC will be doing Phase 1-3 (Scoping/Planning, Indy Node/Plenum Development, CI/CD)

  • Dominic Wörner will be doing Phase 4 (Indy VDR changes)

Release Status and Work Updates

Meeting Topics

  • Developer Experience:

    • Recent merges...  @Wade Barnes

  • Update on CI/CD Update and Ubuntu Upgrade: Status Document

    • Indy-Plenum Status: 

      • Done, 16.04, 20.04, Jenkins and GHA

    • Indy-Node Status:

      • Done, 16.04, 20.04, Jenkins and GHA

      • One 20.04 running in the IDUnion network of 16.04 nodes

      • Merged PRs:

      • Ready to do a first release - working towards that.

        • Artifacts being produced and consumed from Artifactory

        • Move all within Hyperledger GitHub

        • Ready to produce a release

    • indy-test-automation Status:

      • Merged (no circular dependencies!!!!!) - 16.04

      • Still to be done: 20.04 – systemd image needs to be replaced – may have to be created.

      • Workflow to trigger - needs a secret setup / @Ry Jones - Done - can't be run for a PR, just for an RC or manually triggered

    • Currently releasing development artifacts – left to do is a tag-based official release process - @Wade Barnes with help from @Robin Klemens

    • ** Sovrin Release - @Wade Barnes Status:

      • Working ready to start in the three repos in Sovrin

  • Scoping/Planning the "did:indy" DID Method

    • Pull Requests:

      • Privacy Considerations - #29 - Merged

      • Security Considerations - #28 - Merged

      • New method for self-certifying NYMs - #26

        • Change to use SHA-256, but use the full public key as input

      • Proposal - change the separator for the sub-network from ":" to "." - #25  - Merged

      • Fix Typos - #24

      • Add the new Indy DID method to the W3C registry: https://github.com/w3c/did-spec-registries - #393

        • Updated to reflect merges and now approved.

    • Next Steps:

      • Itemizing the work – particularly in Indy Node/Plenum

        • Indy HIPE?

      • Code evaluation to feedback into the specification – are there easier ways to accomplish some of the goals?

    • Issue: If Indy SDK is not updated, how do we run the Indy Node/Plenum tests?  TBD

Future Calls

  • Ideas for "Good First Task" for the Indicio class coming up in two weeks

  • Issues that could impact indy-node on 20.04

    • indy-sdk: needs an upgrade to OpenSSL 1.1 to properly support Ubuntu 18.04/20.04.  For indy-node, just using indy-sdk as is.

    • Multiple libsodium versions could impact consensus – intermittent issue on a mixed network.

  • Plans for a new Indy-SDK release?

  • Indy Contributor Campaign

    • Focus: Indy Generation Next

      • Audience: Organizations building Indy Instances, applications built on Indy

        • Not going for casual, independent developers, more on organizations that can assign developers to work on the project for a set chunk of time (e.g one month)

      • Key Features:

        • Indy network of networks support

        • Indy support for W3C DID Standard 1.0

      • Tasks:

        • Update NYM to support new "diddoc_content" data element

        • Indy-sdk, indy-vdr support for new "diddoc_content" data element

        • Indy DID Resolver support for new "diddoc_content"

        • indy-sdk, indy-vdr support for multiple ledgers

        • Support for new ledger object identifiers

        • Handling cred_defs that references schema on other ledgers

        • Possible: support for NYM "keri_keystate" data element, indy-sdk/indy-vdr support and DID resolver support

        • Other?

      • Foundational Work:

        • did:indy spec. as a spec.

        • Tasks in GitHub Issues - tagged for campaign

        • Getting started with developing indy-plenum and indy-node

      • Campaign work

        • Landing page

        • Video: Intro to Indy Generation Next

        • Meetup channels

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

Action items