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