@hanh I think you’re right that it would be desirable for there to be one-stop shopping for developers coming into this space, with a clear library to choose that is built for a wide range of purposes.
And I totally agree on the “ecosystem” points.
But I think I’d echo Aditya’s point that there are tradeoffs here. Right now, Aditya is able to make improvements up and down the stack to address issues he’s hearing about directly from users. That’s let him move a lot faster on usability than wallets that depend on the ECC SDK, which moves slower. Zbay has been using zecwallet-light-cli as our library and it’s been a good choice for us so far. We chose it because at the time, the ECC library did not support t-addresses at all.
If Zecwallet succeeds at addressing half of the UX-related lightwallet protocol issues above, it will continue to be the best choice—at least for projects whose use-case and tech stack are similar to Zecwallet’s (i.e. cross platform wallets with Electron and React Native, which are common stacks!) For example, if Aditya can address the issue of long syncing times before returning users can access funds, that would be huge leap ahead of the ECC library, for Zecwallet, Zbay, and any projects using the Zecwallet libraries.
I think we can also take your comment as advice for ZOMG about what to fund.
On that front, Nighthawk, which is building on the ECC SDK, is in a position where in order to achieve their goals they will need to make a lot of upstream fixes to the ECC SDK. That’s part of the grant they just applied for. If we fund them, we’ll be funding work on the official library, and will hopefully increase its feature set, velocity, and responsiveness to user needs. We’re also funding Aditya as part of this grant to bring the lightwalletd’s closer together, so there’s that too.
We’d be interested in funding other groups to work on the official SDK too, as well as on the other items in your ecosystem list. If this is work that you’d be interested in undertaking or in managing a team around, we should discuss this!
The one anxiety I have is that we are in a situation common to open source where a project has forked an official library to make it more responsive to their own needs, but where it would be beneficial (both to the official project and the forking project, which is now carrying a growing maintenance burden) to get improvements from that library merged upstream—and I’m wondering whether we are approaching that in the best possible way. Like, @adityapk00, do you think that divergence from the official library is a kind of technical debt, since it could become more and more burdensome over time for you to maintain your fork on your own? And if it is, are we giving you the support you need to address that technical debt? I know there’s a plan for this on the lightwalletd side, but is there a plan for it on the zecwallet-light-cli side?