Versions Compared

Key

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

...

  • Documentation improvements: Michael B and Stephen C
    • Need to review and prune out-of-date documentation (Alice / Faber treatment of pairwise DIDs is a key pain point)
    • Michael is working on Indy Agent walkthrough using C#
    • Finishing work on ReadTheDocs (2 more weeks?)
  • SDK 2.0 architecture / Indy-Aries split (Sergey)
      Indy SDK Architecture Questions: 
    • Sovrin Foundation team and Daniel making progress
    • Will work on defining the API surface in order to better understand what the threading model should be underneath
    • Need to define how we want to handle private keys. Shouldn't expose them to the end users, but need to access them from multiple libraries.
    • Feels pressure to make short term decisions that can be improved incrementally. Will also help Kiva to contributeAnxious to start moving, and iterating.
  • GitLab migration (Mike and Steve G)
    • Demos in the Identity Implementers WG calls
    • Issues with Jenkins machines because Rust builds run out of memory—workaround increased build time but is a temporary solution
  • Advanced Schemas and W3C creds (Ken)
  • Warnings from rust cargo clippy (Mike and Axel)
    • IS-1270 through IS-1274
  • New design for revocation / Anoncreds 2.0 (Mike)
  • Getting Ursa artifacts published that can be used by Indy Node and Indy SDK (Mike and Cam)

...

  • fuzzing libindy https://github.com/AxelNennker/indy-sdk/tree/fuzzing/
    `cargo +nightly fuzz run fuzz_target_1 -- -only_ascii=1`
    Worried about unsafe code in libindy
    ```
    ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$ find src -name \*\.rs -exec fgrep unsafe {} \; | wc -l
    61
    ```
  • PostgreSQL leaving experimental status (see previous discussion)
  • Maintainership requirements for Indy Node and Indy SDK
  • Partially completed refactoring of the Request format: INDY-1375 and IS-567

Future Calls

  • Fully Qualified DID support in Indy SDK
  • New pack / unpack requires disclosure of recipient
    • Cannot hide the receiver of the message like we could with msg_pack
    • Allows having multiple recipients of the same message
    • Should list the drawback in the Aries-RFC? Is there an alternative way that preserves the capability to selectively disclose the recipient?
    • From Kyle Den Hartog
      msg_pack presents problems when dealing with an agent that maintains more than one relationship. For example, if I receive a message, I don't know which key in my agent I should be using to decrypt the message. We can get sender anonymity or receiver anonymity, but I don't believe it's possible to get both and still determine who the message is for.
    • Pack/unpack only exposes the Verkey of the recipients. It does not do forward secrecy.
  • Ursa and AMCL:  Discussed in the Ursa call (August 21), but no decision yet.
  • Architecture questions for Indy SDK:
  • How to handle old pull requests that failed DCO Checks? Close?
  • How to handle pull requests for IOS / Swift wrappers? Close and encourage the move to Aries?
  • How to handle pull requests for LibVCX? Deprecate?
  • Close PR https://github.com/hyperledger/indy-sdk/pull/1048 as something that will be replaced by the advanced schema work?
  • HIPE pull requests: https://github.com/hyperledger/indy-hipe/pulls

...