Hi @mrkit2u and @aratrika_am. I’m Daniel, from Konclave, a group vault on Zcash: members approve a payment and their devices sign it with FROST.
Today our coordinator keeps each vault’s viewing key, so it can read every vault’s books. We are preparing a ZCG application for the first step of changing that: measure what scanning and proving cost in a phone’s browser, and write the design for taking the viewing key off the coordinator. We would rather build on WebZjs than write our own scanner.
We read WebZjs at bdbc6f2f. Its TEST_CASES.md lists detecting incoming Ironwood funds as not built yet, it proves Sapling and Orchard spends but not Ironwood ones, and the store it uses does not keep Ironwood notes. Since NU6.3, the payments our vaults receive land in Ironwood. So, two questions:
- Your grant includes the milestone “Webzjs updated to NU 6.3 with Simple Migration to Ironwood” (ZCG issue 335), and we do not want to ask ZCG to pay for something already on your plate. Will it cover scanning and spending Ironwood notes for an account imported from a viewing key? If it helps, we can test it against a Konclave vault as it lands and send you what we find. And would numbers from phones’ browsers be useful to you? There is also an open upstream pull request that adds Ironwood to the store; would you bring it into your copy, or prefer another way?
- WebZjs uses wasm threads, which need the COOP and COEP headers, and Konclave does not send them today. If we get scanning to work without threads, behind a feature flag, would you want that in WebZjs, or in a fork?
Anything we find goes to you first, with a way to reproduce it. Thanks for keeping WebZjs going.