Open ligi opened 6 years ago
This issue now has a bounty-address via issuETH.
Your bounty-address is 9eb20a6e6af0ae23d80692dedd0457f54ccc6f9f
Watch on rinkeby
Watch on main
The ContentProvider sounds like a good idea to try. Firebase does the init that way and I remember they had a few problems in the beginning. A successful completion of this would have to account for that and avoid it.
A link to start one off: https://firebase.googleblog.com/2016/12/how-does-firebase-initialize-on-android.html
I also do this in WallETH to decouple flavors like this: https://github.com/walleth/walleth/blob/master/app/src/withGeth/java/org/walleth/geth/GethInitContentProvider.kt
Thinking a bit longer about this: in the end this does not need to be that clean as it will get obsolete with #1 anyway ..-) A nice small modular Kotlin crypto lib replacing *castle would be so great!
Was recently talking to @cketti recently and I think he is correct that the best way is not to use the providers at all but the lower bouncycastle API - so we do not need the split spongy/bouncy at all. This way we also can avoid the multiple insertProvider calls. Perhaps when doing so we can also hide bouncycastle behind some crypto-interface so we can replace it with a pure Kotlin implementation at a later point.
what do you mean by lower bouncycastle API
?
you can directly use the functions without going through providers. So you are sure you do not run into the problem of using varying platform implementations. Will cc you once I make the PR for it
This is a follow-up for: https://github.com/walleth/kethereum/pull/21
There are now multiple of these blocks in kethereum:
I would really like a cleaner way of initializing spongyCastle - and ideally a decoupling from sponygCastle from kethereum so it can also be used with bouncyCastle in a JVM context where the whole spongyCastle is not needed.
One Idea:
@mirceanis what do you think?