Versions Compared

Key

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

Summary

Excerpt

Expected topics

  • Release updates
  • Proposal to improve performance of the Indy SDK CI test pipeline
  • Proposal to support Fully Qualified DIDs

...

Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

...

  • fuzzing libindy https://github.com/AxelNennker/indy-sdk/tree/fuzzing/
    `cargo +nightly fuzz run fuzz_target_1 -- -only_ascii=1`
    Worried about the lots of unsafe code in libindy
    ```
    ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$ find src -name \*\.rs -exec fgrep unsafe {} \; | wc -l
    61
    ```
  • 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.
  • Ursa and AMCL
  • Architecture questions for Indy SDK:
  • PostgreSQL wallet to graduate from "experimental" status?
  • Partially completed refactoring of the Request format: INDY-1375 and IS-567
  • Maintainership requirements for Indy Node and 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

...