This proposal aims to solve #12 and #13 from a different angle.
At the moment, the only reason to import a Keccak algorithm as SDK dependency is the HTLC template (in templates folder), which is some kind of "utility" that it's not a core feature.
This feature requires the SDK to import a Keccak algorithm that:
1) is not part of standard Swift CryptoKit algorithms
2) is implemented by SwiftKeccak, which is not a well maintained library (2 stars and no maintenance in 2 yrs as of today). This library also has no Cocoapods support, which is probably the most used dependency manager on iOS (and Apple) apps (see #12 for more details). Furthermore, this library does not specify any type of license in the repo.
3) is implemented by CryptoSwift, which is a well-know and super-well maintained library, has CP support, but has a MIT/Apache2.0 incompatible licensing model (it's a custom one).
My proposal is to separate the HTLC template in some kind of "extra" folder and manually integrate it when needed.
Implementing apps will have to copy-paste it and decide which Keccak implementation they'd rather use (or write their own if needed).
We should also write a detailed Readme about this, or maybe a working example with integration
This proposal aims to solve #12 and #13 from a different angle.
At the moment, the only reason to import a Keccak algorithm as SDK dependency is the HTLC template (in templates folder), which is some kind of "utility" that it's not a core feature.
This feature requires the SDK to import a Keccak algorithm that: 1) is not part of standard Swift CryptoKit algorithms 2) is implemented by SwiftKeccak, which is not a well maintained library (2 stars and no maintenance in 2 yrs as of today). This library also has no Cocoapods support, which is probably the most used dependency manager on iOS (and Apple) apps (see #12 for more details). Furthermore, this library does not specify any type of license in the repo. 3) is implemented by CryptoSwift, which is a well-know and super-well maintained library, has CP support, but has a MIT/Apache2.0 incompatible licensing model (it's a custom one).
My proposal is to separate the HTLC template in some kind of "extra" folder and manually integrate it when needed. Implementing apps will have to copy-paste it and decide which Keccak implementation they'd rather use (or write their own if needed).
We should also write a detailed Readme about this, or maybe a working example with integration