Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Excerpt
  • 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: 20220118 Indy Contributors Call Recording.mp4

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.

...

Related Calls and Announcements

...

  • Indicio PBC will be doing Phase 1-3 (Scoping/Planning, Indy Node/Plenum Development, CI/CD)
  • Dominic Woerner Wörner will be doing Phase 4 (Indy VDR changes)

...

  • Developer Experience:
  • 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 - #28Merged
      • 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 Nest 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

...