Introduction to an Ethereum key management library

[anhnguyenbitmark]

Hello there,

We are from the Bitmark team, working on a project called Autonomy. Initially, it provides a similar set of functions to Metamask, enables end-users to have their own Ethereum wallets. They can also see their NFTs if there are any with ERC721 tokens.

We would like to share with the community our swift library (https://github.com/bitmark-inc/libauk-swift) for key management and signing Ethereum transaction.

Brief information on what it does:

• Create and store private keys securely on the iOS keychain.
• Sign transactions and data.
• Stored seed can be able to export using BC's UR format.

What we will be working on next:

• Make the seed fully understandable and recoverable using the Gordian Seed tool.
• Support Gordian Seed tool's crypto-request for Ethereum address, signing Ethereum transaction.
• Release a Kotlin version for Android.
• Support Tezos and Flow.
• Support Bitcoin.

If you are interested in any topic, let us know. The library is on the Alpha stage, we supposed to have some breaking changes. Your feedback or PRs are greatly appreciated.

[wolfmcnally]

Hello, Anh! I've just been looking over the code; great work! Was there any particular feedback you had or questions you'd like me to address with regard to Blockchain Commons technologies including your use of URs?

[anhnguyenbitmark]

Hi Wolf, thanks for checking the code!

For the URs or other parts of Blockchain Commons technologies, currently, we are good and don't have questions. We desire to have the seeds migratable to the Gordian Seed tool and hope you can be of help there.

[wolfmcnally]

If you are interested in any topic, let us know. The library is on the Alpha stage, we supposed to have some breaking changes. Your feedback or PRs are greatly appreciated.

@anhnguyenbitmark I'm wondering why you chose to depend on PromiseKit? For the Swift code I'm writing right now that I expect to be deployed in next generation Swift apps, I am writing in Swift 5.5 and taking full advantage of async/await and structured concurrency. I know it's not technically out yet, but it's in the latest Xcode betas and will be officially released any day now. When this happens, most of the pre-existing paradigms and third-party concurrency libraries are likely to become technical debt.

[anhnguyenbitmark]

For the PromiseKit, it's one of the dependencies of a Web3 library that we forked recently. The plan is to remove completely and replace it with Apple's one. It could be the Combine framework or Swift's async/await. For Swift's async/await, we are also eager to adopt. But seems like it won't deploy back to the older OSs since it's shipped with the new Swift runtime.

[wolfmcnally]

Yes, Swift 5.5's concurrency model is likely to the dominant one going forward, and I suspect Apple may even deprecate Combine at some point. The main reason I think this is Apple's reluctance to include Combine in the standard open source Swift distribution, which means, for example, that people using Swift on Linux don't have access to Combine. This seems like a glaring omission, until you realize that the new Swift concurrency model basically includes a lot of the functionality of Combine, and while it doesn't completely replace it yet (for example publish/subscribe), the Swift language and standard library is likely to evolve to directly support that functionality, especially given Swift 5.5's nascent support for Actors.

Adoption of new iOS major releases tends to be very fast. So for apps that won't be out for a few months I recommend that all new code adopt Swift 5.5's concurrency, and that other techniques should be deprecated. This would especially hold for newly written libraries.