Sdk20251124

Agenda

• SDK post hacktoberfest follow-up
• v3
  • Keys
  • Vanko and Venilin topics
  • Mirror Node
    • REST APIs
    • HIP-1261
  • Protobufs

Minutes

• SDK Hacktoberfest follow-up
  • Rob recapped on Sophie's presentation last meeting and asked about follow-ups following her TSC presentation
  • Hendrik has had discussions with Richard about setting up GitHub actions and workflows in other SDK repositories
    • Also wanted to set up a weekly "backlog grooming" session to establish good first issues and clean up repos
      • Rob to reach out to Jessica about setting this up
  • Hendrik to meet with Sophie to bring workflows, GitHub actions, and trainings to LFDT
  • Sophie brought up again how contributors are starting to submit more complicated pull requests and it's becoming tougher to review them in a timely manner
    • Had to start asking Limechain to help review PRs
  • Hendrik mentioned he does not want people from Hashgraph and Limechain to take over the project
    • They could work on small portion of it, like TCK support
    • Wants to keep it a community project for the sake of having it as a good example of a fully open-source project
  • Hendrik suggested having more Hashgraph and Limechain engineers do reviews in the Python SDK, not full implementations
  • Hendrik also mentioned trying to acquire money and resources to do things like training videos
  • Rob clarified that all this was meant to be general SDK training, not Python specific
  • Rob suggested trying to find a better spot to put this information (SDK hub?)
    • Hendrik agreed but should figure out resourcing and money first
• v3 Keys
  • Rob recapped previous discussion on keys for v3 SDK and presented on what our current SDKs are capable of
    • Described ASN.1, DER, PKCS#8, X.509 SPKI, and SEC1 standards and how they applied to the SDKs
    • Highlighted differences between the SDKs in terms of key format, and import and export capabilities
    • Key highlights:
      • ED25519 key generation is fully standardized across Hiero SDKs
        • Private keys use PKCS#8 standard
        • Public keys use SPKI with curve-OID
      • ECDSA secp256k1 has two camps
        • Camp A
          • C++, Swift, JS, Rust
          • Private keys use PKCS#8
          • Public keys use SPKI with curve-OID and compressed EC point
        • Camp B
          • Java, Go, Python
          • Private keys use SEC1 ECPrivateKey
          • Public keys use SPKI with id-ecPublicKey + params and compressed EC point
            • Python uses uncompressed EC point
      • In general, there still is a good amount of cross-compatibility between SDKs, but they're not fully cross-compatible
        • Some SDKs can't import keys from other SDKs
    • Suggested use of PKCS#8 for private key and SPKI with curve-OID going forward as standard
  • Hendrik and Rob agreed a unified structure should be thought up (i.e. all keys in all SDKs use the same ASN.1 structures)
  • Keith expressed concerns in this simplicity, thinking there would be no good way to import all possible standard keys into the SDK
    • Rob reassured that most modern crypto libraries should be able to parse most standard ASN.1 key definitions
      • If an SDK is unable to right now, it is most likely at the SDK level that is preventing it
  • Rob mentioned he wasn't sure if these differences are SDK level differences in implementations, or lower-level crypto library implementations
    • Hendrik stated we should look into the lower-level library implementations and see what they can support
  • Keith questioned if we even needed DER-encoding in SDKs as the web3 space doesn't use DER-encoding
    • Hendrik mentioned we could make it more obvious in SDKs, doing something like fromStringEthereum for other web3 users
    • Rob stated DER-encoding, while not as necessary in web3 space, is a good way to interface with other libraries or non-web3 systems