You are not considering being self-funded by micro-transactions anymore?
Thatās our intention. We need to implement-or-integrate several new technologies to get there.
TL;DR We need to see what weāve got to spend it well.
A key component of micro-transaction funding is a suitable recipient for such funds. We think having finsight into the state of that recipient will be essential to efficiently leveraging those fundsā¦
We need to know not just the size of our treasury but also where itās coming from and where its going. The right answer for this kind of problem is tooling. More specifically we need intelligent representations of our treasury to make well-informed decisions.
TL;DR We need distributed spend authority to spend it well.
Beyond knowing what we have we need a mechanism to collaborate in the spend process. For that we hope to leverage the shielded threshold signature capabilities that the ZF is working on.
6 Likes
Morning! Is there a place to see progress or even just screenshots? Iām sure everyone would like an update, but Iād specifically like to see how you guys handled the insight/advanced finsight and memo threads. Thanks.
I understand this thread is a bit stale, please direct me if I am in the wrong place.
I am writing to provide the community with an update on the ZingoLabs effort.
Our February 6, 2023 Authentic Financial Insights proposal is not the best way to organize our immediate efforts.
We have been hard at work on three complementary efforts, that are necessary to provide users what they need in the immediate term.
Speed, Reliability, and Privacy.
To get Zingo to run faster:
We have been experimenting with a port of the latest version of the ECCās witness handling API. To verify that the new version of zingolib is both faster, and still correct, weāve done extensive user-testing with communities around the world. We discovered that occasionally under unreliable network conditions, on certain architectures, the new version (which is faster) fails to correctly mark notes as spent. As a user facing application that intends to be broadly available this is unacceptable to us.
This has stimulated us to build out our test infrastructureā¦
To get Zingo to run more reliably:
We now test end-to-end, on multiple architectures, against a range of simulated network conditions, and block-chain scenarios. To do so effectively, weāve invested significant development into the darksidewalletd framework, network-proxy tools, end-to-end tests on emulated devices, and increasingly into unit-test frameworks. In the course of this work, we have investigated network privacy tools which has led us to collaborate on the Nym projectā¦
To get Zingo to run more privately.
We are currently researching how the UA format can be extended to support Nym addresses, and how Zingo can become a Nym client. We are also considering whether and how our new ground-up Rust proxy will relate to Nym PEAPPs.
Because this work is not directly producing User-Facing Finsight features, we have foregone the earmarked milestone payout.
We will be releasing a faster version of Zingo, in the near future.
Once it is released we will petition the ZCG to consider paying us for the enhanced performance of Zingo, the community-available tools, and the contributions to ecosystem projects weāve made:
- librustzcash/ECC
- ledger/ZonDax
- nym/NymTech
TL;DR our current work is focused on:
- porting the latest ECC sync SDK, to increase sync speed
- extending our tool kit to cover a much broader set of conditions in multiple dimensions
- supporting ZonDax ledger integration (on desktop Zingo-PC)
- extending the UA format to support Nym addresses
- extending our network stack to run over Nym
- incrementally replacing lightwalletd/darksidewalletd with a pure Rust wallet-proxy
- implementing and end-user error report button (for experts) to push scrubbed data to us, in error cases
8 Likes
Hi folks! The faster version of zingo I promised above is now here:
Weāre going to ask the ZCG to provide us the repurposed Finsight Milestone 2 payout for this user-affecting update!
5 Likes
Look forward to another release soon!
3 Likes
Hi @ZcashGrants, @hanh, @noamchom, @Lukas, @Honza , @nuttycom, @harryhalpin
ZingoLabs is proposing the following feature list as a replacement for the old MileStone 3 commitment:
- ZIP317
- Android Background Sync in Android Mobile Devices
- iOS Background Sync in iOS Mobile Devices
- an upgraded Basic (Even More Basic) Mode to facilitate new User on-board
- regtest mode implementation in zebrad to facilitate deprecation of zcashd
- new wallet UI, and streamlining to integrate Nym privacy into the wallet (this does NOT include necessary work on the server-side, or Rust library components, which must be funded by other sources)
- coordinated work with the Zcash Foundation to produce a pure Rust, backwards compatible alternative to zcash/lightwalletd
We intend to complete this work by April 5th, 2024.
7 Likes
Noted. We will discuss and follow up with you next week. Hereās the detail of the old Milestone 3 you want to replace:
Milestone 3: Out Of Order Note Update, Spend Before Sync, ZIP317
The User benefits from the latest innovations available in librustzcash to have a faster, and smoother experience when sending and receiving funds from the mobile, desktop, and command line apps.
ZingoLabs manages proxy infrastructure to enable more flexible and thorough test
Qualitatively success can be measured in increases in well-informed and thoughtful decisions made by Zingo users.
The original milestone looks pretty good to me. Could you elaborate on the reasons behind the replacement?
coordinated work with the Zcash Foundation to produce a pure Rust, backwards compatible alternative to zcash/lightwalletd
Could you explain this a bit more?
Thanks
1 Like
Good question! The work that is not covered in the new list, that was in the old is the core sync upgrades. Weāre pushing two of those out past BackGround Sync:
Out of Order UpdateSpend Before Sync
TL;DR: Weāre going to ship the core sync upgrades next, but first BackGround Sync.
Why? Because Background Sync is faster, safer, and has better impact on UX.
It also augments the core work. Both the ShardTree port that weāve finished and the new features that weāre developing get time to run!
BackGround Sync:
(1) Faster to implement
(2) Safer to implement
(3) Has at least as much impact on UX
(4) augments the effect of the work on the core algorithms
Per the other items on the list:
UI:
UI needs to respond to User experience by becoming simpler, and prepare for new security enhancements.
- an upgraded Basic (Even More Basic) Mode to facilitate new User on-board
- new wallet UI, and streamlining to integrate Nym privacy into the wallet (this does NOT include necessary work on the server-side, or Rust library components, which must be funded by other sources)
Infrastructure:
We canāt run on a house of cards. This work moves us toward a pure Rust future, and benefits the entire community.
1 regtest mode implementation in zebrad to facilitate deprecation of zcashd
2 coordinated work with the Zcash Foundation to produce a pure Rust, backwards compatible alternative to zcash/lightwalletd
Per coordination with ZF, we havenāt heard anything from them yet. We donāt really know what the solution will look like, but weāre committed to making it happen.
1 Like
It takes 25 minutes to synchronize 2 months of data (using the improved Shard Tree, on the Samsung S24 Ultra). Per @joshs post, Zashi should take ~2 minutes. Therefore, I hope it wonāt take too long before the synchronization algorithm gets updated.
Hi @zancas. We have a meeting on Monday to discuss the milestone changes you proposed above. Regarding the Nym integration, can you elaborate on whatās included in Milestone #3? Thanks!
Hi @aquietinvestor a significant part of the Nym integration is proper UX.
Weāll propose several possibilities via experimental releases (i.e. TestFlight in Apple, internal test in Google) that provide sample interfaces, that arenāt connected to Nym, to solicit user feedback on the preferred experience.
Implementation of Nym integration will continue to proceed separately, and wonāt be covered by funding in this MileStone.
2 Likes
I really appreciate this data!
Based on this, I think that if Back Ground Sync runs for 10 minutes/day, then Zingo is syncing ~24 days per day of Back Ground Sync.
I agree that we need to be even faster, and weāre actively working on the next upgrades, but I think that going from syncing 0-blocks in the background to ~25_000 / day is enough of a performance improvement to significantly impact many user experiences.
That shouldnāt be the case with background sync. In general, the amount of time it runs is hard to predict and therefore it cannot be extrapolated like that.
I donāt understand why you donāt simply measure it instead of estimating it.
You just need a phone and an old seed phrase.
I trust your numbers. I think itās reasonable to back-of-the-envelope them, among other things it gives us an expectation to work against. But I take your point.
Weāll have more data soon, to compare against.
Actual deployed Back Ground sync runs overnight so we get a data point, per phone, per night.
1 Like
Well, Iām talking about general engineering/research practices. Itās important to have reproducible experiments. There is no need to rely on trust since everything is publicly available.
For instance, Iād be happy to provide the seed phrase for a 2-month-old account and use the same hardware. I like to use an online test framework because it puts everyone in the same environment.
Once Zashi releases, it can be tested the same way.
PS: Ywallet has background sync too. I am not saying it is a bad thing.
7 Likes
What do you mean by ācoordinated workā?
Iām not aware of us receiving an email or similar requesting or proposing coordination with ZF. Did we miss something?
3 Likes